|From:||Linus Torvalds <torvalds-AT-osdl.org>|
|Subject:||Re: silent semantic changes with reiser4|
|Date:||Sun, 29 Aug 2004 14:50:07 -0700 (PDT)|
|Cc:||Hans Reiser <reiser-AT-namesys.com>, flx-AT-msu.ru, Paul Jackson <pj-AT-sgi.com>, riel-AT-redhat.com, ninja-AT-slaphack.com, diegocg-AT-teleline.es, jamie-AT-shareable.org, christophe-AT-saout.de, vda-AT-port.imtp.ilyichevsk.odessa.ua, christer-AT-weinigel.se, spam-AT-tnonline.net, akpm-AT-osdl.org, wichert-AT-wiggy.net, jra-AT-samba.org, hch-AT-lst.de, linux-fsdevel-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org, flx-AT-namesys.com, reiserfs-list-AT-namesys.com|
On Sun, 29 Aug 2004 email@example.com wrote: > > A slew of cache coherency issues (and memory consumption on top of that). > Rigth now we have a signle dentry tree for all fs instances, no matter > how many times it and its subtrees are visible in the tree. Which, > obviously, avoids all that crap. As soon as we start trying to have > multiple trees over the same fs, we are in for a *lot* of fun. Al, I think you should make the argument a bit more specific, because I doubt a lot of people understand just what the problems are with aliased names. Just a few examples of the problems involved will illuminate things very well, I think. People who haven't been intimate with the name caches probably simply don't understand why you worry so much. I'll start out with some trivial examples, just to let Hans and others get an idea about what the issues are. I think examples of problems are often better ways to explain them than the abstract issues themselves. Aliases: let's say that you have filename "a" hard-linked to filename "b", and you have a directory structure of streams under there. So you have a/file1 a/dir1/file2 a/dir2/file3 and (through the hard-link with "b") you have aliases of all these same names available as "b/file1", "b/dir1/file2" etc). Now, imagine that you have two processes doing mv a/dir1 a/dir2/newdir and mv b/dir2 b/dir1/newdir at the same time. Both of them MUST NOT SUCCEED, for pretty obvious reasons (you'd have moved two directories within each other, and now neither would be accessible any more). How do you handle locking for this situation? Another interesting case is what happens when you have looked up and cache the filename "a/file1" and then another process does "rm b/file1". How do you update the _other_ cached copy, since they had two different names, but _both_ names went away at the same time. Also again, how do you handle locking? The general VFS layer has a lot of rules, and avoids these problems by simply never having aliases between two directories. If the same directory shows up multiple times (which can happen with bind mounts), they have the exact same dentry for the directory, it's just found through two different vfsmount instances. That's why vfsmounts exist - they allow the same name cache entry to show up in different places at the same time. So when we do a bind mount, and the same directory shows up under two different names "a" and "b", and we do a "rm b/file1", it _automatically_ disappears from "a/file1" too, simply by virtue of "a" and "b" literally being the same dentry. No aliasing ever happens, and this makes coherency and locking much easier (which is not to say that they are trivial, but they are pretty damn clear in comparison to the alternatives). What Al (and others) worries about is that the reiser4 name handling has _none_ of these issues figured out and protected against. You can protect against them by taking very heavy locks (you can trivially protect against all races by taking one large lock around any operation), but the fact is, that is just not an option for high-performance name lookup. These aliasing/locking rules need to be global and wll-though-out. Not just fix the two examples above, but be shown to be safe _in_general_. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds