Hans Reiser wrote: > David Masover wrote: > > >>Hans Reiser wrote: >> >> >> >>>Hubert Chan wrote: >>> >>> >>> >>> >>> >>>>On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Hubert Chan wrote: >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>>>>The main thing blocking file-as-dir is that there are some >>>>>>locking(IIRC?) issues. And, of course, some people wouldn't want it >>>>>>to be merged into the mainline kernel. (Of course, the latter >>>>>>doesn't prevent Namesys from maintaining their own patches for people >>>>>>to play around with.) >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >>>>>What's the locking issue? I think that was more about transactions... >>>>> >>>>> >>>>> >>>>> >>>> >>>>It was whatever was Al Viro's (technical) complaint about file-as-dir. >>>>I don't remember exactly what it was. The technical people know what it >>>>is (and the Namesys guys are probably working on it), and the exact >>>>issue doesn't concern us non-technical people that much, so I don't feel >>>>like looking it up. But if you want to, just look for Al Viro's message >>>>in this thread. >>>> >>>> >>>> >>>> >>>> >>> >>>Cycle detection when hard links to directories are allowed. There is a >>>debate over whether cycle detection is feasible that can only be >>>resolved by working code or a formal proof that it is not >>>computationally feasible. >>> >>> >> >>Ah. But then, one solution was to avoid the issue at all, and have the >>directory inside a file act as a mountpoint. After all, mount --bind >>doesn't cause problems... >> >> > > Can you explain this idea at greater length?
Just don't allow user-created hardlinks inside either metafs (/meta) or the magical meta directory inside files. In order to do that, one way would be to have "file/..." appear as a mountpoint. I don't know if this is feasable, performance-wise, but I think it would work. >>Hey! This sounds like metafs (/meta) already! I wonder if we can do >>file-as-dir in /meta, and just not support user-created hardlinks there? >>(other than creating brand-new files, of course...) This is still my preferred solution, because it's not any harder or less efficient to develop new apps based on metafs than on file-as-dir, but it means that old apps will see something *entirely* POSIX-compliant, and the strangeness will be confined to /meta. Basically, you have to allow hardlinks in /meta, in case some plugin wants to do that, but if you have files that are also directories, you also have to make sure that users can't create hardlinks. I don't think this would be particularly hard, though. Pretend it's a read-only filesystem unless the user is doing something safe, like creating a brand-new file, deleting an old one, or modifying the contents of an existing one, all assuming that the plugin responsible for the file/directory you're doing this in allows it. But then, if we're doing metafs, I don't think you need file-as-directory, and certain existing tools that we'd like to be able to point at metafs might not like file-as-directory anyway. Now, can anyone think of a situation where we want user-created hardlinks inside metadata? More importantly, what do we do about it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/