On Thu, Jan 13, 2000 at 12:19:17AM +0100, Mikulas Patocka wrote:
> It won't work. dentry cache expects directory structure as tree. A lot of
> lockups or hanging references will happen when you create directory loop.
I don't really know what the dentry cache is (that's part of my
problem: I used to know a bit how the Linux filesystem worked, but
that was in the 2.0 times when there was no dentry cache). But I
assume 'dentry' stands for directory entry, and this is a cache to
speed up the filename->inode translation (lookup, rather).
How is it organized? The fact that the filesystem is liable to
contain wild loops doesn't mean that the cache must do so. For
example, if foo/ contains baz/ and baz/ contains qux/ that is the same
inode as the original foo/, the paths foo/ and foo/baz/qux/ point to
the same inode, but they can be cached separately - or can they? I
don't know what I'm talking about, of course. But the basic idea,
somehow, would be that the dentry cache, and perhaps the entire VFS,
need not know that foo/ and foo/baz/qux/ are the same - only I
(i.e. the gcfs) need to know that. (A mathematician would say this by
pointing out that the fundamental cover of any graph is a tree. Never
mind, just ranting.) But then the question is whether it will be a
problem that entries magically appear in foo/ when entries are added
in foo/baz/qux/...
The filesystem strikes. --more-- I feel confused.
To summarize: given that point I'm confusedly trying to make, do you
think it's hopeless anyway?
> You can try implementing it for 2.0 kernels - there is no dcache, and so
> directory anomalies shouldn't cause much trouble.
Or isn't there a way to tell the VFS not to cache anything from my
filesystem?
--
David A. Madore
(david.madore@ens.fr,
http://www.eleves.ens.fr:8080/home/madore/ )
-
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 : Sat Jan 15 2000 - 21:00:21 EST