On Thu, Dec 10, 2015 at 07:08:51AM -0500, Austin S Hemmelgarn wrote: > 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.
Indeed, but there is now a tool to do that. :) (btrfstune -u or -U) Hugo. -- Hugo Mills | Go not to the elves for counsel, for they will say hugo@... carfax.org.uk | both no and yes. http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
