E V posted on Tue, 25 Mar 2014 14:56:08 -0400 as excerpted: > Plenty of meta data space and such: > Metadata, RAID1: total=134.00GiB, used=87.27GiB > Metadata, single: total=8.00MiB, used=0.00 > > just seems to be some blocks that the profile covert fails on that a > regular balance process fine. This is using kernel 3.13.7 and > btrfs-progs 3.12. Any suggestions would be great, thanks, What about unallocated space, that is, the difference between total space and used space, per device, as reported by btrfs filesystem show? That's what btrfs balance uses, the unallocated space. Balance works on data, metadata or system chunks, but uses unallocated space to create the new chunks it then copies the data/metadata to from the old chunks, before freeing them. So if unallocated space drops too low, balance will fail with enospace errors. But you didn't post the unallocated space, you posted metadata space, which should stay just as it is (tho I guess some pointers will need rewritten as the data chunk they point to is rewritten), because you specified a -d/data balance, not metadata. That said, profile=raid0,convert=single, failing where a standard balance without the profile convert succeeds, is a bit strange. raid0-to-single conversion should use the same amount of space but be less picky about where it's located, so why it would enospace, where a standard balance (which should be more picky than conversion to single about where the new chunks get written, when it's replacing raid0 with raid0 without the conversion to single) succeeds, remains a good question indeed. -- 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 -- 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
