>AFAIU, NFS uses major/minor numbers of block device to create >FSID and uses it as part of file handle. And the idea behind >this is that if the server rebooted unexpectedly, and then >exported a _different_ file-system to the same path, the client >would notice this because the FSID part of file handle would >change. After the reboot, the client would not notice that that the server had exported a different filesystem to the same path because the client has already done the lookup; he has no reason to do it again. (If the original file is still exported under a different name, the client will continue accessing the old file. If the original filesystem isn't exported at all anymore, the client's access via the old file handle fails and the client repeats the lookup and continues accessing the new file as if nothing had changed). The point of the FSID is simply that the file handle has to completely identify the file so the server knows which file to access. An NFS client request to read a file doesn't come with a file name; the file handle is all there is. If the filesystem lives on a disk device and you trust the disk device's major/minor number not to change across a reboot, major/minor number makes a good FSID. If not, you need something else, such as the filesystem UUID you propose. Having the system administrator manually identify the filesystem in a special namespace via fsid=5 in /etc/exports obviously doesn't have the same level of integrity, but it does solve the problem of not having any way to identify the filesystem at all. -- 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
