On Apr 22, 2010, at 2:15 PM, Aneesh Kumar K.V wrote: > > TODO: > I guess we would need to optimize how we get the vfsmount for the filesystem > uuid specified. Searching the file system list and task name space may be a big > overhead for each open by handle call. Something to consider is whether anything bad happens if there are multiple filesystems mounted with the same UUID. I can think of two ways this could happen. One is when we make a read-only LVM snapshot of a filesystem, and then mount it to back up a stable snapshot. This might happen if the sysadmin is trying to backup a SQL database, for example; the database gets frozen, we take a snapshot, and then we unfreeze the database and mount the snapshot. Now suppose we try to open-by-handle the mysql database --- should the system return the a file from the r/o frozen snapshot, or from the r/w file system? The second case is that there are people, especially people playing games with virtualization, who copy file system images around, and then don't bother to use "tune2fs -U random" afterwards to make sure each file system gets its own unique UUID. I even have some vague memories that some distribution was thinking about copying an image-copy of a filesystem from a Live CD and then using resize2fs to re-inflate the fs image as a way of doing a quick-and-dirty install. So there might be a real risk that you might have multiple file systems that have diverged significantly from each other, but which have the same UUID. Something we might do is to add a check and refuse mounting file systems with duplicate UUID's, and changing the LVM snapshot code to do run some kind of hook after a snapshot which runs a "tune2fs -U random" on the snapshot. For r/o LVM snapshots, we could also put in a hack that if there are two file systems mounted, one r/o and one r/w, we return the r/w file system. That doesn't handle the case of a r/w mounted LVM snapshot, as well as other cases where we might have duplicate fs UUID's, though.... -- Ted -- 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
