On 2014-02-10 08:41, Brendan Hide wrote: > On 2014/02/10 04:33 AM, Austin S Hemmelgarn wrote: >> <snip> >> Apparently, trying to use -mconvert=dup or -sconvert=dup on a >> multi-device filesystem using one of the RAID profiles for metadata >> fails with a statement to look at the kernel log, which doesn't show >> anything at all about the failure. > ^ If this is the case then it is definitely a bug. Can you provide some > version info? Specifically kernel, btrfs-tools, and Distro. In this case, btrfs-progs 3.12, kernel 3.13.2, and Gentoo. >> <snip> it appears >> that the kernel stops you from converting to a dup profile for metadata >> in this case because it thinks that such a profile doesn't work on >> multiple devices, despite the fact that you can take a single device >> filesystem, and a device, and it will still work fine even without >> converting the metadata/system profiles. > I believe dup used to work on multiple devices but the facility was > removed. In the standard case it doesn't make sense to use dup with > multiple devices: It uses the same amount of diskspace but is more > vulnerable than the RAID1 alternative. >> <snip> Ideally, this >> should be changed to allow converting to dup so that when converting a >> multi-device filesystem to single-device, you never have to have >> metadata or system chunks use a single profile. > This is a good use-case for having the facility. I'm thinking that, if > it is brought back in, the only caveat is that appropriate warnings > should be put in place to indicate that it is inappropriate. > > My guess on how you'd like to migrate from raid1/raid1 to single/dup, > assuming sda and sdb: > btrfs balance start -dconvert=single -mconvert=dup / > btrfs device delete /dev/sdb / > Ideally, yes. The exact command I tried to use was: btrfs balance start -dconvert=single -mconvert=dup -sconvert=dup -f -v / Trying again without the system chunk conversion also failed. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
