On Feb 18, 2014, at 2:55 PM, Hendrik Friedel <hend...@friedels.name> wrote:
> Hello, > > >> It looks like everything is single except for 4GB of data which is still >>> raid0. Weird. There should be a bunch of messages in dmesg during a >>> normal/successful balance, and either something mentioned or missing >>> might provide a clue why some chunks weren't converted. > > >> Agreed. > > time ./btrfs balance start -dconvert=single,soft /mnt/BTRFS/Video/ > ERROR: error during balancing '/mnt/BTRFS/Video/' - No space left on device > There may be more info in syslog - try dmesg | tail > > real 0m23.803s > user 0m0.000s > sys 0m1.070s > > dmesg: > [697498.761318] btrfs: relocating block group 19874593112064 flags 9 > [697507.614140] btrfs: relocating block group 19715679322112 flags 9 > [697516.218690] btrfs: 2 enospc errors during balance You could try mounting with enospc_debug option and retrying, see if there's more information dmesg. But the large number of problems btfs check is finding, it may not be possible to move these 4GB. So hopefully the data you need is already backed up and you can just blow this file system away. Or if you're looking to keep testing, you could try building a btrfs-next kernel to see if it can unwind this problem. And for btrfs-progs there's David Sterba's integration branch, is probably the most appropriate. But I haven't kept track of fsck related patches since v3.12 was released so I don't know if there's something newer that applies. Which is why it's easier to just back up and blow this thing away entirely and start from scratch. Chris Murphy -- 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
