Robert White posted on Wed, 17 Dec 2014 20:07:27 -0800 as excerpted:

>  We have room for 1 more metadata extent on each
> drive, but if we allocate two more metadat extents on each drive we will
> burn up 1.25 GiB by reducing it to 0.75GiB.

FWIW, at least the last chunk assignment can be smaller than normal.  I 
believe I've seen it happen both here and on posted reports.  The 0.75 
GiB could thus be allocated as data if needed.

I'm not actually sure how the allocator works with the last few GiB.  
Some developer comments have hinted that it starts carving smaller chunks 
before it actually has to, and I could imagine it dropping data chunks to 
a half gig, then a quarter gig, than 128 MiB, then 64 MiB... as space 
gets tight, and metadata chunks similarly but of course from a quarter 
gig down.  That I'm not sure about.  But I'm quite sure it will actually 
use the last little bit (provided it can properly fill its raid policy 
when doing so), as I'm quite sure I've seen it do it.

I know for sure it does that in mixed-mode, as I have a 256 MiB mixed-
mode dup /boot (and a backup /boot of the same size on the other device, 
so I can select the one that's booted from the BIOS), and they tend to be 
fully chunk-allocated.   Note that even with mixed-mode, which defaults 
to metadata-sized-chunks, thus 256 MiB, on a 256 MiB device, by the time 
overhead, system, and reserve chunks are allocated, there's definitely 
NOT 256 MiB left for a data/metadata-mixed chunk, so if it couldn't 
allocate smaller bits it couldn't allocate even ONE chunk, let alone a 
pair (dup mode).

And I think I've seen it happen on my larger (not mixed) filesystems of 
several GiB as well, tho I don't actually tend to fill them up quite so 
routinely, so it's more difficult to say for sure.

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to