linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* btrfs balance start -dconvert=raid5 on raid1 not converting to raid5
@ 2015-04-25  2:47 None None
  2015-04-25  3:00 ` Omar Sandoval
  0 siblings, 1 reply; 5+ messages in thread
From: None None @ 2015-04-25  2:47 UTC (permalink / raw)
  To: linux-btrfs

I tried to convert my btrfs from raid1 to raid5 but after the balance command it's still raid1.
Also for raid56 the wiki says "Parity may be inconsistent after a crash (the "write hole")"
does that mean if I convert metadata to raid5/6 and the parity becomes inconsistent my btrfs will be lost?

Kernel is v4.0 on debian/sid
The filesystem was created with nodesize 8k if I remember correctly
Mount options for /srv/ noatime,nodev,space_cache,subvol=@
No snapshots and only a few subvolumes
Free space is ~450GiB

To convert the data profile to raid5 (with btrfs-progs v3.17) I did
btrfs balance start -v -dconvert=raid5 /srv/
but after the the command was done (after 10 days)
btrfs fi sho /srv/
still shows data as raid1, free space is also what would be expected for raid1
no errors, no problems, no raid5


So I compiled the newer btrfs-progs v3.19.1 and did (I also tried raid6, same result still raid1)
btrfs balance start -v -dconvert=raid5 -dlimit=1 /srv/
Dumping filters: flags 0x1, state 0x0, force is off
  DATA (flags 0x120): converting, target=128, soft is off, limit=1
Done, had to relocate 1 out of 12071 chunks

dmesg shows only this, no errors
[170427.207107] BTRFS info (device sdj): relocating block group 65294058848256 flags 17
[170461.591056] BTRFS info (device sdj): found 129 extents
[170476.270765] BTRFS info (device sdj): found 129 extents

btrfs fi sho /srv/
shows all data as raid1


btrfs fi sho
Label: none  uuid: xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx
        Total devices 9 FS bytes used 11.78TiB
        devid    1 size 2.73TiB used 2.62TiB path /dev/sdh
        devid    2 size 2.73TiB used 2.62TiB path /dev/sdj
        devid    3 size 2.73TiB used 2.62TiB path /dev/sdg
        devid    4 size 2.73TiB used 2.62TiB path /dev/sdi
        devid    5 size 2.73TiB used 2.62TiB path /dev/sdf
        devid    6 size 2.73TiB used 2.62TiB path /dev/sde
        devid    7 size 2.73TiB used 2.62TiB path /dev/sdc
        devid    9 size 2.73TiB used 2.62TiB path /dev/sdd
        devid   10 size 2.73TiB used 2.62TiB path /dev/sda

btrfs-progs v3.19.1


btrfs fi df /srv/
Data, RAID1: total=11.76TiB, used=11.76TiB
System, RAID1: total=32.00MiB, used=1.62MiB
Metadata, RAID1: total=17.06GiB, used=14.85GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs balance start -dconvert=raid5 on raid1 not converting to raid5
  2015-04-25  2:47 btrfs balance start -dconvert=raid5 on raid1 not converting to raid5 None None
@ 2015-04-25  3:00 ` Omar Sandoval
  2015-04-25  3:56   ` None None
  0 siblings, 1 reply; 5+ messages in thread
From: Omar Sandoval @ 2015-04-25  3:00 UTC (permalink / raw)
  To: None None; +Cc: linux-btrfs

On Sat, Apr 25, 2015 at 04:47:31AM +0200, None None wrote:
> I tried to convert my btrfs from raid1 to raid5 but after the balance command it's still raid1.
> Also for raid56 the wiki says "Parity may be inconsistent after a crash (the "write hole")"
> does that mean if I convert metadata to raid5/6 and the parity becomes inconsistent my btrfs will be lost?
> 
> Kernel is v4.0 on debian/sid
> The filesystem was created with nodesize 8k if I remember correctly
> Mount options for /srv/ noatime,nodev,space_cache,subvol=@
> No snapshots and only a few subvolumes
> Free space is ~450GiB
> 
> To convert the data profile to raid5 (with btrfs-progs v3.17) I did
> btrfs balance start -v -dconvert=raid5 /srv/
> but after the the command was done (after 10 days)
> btrfs fi sho /srv/
> still shows data as raid1, free space is also what would be expected for raid1
> no errors, no problems, no raid5
> 
> 
> So I compiled the newer btrfs-progs v3.19.1 and did (I also tried raid6, same result still raid1)
> btrfs balance start -v -dconvert=raid5 -dlimit=1 /srv/
> Dumping filters: flags 0x1, state 0x0, force is off
>   DATA (flags 0x120): converting, target=128, soft is off, limit=1
> Done, had to relocate 1 out of 12071 chunks
> 
> dmesg shows only this, no errors
> [170427.207107] BTRFS info (device sdj): relocating block group 65294058848256 flags 17
> [170461.591056] BTRFS info (device sdj): found 129 extents
> [170476.270765] BTRFS info (device sdj): found 129 extents
> 
> btrfs fi sho /srv/
> shows all data as raid1
> 
> 
> btrfs fi sho
> Label: none  uuid: xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx
>         Total devices 9 FS bytes used 11.78TiB
>         devid    1 size 2.73TiB used 2.62TiB path /dev/sdh
>         devid    2 size 2.73TiB used 2.62TiB path /dev/sdj
>         devid    3 size 2.73TiB used 2.62TiB path /dev/sdg
>         devid    4 size 2.73TiB used 2.62TiB path /dev/sdi
>         devid    5 size 2.73TiB used 2.62TiB path /dev/sdf
>         devid    6 size 2.73TiB used 2.62TiB path /dev/sde
>         devid    7 size 2.73TiB used 2.62TiB path /dev/sdc
>         devid    9 size 2.73TiB used 2.62TiB path /dev/sdd
>         devid   10 size 2.73TiB used 2.62TiB path /dev/sda
> 
> btrfs-progs v3.19.1
> 
> 
> btrfs fi df /srv/
> Data, RAID1: total=11.76TiB, used=11.76TiB
> System, RAID1: total=32.00MiB, used=1.62MiB
> Metadata, RAID1: total=17.06GiB, used=14.85GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

This is a known bug in v4.0. I sent in a patch [1] to revert the commit
that caused the regression, but it didn't get any response. You could
apply that or just revert 2f0810880f08 ("btrfs: delete chunk allocation
attemp when setting block group ro") to fix your problem for now.

[1]: https://patchwork.kernel.org/patch/6238111/

-- 
Omar

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs balance start -dconvert=raid5 on raid1 not converting to raid5
  2015-04-25  3:00 ` Omar Sandoval
@ 2015-04-25  3:56   ` None None
  2015-04-25  8:18     ` Duncan
  0 siblings, 1 reply; 5+ messages in thread
From: None None @ 2015-04-25  3:56 UTC (permalink / raw)
  To: Omar Sandoval; +Cc: linux-btrfs

 
Omar Sandoval <osandov@osandov.com> írta:
>On Sat, Apr 25, 2015 at 04:47:31AM +0200, None None wrote:
>> I tried to convert my btrfs from raid1 to raid5 but after the balance command it&#39;s still raid1.
>> Also for raid56 the wiki says "Parity may be inconsistent after a crash (the "write hole")"
>> does that mean if I convert metadata to raid5/6 and the parity becomes inconsistent my btrfs will be lost?
>> 
>> Kernel is v4.0 on debian/sid
>> The filesystem was created with nodesize 8k if I remember correctly
>> Mount options for /srv/ noatime,nodev,space_cache,subvol=@
>> No snapshots and only a few subvolumes
>> Free space is ~450GiB
>> 
>> To convert the data profile to raid5 (with btrfs-progs v3.17) I did
>> btrfs balance start -v -dconvert=raid5 /srv/
>> but after the the command was done (after 10 days)
>> btrfs fi sho /srv/
>> still shows data as raid1, free space is also what would be expected for raid1
>> no errors, no problems, no raid5
>> 
>> 
>> So I compiled the newer btrfs-progs v3.19.1 and did (I also tried raid6, same result still raid1)
>> btrfs balance start -v -dconvert=raid5 -dlimit=1 /srv/
>> Dumping filters: flags 0x1, state 0x0, force is off
>>   DATA (flags 0x120): converting, target=128, soft is off, limit=1
>> Done, had to relocate 1 out of 12071 chunks
>> 
>> dmesg shows only this, no errors
>> [170427.207107] BTRFS info (device sdj): relocating block group 65294058848256 flags 17
>> [170461.591056] BTRFS info (device sdj): found 129 extents
>> [170476.270765] BTRFS info (device sdj): found 129 extents
>> 
>> btrfs fi sho /srv/
>> shows all data as raid1
>> 
>> 
>> btrfs fi sho
>> Label: none  uuid: xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxxx
>>         Total devices 9 FS bytes used 11.78TiB
>>         devid    1 size 2.73TiB used 2.62TiB path /dev/sdh
>>         devid    2 size 2.73TiB used 2.62TiB path /dev/sdj
>>         devid    3 size 2.73TiB used 2.62TiB path /dev/sdg
>>         devid    4 size 2.73TiB used 2.62TiB path /dev/sdi
>>         devid    5 size 2.73TiB used 2.62TiB path /dev/sdf
>>         devid    6 size 2.73TiB used 2.62TiB path /dev/sde
>>         devid    7 size 2.73TiB used 2.62TiB path /dev/sdc
>>         devid    9 size 2.73TiB used 2.62TiB path /dev/sdd
>>         devid   10 size 2.73TiB used 2.62TiB path /dev/sda
>> 
>> btrfs-progs v3.19.1
>> 
>> 
>> btrfs fi df /srv/
>> Data, RAID1: total=11.76TiB, used=11.76TiB
>> System, RAID1: total=32.00MiB, used=1.62MiB
>> Metadata, RAID1: total=17.06GiB, used=14.85GiB
>> GlobalReserve, single: total=512.00MiB, used=0.00B
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>This is a known bug in v4.0. I sent in a patch [1] to revert the commit
>that caused the regression, but it didn&#39;t get any response. You could
>apply that or just revert 2f0810880f08 ("btrfs: delete chunk allocation
>attemp when setting block group ro") to fix your problem for now.
>
>[1]: https://patchwork.kernel.org/patch/6238111/
>
>-- 
>Omar

I'll give it a try, thanks for the fast reply.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs balance start -dconvert=raid5 on raid1 not converting to raid5
  2015-04-25  3:56   ` None None
@ 2015-04-25  8:18     ` Duncan
  2015-04-25  9:39       ` Omar Sandoval
  0 siblings, 1 reply; 5+ messages in thread
From: Duncan @ 2015-04-25  8:18 UTC (permalink / raw)
  To: linux-btrfs

None None posted on Sat, 25 Apr 2015 05:56:50 +0200 as excerpted:

> Omar Sandoval <osandov@osandov.com> írta:
>>On Sat, Apr 25, 2015 at 04:47:31AM +0200, None None wrote:
>>> I tried to convert my btrfs from raid1 to raid5 but after the balance
>>> command it&#39;s still raid1.
>>
>>This is a known bug in v4.0. I sent in a patch [1] to revert the commit
>>that caused the regression, but it didn&#39;t get any response. You
>>could apply that or just revert 2f0810880f08 ("btrfs: delete chunk
>>allocation attemp when setting block group ro") to fix your problem for
>>now.
>>
>>[1]: https://patchwork.kernel.org/patch/6238111/
>>
> I'll give it a try, thanks for the fast reply.

FWIW, while I've not been following this /too/ closely (as my use-case 
has zero reason to do a convert), I believe I saw Chris and others 
discussing the patch, and I /think/ it (or an update) may have actually 
been in the 4.1 upgrade window pull.

Presumably they'll queue it for stable too, once it's in 4.1 (or whatever 
if I'm wrong on the 4.1 pull).

A verify either way would be useful, but as I said I've not been 
following it /too/ closely, and I'm still on 4.0 here, so...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: btrfs balance start -dconvert=raid5 on raid1 not converting to raid5
  2015-04-25  8:18     ` Duncan
@ 2015-04-25  9:39       ` Omar Sandoval
  0 siblings, 0 replies; 5+ messages in thread
From: Omar Sandoval @ 2015-04-25  9:39 UTC (permalink / raw)
  To: Duncan; +Cc: linux-btrfs

On Sat, Apr 25, 2015 at 08:18:30AM +0000, Duncan wrote:
> None None posted on Sat, 25 Apr 2015 05:56:50 +0200 as excerpted:
> 
> > Omar Sandoval <osandov@osandov.com> írta:
> >>On Sat, Apr 25, 2015 at 04:47:31AM +0200, None None wrote:
> >>> I tried to convert my btrfs from raid1 to raid5 but after the balance
> >>> command it&#39;s still raid1.
> >>
> >>This is a known bug in v4.0. I sent in a patch [1] to revert the commit
> >>that caused the regression, but it didn&#39;t get any response. You
> >>could apply that or just revert 2f0810880f08 ("btrfs: delete chunk
> >>allocation attemp when setting block group ro") to fix your problem for
> >>now.
> >>
> >>[1]: https://patchwork.kernel.org/patch/6238111/
> >>
> > I'll give it a try, thanks for the fast reply.
> 
> FWIW, while I've not been following this /too/ closely (as my use-case 
> has zero reason to do a convert), I believe I saw Chris and others 
> discussing the patch, and I /think/ it (or an update) may have actually 
> been in the 4.1 upgrade window pull.
> 
> Presumably they'll queue it for stable too, once it's in 4.1 (or whatever 
> if I'm wrong on the 4.1 pull).
> 
> A verify either way would be useful, but as I said I've not been 
> following it /too/ closely, and I'm still on 4.0 here, so...
> 

Just reproduced the bug on Chris' integration-4.1 branch, which appears
to have everything that was pulled for 4.1-rc1 plus some more. Maybe
you're thinking of the original bisect report [1]? I never saw anything
else come out of that.

[1]: http://thread.gmane.org/gmane.comp.file-systems.btrfs/43117

-- 
Omar

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-04-25  9:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-25  2:47 btrfs balance start -dconvert=raid5 on raid1 not converting to raid5 None None
2015-04-25  3:00 ` Omar Sandoval
2015-04-25  3:56   ` None None
2015-04-25  8:18     ` Duncan
2015-04-25  9:39       ` Omar Sandoval

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).