[9fans] the futility of QTMOUNT

[9fans] the futility of QTMOUNT

[erik quanstrom]

i've been experimenting a bit with reexporting
namespaces that have remote elements.  sometimes
the remote machine goes away.  unfortunately
when this happens, the first process to wander
into the missing mount hangs up everything.  it
appears that exportfs defends against this; it
is designed to fork when it detects it is traversing
a mount point (exportsrv.c:652).  this test always
fails because QTMOUNT is never set.  it appears that this
bit is always clobbered when being passed up to
user space.  in tracking that down, i noticed that
fixmount traverses the mount point anyway, so
QTMOUNT, even if set, would be seen too late.

so should QTMOUNT be removed, or have i
missed something?

- erik

Re: [9fans] the futility of QTMOUNT

[erik quanstrom]

On Wed Dec  8 11:18:55 EST 2010, forsyth@terzarima.net wrote:
> QTMOUNT allows exportfs to detect an attempt to open a /srv file
> that has been opened and mounted somewhere on the system running exportfs
> (i'll refer to that as the `called system' and the client of exportfs as
> the `calling system').

exportfs never detects this bit being set.  i would expect the
type to be 90, not 80 in this example

; mkdir q; mount /srv/boot q; ls -qd q
(0000000000000001 48 80) q

if this isn't when QTMOUNT is set, when would it be set?
i can't find a single file in the system with qid.type&0x10.

- erik

Re: [9fans] the futility of QTMOUNT

[Charles Forsyth]

QTMOUNT allows exportfs to detect an attempt to open a /srv file
that has been opened and mounted somewhere on the system running exportfs
(i'll refer to that as the `called system' and the client of exportfs as
the `calling system').

exportfs opens the /srv file, mounts that file descriptor itself,
and then serves 9p itself to access the resulting name space,
when the caller mounts it (on the calling system), just as
if the caller had been able to open the /srv file directly to mount it
(on the calling system). that's needed because once a file is serving 9p,
it can't be read or written directly (see the CMSG flag on chans).

it isn't to do with exporting name spaces that contain remote elements.

Re: [9fans] the futility of QTMOUNT

[Charles Forsyth]

>exportfs never detects this bit being set.  i would expect the
>type to be 90, not 80 in this example ...

>; mkdir q; mount /srv/boot q; ls -qd q
>(0000000000000001 48 80) q

i wouldn't! it's not set on the *mounted* file system in the scope of exportfs
but on the file (/srv/boot), once opened, that provides the 9p stream that the *client* of exportfs is opening and wants to mount.

it's typically $wsys in a cpu window, such as /mnt/term/srv/rio.forsyth.5

you can only see the bit on the qid you get from fstat, which is what exportfs does.