On Sat, Feb 20, 2010 at 11:58:34AM -0700, Andreas Dilger wrote: > Without the handle identifying the filesystem in some way this is > mostly useless. Encoding the device number would be a simple (though > non-robust) way to do this, a better way would be with the filesystem > UUID and adding an in-kernel UUID->sb mapping function (which is > useful for other things as well). I certainly have one use in mind for having a static sb->ID mapping inside the FS driver. It seems like a more reliable way to do NFS serving of anything more complicated than a standard disk-based local filesystem. In particular, it would be nice to be able to serve some synthetic or network/cluster based FS over NFS and have the file handles be consistent across multiple machines for failover purposes. Currently specifying the fsid in the exports table is the only logical way to force this, but that's extra manual work. I haven't started writing any code to do this, but I have looked at the current NFS FH code and it seems like it should be reasonable to add a new set of methods to allow another FS specific field. The hardest part seems to be holding the size down to the old NFS v2 protocol limits. Brad Boyer flar@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
