On Sun, Dec 6, 2015 at 7:34 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote:
> But just as you mentioned, it *IS* a real problem, and we should need to > enhance it. LVM sorta avoids the problem, because its snapshots aren't active by default so the underlying fs (and its UUID and superblock) don't appear to the kernel. In no order: 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. > I'd like to see how LVM/DM behaves first, at least as a reference if they > are really so safe. > For example, I have a whole disk as the following configuration: > > 0 10G 20G > | test_lv | | > ---------------- > | test_vg | > ----------------------- > | test_pv | > ----------------------- > | /dev/sdb | > ----------------------- > > If I did a dd copy of /dev/sdb to /dev/sdc, > what will pv/vg/lv rescan show if test_pv/vg/lv is already active? > And what will rescan show if they are not active? Or after a reboot? I haven't tested it recently but my recollection is that it flat refused to activate the VG/LV whenever two PV's with identical UUIDs were visible, that is, it would not use either PV until I resolved the ambiguity by physical PV removal, or using pvremove, or using wipefs. -- 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
