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@xxxxxxxxxxxxxx> 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:
signature.asc
Description: Digital signature
