On Wed, Jun 17, 2009 at 07:03:43PM +0100, David Howells wrote:
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > What _I_ mean is that THIS IS IMPOSSIBLE TO DO FROM USER SPACE!
> >
> > Try it. Not doable. User space simply doesn't know enough, and has
> > fundamental races with mount/umount.
>
> Ummm... I'm not sure I completely agree. If you've managed to open, say,
> "/afs", where's the race with mount/umount? You've got a file descriptor you
> can use as a handle. Yes, you have to check that it's actually an inode of
> your fs, but that's not exactly difficult, and that's not going to change just
> because someone unmounts it or mounts over it whilst you've got it open.
I believe Linus is arguing that in the general case, it's impossible
to open the mountpoint of an arbitrarily mounted filesystem. David,
you're arguing that by convention the afs root is *always* in /afs,
and that the afs utilities will always simply open "/afs", and thus
it's not hard to find the mount point, since afs works by having a
single top-level static mount point --- and AFS hides the
lookup of what volume server you might need to go to when you open
/afs/athena.mit.edu/user/t/y/tytso versus /afs/andrew.cmu.edu/usr/shadow.
There are no magic "automounts" such that OS won't know that
user.tytso AFS Volume in the athena.mit.edu AFS cell is at
/afs/athena.mit.edu/user/t/y/tytso, so the only "mountpoint" that
exists as far as AFS is concerned is at /afs --- and that in the AFS
world, it's essentially a universal convention that AFS pathnames
begin with "/afs", and so the AFS filesystem will always be mounted in /afs.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
