Re: Please review and comment, dealing with btrfs full issues

[Duncan <1i5t5.duncan@cox.net>]

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