On Wed, Dec 9, 2015 at 2:48 PM, S.J. <so...@anonym.com> 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.
That isn't what I'm suggesting. In the multiple device volume case where there are two exact (same UUID, same devid, same generation) instances of one of the block devices, Btrfs could randomly choose either one if it's an RO mount. It may very well be safer to just refuse to mount it with an error indicating the ambiguity, and suggesting the user explicitly specify the devices to use to assemble the volume, and if the generations differ on those chosen devices, at least warn about that also. > > 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. dd is not a copy operation. It's creating a 2nd original. You don't end up with an original and a copy (or clone). A copy or clone has some distinguishing difference. Volume UUID is used throughout Btrfs metadata, it's not just in the superblocks. Changing volume UUID requires a rewrite of all metadata. This is inefficient for two reasons: one dd copies unused sectors; two it copies metadata that will have to be completely rewritten by btrfstune to change volume UUID; and also the subvolume UUIDs aren't changed, so it's an incomplete solution that has problems (see other threads). If your workflow requires making an exact copy (for the shelf or for an emergency) then dd might be OK. But most often it's used because it's been easy, not because it's a good practice. Note that Btrfs is not unique, XFS v5 does a very similar thing with volume UUID as well, and resulted in this change: http://oss.sgi.com/pipermail/xfs/2015-April/041267.html Using dd also means the volume is offline. For even medium sized multiple device volumes, it's a huge penalty. dd does not scale. Using dd means source and destination physical configurations are identical (at least the number of devices and the data and metadata profiles) which I may not want or need for a clone. Maybe I want a 1x6TB clone for the 5x1TB raid5 volume. Even for an online full volume copy/clone of a 5x1TB raid5, moving all subvolume+snapshots to a new 3x4TB raid5 (or whatever), that could be hundreds of subvolumes to btrfs send/receive. OK yeah script it. But that's tedious even assuming I have a script friendly subvolume naming convention to get the send/receive order correct, which I don't. Anyway, I think it's a nice to have now, that'll eventually be a need. And dd is just totally disqualified outside of very specific edge case need. -- Chris Murphy -- 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
