I'm catching up with archives and found a thread on cloning and wanted to point out that in particular on Btrfs this can be a problem: "Do not make a block-level copy of a btrfs filesystem to a block device, and then try to mount either the original or the copy while both are visible to the same kernel." https://btrfs.wiki.kernel.org/index.php/Gotchas The same problem applies to LVM snapshots (thick or thin). And likely similar problems apply to ext4 and XFS when using metadata checksumming. This isn't the default yet in ext4, but is the default with XFS format v5 starting with xfsprogs 3.2. btrfs-progs 4.1 now has a way to change the fs volume UUID. So after cloning if there is *any* possibility the two file systems will be visible to the kernel at the same time while one will be mounted, first it's best to change the UUID on one of them. This will take a while as the fs volume UUID is used constantly in the metadata format. In effect the whole fs (minus data) has to be read and written. There might still be bugs, but another way to clone a Btrfs volume is the seed device. Make A a seed device, and it mounts read-only, add a new device to the volume, then umount and remount, and it mounts read-write, then delete the seed device and data is migrated to the new device. But also, the UUID is unique on the new device. After it's completely, the seed device can be made a non-seed volume again (no longer mounts read only). Just an idea. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org