From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs
Date: Fri, 28 Dec 2018 04:09:12 +0000 (UTC) [thread overview]
Message-ID: <pan$369c4$4c203e8d$24a2c9f9$f1866656@cox.net> (raw)
In-Reply-To: CAJCQCtRFwLvPFkjhXfs+UFmOu+rHAQ-Zq3Mk6T_q22Qn0zgc7A@mail.gmail.com
Chris Murphy posted on Thu, 27 Dec 2018 16:37:55 -0700 as excerpted:
[Context is btrfs reports when btrfs is smaller on a device than the
device it is on. In this specific case it's due to btrfs replace to a
larger device, before using btrfs filesystem resize to increase the size
to that of the newer/larger device.]
> OK let me see if I get this right. You're saying it's confusing that
> 'btrfs fi sh' "devid size" does not change when doing a device replace;
> whereas 'btrfs fi us' device specific "unallocated" does change, even
> though you haven't yet done a resize.
>
> I kinda sorta agree. While "unallocated" becomes 6.53TiB for this
> device, the idea it's unallocated suggests it could be allocated, which
> before a resize it cannot be allocated.
"It depends what the definition of "unallocated" is."[1]
Arguably, just as "unallocated" includes space not yet allocated to data/
metadata/system chunks, it could be argued it should include space on the
device not yet allocated to the filesystem as well. Clearly, that's what
the coder of the btrfs filesystem usage functionality thought.
By that view, "unallocated" includes "not yet allocated to the filesystem
itself also, but available on the block device the filesystem is on, to
be allocated to the filesystem should the admin decide to do so."
OTOH, as the OP says it's still confusing, and as pointed out in a reply,
it's btrfs _filesystem_ usage we're talking about here, not btrfs
_device_ usage, and at minimum, _filesystem_ usage including space on the
device that's not yet allocated to that filesystem is indeed confusing/
unintuitive, and arguably actually incorrect, particularly if the btrfs
device usage report reports that space under its "device slack" line,
which as admins we don't actually know at this point (it doesn't appear
to be documented except presumably in the code itself). And arguably, if
btrfs filesystem usage is to report it at all, it should be under a
separate (additional) line, presumably device slack, if that's what the
device usage version does with that line.
---
[1] Quote paraphrases a famous US political/legal quote from some years
ago... OT as to the merits, but if you wish the background,
s/unallocated/is/ and google it using the search engine of your choice.
--
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
prev parent reply other threads:[~2018-12-28 4:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-24 17:21 btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs joshua
2018-12-27 0:36 ` Chris Murphy
2018-12-27 7:12 ` Duncan
2018-12-27 20:06 ` Chris Murphy
2018-12-27 20:07 ` Chris Murphy
2018-12-27 20:33 ` joshua
2018-12-27 23:37 ` Chris Murphy
2018-12-28 4:09 ` Duncan [this message]
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$369c4$4c203e8d$24a2c9f9$f1866656@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.