On 11/08/2012 08:50 PM, J. Bruce Fields wrote: > The protocol references files on the filesystem using filehandles. The > linux NFS server generates a filehandle that has a part which identifies > the filesystem and a part which identifies the particular file (usually > an inode and generation number). sounds comprehensible. > The filesystem part in your case is probably a uuid which is part of > what's copied when you snapshot (as are all the inode numbers). So > you're left with filehandles that are the same for the two filesystems. i can confirm that both filesystems by design have the same UUID. > You can tell it to instead to use whatever integer you'd like using the > "fsid=" export option (just don't used fsid=0, which has a special > meaning). tried that already (using 2 and 6) and it did not work. > Or, probably better--you should be able to be able to modify the uuid... > Looking at the tune2fs man page, I think it should be: > > tune2fs -U random /dev/vg0/nfssnapshot we're using xfs in production, but it has some similar tool. i'll look into it tomorrow, because it doesn't works out that quick. my problem with this issue is that we're running this setup for over two years now and the NFS server wasn't rebooted since half a year and the bug just showed recently. while we didn't had safety-checks in place to be sure what we mounted, we regularly simulated file-operations on a snapshot which never affected the origin volume. pille -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
