Hello Hugo- Thanks for the helpful explanation. This is what I assumed was happening and it is great to have a clarification. More comments inline. On Tue, Apr 29, 2014 at 3:21 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > The only solution that there is right now is, "don't do that". This use case, attaching an old block device for recovery or debugging, is common on a majority of the "cloud" platforms. And starting from an identical btrfs UUID is common with the prevalence of the "install, snapshot and replicate the VM" model. So, this leaves us with two options as I can see: 1. mkfs on first boot of an instance and copy any files over 2. rewrite the UUID on first boot of an instance > btrfs basically assumes that if several block devices have the same > UUID in their btrfs superblocks, they're different parts of the same > filesystem. If they're actually clones of the same filesystem, then it > has problems, and can _really_ screw things up, as you've discovered. Best guess: would a mkfs and copy or this tree walk and write be more expensive? Say I have 40 megabytes of initial data on the btrfs that would need to be copied in case 1. Thanks! Brandon -- 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
