Alexander Viro wrote:
>
> On Thu, 30 Mar 2000, Jeff V. Merkey wrote:
>
> >
> > I think I've gotten to the bottom of the dcache pinning issue. When rm
> > is calling getdents(), as it deletes files, the positional relationship
> > within a given directory changes.
> >
> > i.e. This is what seems to happen:
> >
> > seek(dir, 0, SEEK_SET);
> > getdents(,64);
> > seek(dir, 60, SEEK_SET);
> > getdents(,64);
> > seek(dir, 120, SEEK_SET);
> >
> > As the files unlink, the dir hash chains in NWFS shrink, and their
> > relative positions change between readdir() calls, which causes rm -r to
> > run off the end of directory and forget where it really is. It's clear
> > I need a way to "pin" the dcache in place while GLIB/rm is doing this.
>
> No, you don't. Pinning the dcache stuff will not help you here - getdents
> couldn't care less for dentries of children. If you can't keep the
> constant offsets (notice that they don't have to be sequential - anything
> will go) - too bad,
[ ... we'll have to fix rm. ...]
probably should in any case, since what it's doing is probably a bug.
[.... However, I suspect that something like an address of entry might
be good enough. ...]
Al,
Please explain how I should implement this with an address of entry --
I'll get right on it. :-)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:28 EST