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.
I've looked through the FS code for 2.3.99 and there are some very
contorted implementations folks have used to handle this problem (like
building private directory caches with page pool memory), but none of
them are ideal for NWFS, but they all take up tons of processing cycles
needlessly for what's clearly an inadequacy in the dcache itself. What
would be ideal is for the owner of the dcache to pin the directory
entries in-place until rm -r completes a pass of the directory. This
would seem to be a GLIB bug, but I can see where the underlying dcache
should handle some of this for the apps.
There would seem to be know way for a file system driver to really know
when subsequent readdir() calls are from a single directory operation,
like rm -r.
Is there a way for me to keep a private pool of my own dcache entries
around and pin them? The existing calls just don't seem to support
this, the dentry overloading operations are very limited in scope.
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