Cc: Linus Torvalds <torvalds@...>, Christoph Hellwig <hch@...>, Hans Reiser <reiser@...>, <linux-fsdevel@...>, <linux-kernel@...>, Alexander Lyamin aka FLX <flx@...>, ReiserFS List <reiserfs-list@...>
On Thu, Aug 26, 2004 at 01:11:52AM +0100, Jamie Lokier wrote:
Yes - mountpoints can't be e.g. unlinked. Moreover, having directory
mounted on non-directory is also an interesting situation.
*Ugh*
What would happen if you open that directory or chdir there? If it's
"underlying file stays locked" - we are in even more obvious deadlocks.
We don't actually need a different fs - different vfsmount will do just fine.
You really don't want to lock mountpoint on path lookup, so I don't see
how that would be relevant - it's a hell to clean up, for one thing
(I've crossed ten mountpoints on the way, when do I unlock them and
how do I prevent deadlocks from that?) Besides, different namespaces
can have completely different mount trees, so tracking down all that
stuff would be hell in its own right.
The main issue I see with all schemes in that direction (and something
like that could be made workable) is the semantics of unlink() on
mountpoints. *Especially* with users being able to see attributes of
files they do not own (e.g. reiser4 mode/uid/gid stuff). Ability to
pin down any damn file on the system and make it impossible to replace
is not something you want to give to any user.