1. better practices, we really need to tell users, and documentation writers, that using dd (or variant) to copy Btrfs volumes has a consequence and should not be used to make copies.
2. Btrfs needs a better way to make a copy of a volume when there are snapshots (including even rw snapshots); e.g. permit send/receive to work on rw snapshots if the fs is ro mounted; e.g. a way to do "recursive" send/receive.
3. Some way to fail gracefully, when there's ambiguity that cannot be resolved. Once there are duplicate devs (dd or lvm snapshots, etc) then there's simply no way to resolve the ambiguity automatically, and the volume should just refuse to rw mount until the user resolves the ambiguity. I think it's OK to fallback to ro mount (maybe) by default in such a case rather than totally fail to mount.
About 3: RO fallback for the second device/partitions is not good. It won't stop confusing the two partitions, and even if both are RO, thinking it's ok to read and then reading the wrong data is bad. About 1 and 2 ... if 3 gets fulfilled, why? DD itself is not a problem "if" the UUID is changed after it (which is a command as simple as dd), and if someone doesn't know that, he/she will notice when mount refuses to work because UUID duplicate. PS: Kudos to C.A. Mitterer for discovering that problem -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
