Messages in this thread | | | Date | Fri, 22 Mar 2002 12:03:18 +0100 | Subject | Re: BUG REPORT: kernel nfs between 2.4.19-pre2 (server) and 2.2.21-pre3 (client) | From | Trond Myklebust <> |
| |
>>>>> " " == 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/
| |