Brendan Hide posted on Tue, 06 May 2014 18:30:31 +0200 as excerpted: >> So in my case when I hit that case, I had to use dusage=0 to recover. >> Anything above that just didn't work. > > I suspect when using more than zero the first chunk it wanted to balance > wasn't empty - and it had nowhere to put it. Then when you did dusage=0, > it didn't need a destination for the data. That is actually an > interesting workaround for that case. I've actually used -Xusage=0 (where X=m or d, obviously) for exactly that. If every last bit of filesystem is allocated so another chunk simply cannot be written in ordered to rewrite partially used chunks into, BUT the spread between allocated and actually used is quite high, there's a reasonably good chance that at least one of those allocated chunks is entirely empty, and -Xusage=0 allows returning it to the unallocated pool without actually requiring a new chunk allocation to do so. With luck, that will free at least one zero-usage chunk (two for metadata dup, but it would both allocate and return to unallocated in pairs as so it balances out), allowing the user to rerun balance, this time with a higher -Xusage=. The other known valid use-case for -Xusage=0 is when freeing the extraneous zero-usage single-mode chunks first created by mkfs.btrfs as part of the mkfs process, so they don't clutter up the btrfs filesystem df output. =:^) -- 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
