Re: btrfs convert running out of space

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On Tue, Jan 20, 2015 at 02:41:13PM -0700, Chris Murphy wrote:
> On Tue, Jan 20, 2015 at 2:25 PM, Gareth Pye <gareth@cerberos.id.au> wrote:
> > Yeah, I have updated btrfs-progs to 3.18. While it is plausible that
> > the bug was created by using 3.12, none of the behavior has changed
> > now I'm using 3.18.
> >
> > I was experimenting with -dusage values to try and process the blocks
> > in a different order to see if that made any difference. It did let me
> > get through more of the file system before erroring but now it errors
> > on the first block it tries.
> >
> > Using "btrfs balance start -v -dusage=2 /data" cleans up all the empty
> > block groups that "btrfs balance start -v
> > -dconvert=raid1,soft,limit=10 /data" creates. I'm using limit=10 to
> > speed up testing, I have tried without it and it just takes longer to
> > complete and the whole time the RAID1 total sky rockets while the
> > RAID1 used doesn't move.
> 
> Sounds like during the conversion, no longer needed raid1 chunks
> aren't quickly deallocated so they can be used as raid10 chunks.
> There's been some work on this in the 3.19 kernel, it might be worth
> testing.
> 
> I'm not sure if the significance of the change from flags 17 to flags
> 65 right before the enospc errors. The spacing between flags 17 chunks
> is exactly 1GB whereas the spacing between the values reported for
> flags 65 vary a lot, one is a 12GB gap.

   flags 17 is RAID-1 data. 65 is RAID-10 data. If you're converting,
I think that's the type *before* it gets converted. The values for
block group type are in the ctree.h header (kernel and userspace),
BTRFS_BLOCK_GROUP_*.

   Hugo.

-- 
Hugo Mills             | Putting U back in Honor, Valor, and Trth.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: 65E74AC0          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]