Re: silent semantic changes with reiser4

[viro]

[reposted in thread]

On Thu, Aug 26, 2004 at 11:46:33AM -0700, Linus Torvalds wrote:
> Note that we could try this out with existing filesystems with very 
> minimal changes:
> 
>  - make directory bind mounts work on top of files ("graft_tree()")
>  - make open_namei() and friend _not_ do the mount-point following for the 
>    last component if it's a non-directory.
>  - probably some trivial fixups I haven't thought about. There might be 
>    some places that use "S_ISDIR()" to check for whether something can be 
>    looked up, but the main path walking already just checks whether there
>    is a ".lookup" operation or not.
> 
> This would already allow people to "try out" how different applications 
> would react to a file that can show up both as a directory and a file. The 
> patch might end up being less than 25 lines or so, the difficulty is in 
> finding all the right places.

The real issue is what to do with unlink() et.al. on these guys.  Note
that "unlink is OK if all we have there is a bunch of directory mounts"
won't work well - we have no good way to check that condition.

Even funnier one is what we do if we have directory mounted there *and*
have something mounted on stuff in that directory.

Yes, that's one of the probable directions for such stuff, but there's a
lot of fun semantics questions and answers to them will matter a lot.

Hey, if we lose the "can't unlink/rmdir/rename over something that is
a mountpoint in other life" - I'm happy and we can get a lot of much
more interesting stuff to work.  It will take some work (e.g. making
sure we can find all vfsmounts over given mountpoint and sorting out
the locking issues, which won't be trivial), but the main obstacle in
that direction is not in architecture - it's in SuS and tradition; as
the matter of fact, our life would be much easier if we stopped trying
to give -EBUSY here and just dissolved all subtrees mounted on anything
that has that dentry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/