Messages in this thread | | | Date | Wed, 25 Aug 2004 22:25:18 +0100 | From | viro@parcelfa ... | Subject | Re: silent semantic changes with reiser4 |
| |
On Wed, Aug 25, 2004 at 02:00:01PM -0700, Linus Torvalds wrote: > Of course, the dcache introduces some new problems of its own wrt > directory aliasing, but I don't actually think that should be fundamental > either. Treating them more as a "static mountpoint" from an FS angle and > less as a traditional Unix hardlink should be doable, I'd have thought.
Yeah, if we ditch the "mountpoints are busy and untouchable" stuff. Which I'd love to, but it's a hell of a visible (and admin-visible) change.
FWIW, current deadlocks are unrelated to actual operation succeeding. Look: we have sys_link() making sure that parent of target is a directory (PATH_LOOKUP, in a "it has ->lookup()" sense), then locking target's parent, then checking that it has ->link() (everyone on reiser4 does) and then checking that source (old link to file) is *not* a directory (in S_ISDIR sense). Then we lock source.
Note that currently it's OK - we get "all non-directories are always locked after all directories". With filesystem that provides hybrid objects with non-NULL ->link() it's not true and we are in deadlock country. Before we get anywhere near fs code.
I'm not saying that this particular instance is hard to fix, but it wasn't even looked at. All it would take is checking the description of current locking scheme and looking through the proof of correctness (present in the tree). That's the first point where said proof breaks if we have hybrids. And it's what, about 4 screenfuls of text?
I have no problems with discussing such stuff and no problems with having it merged if it actually works. But let's start with something better than "let's hope nothing breaks if we just add such objects and do nothing else, 'cause hybridi files/directories are good, mmmkay?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |