On 02/10/2014 08:41 AM, 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.
>> <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 /
>
Do you happen to know which git repository and branch is preferred to
base patches on? I'm getting ready to write one to fix this, and would
like to make it as easy as possible for the developers to merge.
--
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
