On Mon, Aug 04, 2014 at 11:31:57AM +0100, Peter Waller wrote: > Thanks Hugo, this is the most informative e-mail yet! (more inline) > > On 4 August 2014 11:22, Hugo Mills <h...@carfax.org.uk> wrote: > > > > * btrfs fi show > > - look at the total and used values. If used < total, you're OK. > > If used == total, then you could potentially hit ENOSPC. > > Another thing which is unclear and undocumented anywhere I can find is > what the meaning of `btrfs fi show` is. > > I'm sure it is totally obvious if you are a developer or if you have > used it for long enough. But it isn't covered in the manpage, nor in > the oracle documentation, nor anywhere on the wiki that I could find. > > When I looked at it in my problematic situation, it said "500 GiB / > 500 GiB". That sounded fine to me because I interpreted the output as > what fraction of which RAID devices BTRFS was using. In other words, I > thought "Oh, BTRFS will just make use of the whole device that's > available to it.". I thought that `btrfs fi df` was the source of > information for how much space was free inside of that.
That's actually pretty much accurate. The problem is that btrfs distinguishes between "space available for data" and "space available for metadata", and doesn't trade off one for the other once they've been allocated. The balance operation frees up some of the allocation, allowing the newly-freed space to be allocated again for something else. All of the information about the data/metadata split, and what's used out of that, is revealed by btrfs fi df. > > * btrfs fi df > > - look at metadata used vs total. If these are close to zero (on > > 3.15+) or close to 512 MiB (on <3.15), then you are in danger of > > ENOSPC. > > Hmm. It's unfortunate that this could indicate an amount of space > which is free when it actually isn't. That's why the 512 MiB block reserve was split out of metadata -- so that you don't look at metadata and say "oh, I've got half a gig free, that's OK". > > - look at data used vs total. If the used is much smaller than > > total, you can reclaim some of the allocation with a filtered > > balance (btrfs balance start -dusage=5), which will then give > > you unallocated space again (see the btrfs fi show test). > > So the filtered balance didn't help in my situation. I understand it's > something to do with the "5" parameter. But I do not understand what > the impact of changing this parameter is. It is something to do with a > fraction of something, but those things are still not present in my > mental model despite a large amount of reading. Is there an > illustration which could clear this up? The 5 is 5%. So, it'll only look at chunks which are less than 5% full. David Sterba published a patch that would balance the (approximately N) least-used chunks, which is a considerably more usable approach, but I don't know what happened to that one. > Among other things I also got the kernel stack trace I pasted at the > bottom of the first e-mail to this thread when I did the rebalance. OK, I'll go back and read that. You probably shouldn't have had it, though. :) > > This FAQ entry is pretty horrible, I'm afraid. I actually started > > rewriting it here to try to make it clearer what's going on. I'll try > > to work on it a bit more this week and put out a better version for > > the wiki. > > This is great to hear! :) > > Thanks for your response Hugo, that really cleared up a lot of mental > model problems. I hope the documentation can be improved so that > others can learn from my mistakes. I do try to work on it every so often. Note to self: win lottery, or get cloned. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- You stay in the theatre because you're afraid of having no --- money? There's irony...
signature.asc
Description: Digital signature
