MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15515.3958.533172.840461@charged.uio.no>
Date: Fri, 22 Mar 2002 12:03:18 +0100
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@ton.iguana.be (Ton Hospel), linux-kernel@vger.kernel.org
Subject: Re: BUG REPORT: kernel nfs between 2.4.19-pre2 (server) and 2.2.21-pre3 (client) 
In-Reply-To: <24969.1016793219@redhat.com>
Reply-To: trond.myklebust@fys.uio.no
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Sender: linux-kernel-owner@vger.kernel.org

>>>>> " " == David Woodhouse <dwmw2@infradead.org> writes:

     > trond.myklebust@fys.uio.no said:
    >> As for re-exporting: that can be done pretty easily too unless
    >> of course you actually expect it to be reliable. The tough
    >> cookie is to get it to survive server reboots.

     > The problem here is that we're using the anonymous device which
     > the NFS mount happens to have as sb->s_dev as the device ID in
     > our exported file handles. We don't have to do that; we could
     > use something slightly more useful, based on the root fh we got
     > from the _real_ server, surely?
 
That is an issue, but it is really only a minor one.

The real problem is that whereas the tuple (sb->s_dev,i_ino) suffices
in order to be able to iget() a typical ext2 file, you require the the
tuple (sb->s_dev, 32/64 byte opaque filehandle) if you want to
iget() an NFS file.

Basically, if you want to be able to recover gracefully from the
situation in which the re-exporting server reboots, you would need to
compress the entire filehandle from the original server + the
sb->s_dev (in some manner that survives a reboot, I'll grant you) and
fit that into the filehandle that the NFS client uses.


To complicate matters a bit further, you have the fact that NFSv3
filehandles are 0-64 bytes long, and NFSv2 filehandles are always 32
bytes long...

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/