On 2015-12-09 16:48, S.J. wrote: >> 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. Unless things have changed significantly, changing the UUID on a BTRFS image is not anywhere near as simple as copying it with dd. The UUID gets used internally somehow, and changing it would require rewriting _all_ the metadata blocks.
smime.p7s
Description: S/MIME Cryptographic Signature
