From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Standards Problems [Was: [PATCH v2 1/3] Btrfs: get more accurate output in df command.]
Date: Thu, 18 Dec 2014 08:02:09 +0000 (UTC) [thread overview]
Message-ID: <pan$f1f89$5f6c1478$209cc54c$73adc535@cox.net> (raw)
In-Reply-To: 549252FF.10400@pobox.com
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
next prev parent reply other threads:[~2014-12-18 8:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-11 8:31 [PATCH v2 1/3] Btrfs: get more accurate output in df command Dongsheng Yang
2014-12-11 8:31 ` [PATCH v2 2/3] Btrfs: raid56: simplify the parameter of nr_parity_stripes() Dongsheng Yang
2014-12-16 6:21 ` Satoru Takeuchi
2014-12-11 8:31 ` [PATCH v2 3/3] Btrfs: adapt df command to RAID5/6 Dongsheng Yang
2014-12-12 18:00 ` [PATCH v2 1/3] Btrfs: get more accurate output in df command Goffredo Baroncelli
2014-12-13 0:50 ` Duncan
2014-12-13 10:21 ` Dongsheng Yang
2014-12-13 9:57 ` Dongsheng Yang
2014-12-12 19:25 ` Goffredo Baroncelli
2014-12-14 11:29 ` Dongsheng Yang
[not found] ` <CABmMA7tw9BDsBXGHLO4vjcO4gaYmZPb_BQV8w22griqFvCJpPA@mail.gmail.com>
2014-12-14 14:32 ` Grzegorz Kowal
2014-12-15 1:21 ` Dongsheng Yang
2014-12-15 6:06 ` Robert White
2014-12-15 7:49 ` Robert White
2014-12-15 8:26 ` Dongsheng Yang
2014-12-15 9:36 ` Robert White
2014-12-16 3:30 ` Standards Problems [Was: [PATCH v2 1/3] Btrfs: get more accurate output in df command.] Robert White
2014-12-16 3:52 ` Robert White
2014-12-16 11:30 ` Dongsheng Yang
2014-12-16 13:24 ` Dongsheng Yang
2014-12-16 19:52 ` Robert White
2014-12-17 11:38 ` Dongsheng Yang
2014-12-18 4:07 ` Robert White
2014-12-18 8:02 ` Duncan [this message]
2014-12-23 12:31 ` Dongsheng Yang
2014-12-27 1:10 ` Robert White
2015-01-05 9:59 ` Dongsheng Yang
2014-12-31 0:15 ` Zygo Blaxell
2015-01-05 9:56 ` Dongsheng Yang
2015-01-05 10:07 ` [PATCH v2 1/3] Btrfs: get more accurate output in df command Dongsheng Yang
2015-01-05 10:07 ` [PATCH v2 2/3] Btrfs: raid56: simplify the parameter of nr_parity_stripes() Dongsheng Yang
2015-01-05 10:07 ` [PATCH v2 3/3] Btrfs: adapt df command to RAID5/6 Dongsheng Yang
2014-12-19 3:32 ` [PATCH v2 1/3] Btrfs: get more accurate output in df command Zygo Blaxell
[not found] ` <548F1EA7.9050505@inwind.it>
2014-12-16 13:47 ` Dongsheng Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$f1f89$5f6c1478$209cc54c$73adc535@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).