From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed,  8 Dec 2010 08:16:50 -0500
To: 9fans@9fans.net
Message-ID: <066486e67299fd5a3f2605c8df948616@plug.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] the futility of QTMOUNT
Topicbox-Message-UUID: 89625fa8-ead6-11e9-9d60-3106f5b1d025

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