> 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/