On 2014-08-04 06:31, 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. > You didn't look very hard then, because there is information in the manpage (oh wait, you mentioned Oracle, your probably using RHEL or CentOS, which are the last thing you should be using if you want to use stuff like BTRFS that is under heavy development), and it is documented on the wiki. > 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. > >> * 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 depends on what you mean by 'free'. > >> - 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? > Think of each chunk like a box, and each block as a block, and that you have two different types of block (data and metadata) and two different types of box (also data and metadata). The data boxes are four times the size of the metadata boxes, and they all have to fit in one really big container (the device itself). You can only put data blocks in the data boxs, and you can only put metadata blocks in metadata boxes. Say that in total, you can fit 128 data boxes in the large container, or you can replace one data box with up to four metadata boxes. Even though you may only have a few blocks in a given box, the box still takes up the same amount of space in the larger container. Thus, it's possible to have only a few blocks stored, but not be able to add any more boxes to the larger container. A balance operation is essentially the equivalent of taking all of the blocks of a given type, and fitting them into the smallest number of boxes possible. > 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. > >> 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. > -- > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
