> > 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?
Each directory dentry contains hash of items and pointer to inode. Each
directory has it's d_parent.
> 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/...
That is problem. If you create file in foo/, there could still be cached
"not found" response in foo/baz/qux/. When you delete the file in one
directory, it still exists in another. You can make directory hardlinks
with ext2ed and see what happens. Maybe you could solve it so that you go
through all aliases and invalidate cache entries when you change
something.
There is another problem: moving directory to itself. The dentry cache
contains test that prevents you from doing it, however if you disable the
test, you will create loop of dentries, each poining with d_parent to
other. An when something like d_path is called on it, it locks up.
Additionally, this dentry loop can't be freed; you would have to implement
garbage collection for dentry cache.
> 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?
It's not impossible, but you'll have to change a lot of things in VFS. It's
not just "write filesystem driver".
> > 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?
No. dentries are passed to almost all VFS calls, you can't avoid them.
Mikulas
-
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:22 EST