Re: filesystem full when it's not? out of inodes? huh?

[Daniel Lee <longinus00@gmail.com>]

On 02/26/2012 12:05 PM, Brian J. Murrell wrote:
> On 12-02-26 02:52 PM, Daniel Lee wrote:
>> What's mysterious about that?
> What's mysterious about needing to grow the filesystem to over 20GB to
> unpack 10MB of (small, so yes, many) files?
>> When you shrink it btrfs is going to throw
>> away unused data to cram it all in the requested space and you had empty
>> space that was taken up by the metadata allocation.
> The shrinking is secondary mystery.  It's the need for more than 20GB of
> space for less than 3GB of files that's the major mystery.
Several people in this list have already answered this question but here
goes.

Btrfs isn't like other more common filesystems where metadata is fixed
at filesystem creation. Rather, metadata allocations happen just like
data allocations do. Btrfs also tries to allocate metadata in big chunks
so it doesn't get fragmented and lead to slowdowns when doing something
like running du on the root folder. The downside to all of this is that
it's not very friendly to "small" filesystems, in your case it allocated
some 1.8 GB of metadata of which only 500 MB was actually in use.

In the future you can create your filesystem with metadata=single to
free up more space for regular data or look into forcing the mixed block
groups mode which is normally only enabled for 1GB or smaller
filesystems. Mixed block group mode can't be switched off so you could
make a really tiny FS, several hunder MB or so, and then just grow it to
whatever size you want. The btrfs wiki seems to define small filesystems
as anything under 16GB so might be a good lower bound for actually using
btrfs in a day to day environment.