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. -- Chris Murphy -- 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
