On 2010-04-23, at 07:23, Theodore Tso wrote: > > 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? I'd say from the r/w LV in virtually all cases. We are safe from totally egregious errors, because the inode+generation will prevent totally incorrect files from being returned, but newer/older versions of the same file/director may be found. > 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. I think this may break things if we change the UUID when a snapshot is created, because we don't know what userspace might be using the UUID for. That said, I totally agree that returning the r/w LV makes sense. The LVM code itself understands which LV is the primary and which is the snapshot, so it likely means that the "lookup the UUID" code might need to be smarter. Probably the simplest thing is if a new filesystem is mounted, but a second filesystem with the same UUID is mounted that it is skipped. If we keep the UUID list in FIFO order, that should be sufficient to ensure that the "primary" version is returned first. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- 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
