Henk Slager posted on Thu, 12 May 2016 19:02:56 +0200 as excerpted: > Maybe you first want to test it on an overlay > of the device or copy the whole fs with dd. WARNING! Because btrfs can be multi-device, it needs some way to track which devices belong to each filesystem, and it uses filesystem UUID for this purpose. If you clone a filesystem (for instance using dd or lvm snapshotting, doesn't matter how) and then trigger a btrfs device scan, say by plugging in some other device with btrfs on it so udev triggers a scan, and the kernel sees multiple devices with the same filesystem UUID as a result, and one of those happens to be mounted, you can corrupt both copies as the kernel btrfs won't be able to tell them apart and may write updates to the wrong one. Prevention: Don't let btrfs see both copies at the same time. If you need to clone the filesystem, ideally make sure it's unmounted at the time, and detach either the original device or the clone immediately upon finishing the clone operation (before doing anything that might trigger a btrfs device scan, including device plugging that would trigger udev to trigger such a scan). Then simply keep them separate, only attaching one at a time and DEFINITELY never mounting the filesystem with both the clone and the original devices attached, so the kernel can't get confused and write to the wrong one because the other one is never there at the same time to provide the opportunity. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
