All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?
Date: Thu, 19 Nov 2015 02:16:20 +0000 (UTC)	[thread overview]
Message-ID: <pan$61583$65d817c9$bfda2de6$465dca20@cox.net> (raw)
In-Reply-To: 564D1AE5.3000700@cn.fujitsu.com

Qu Wenruo posted on Thu, 19 Nov 2015 08:42:13 +0800 as excerpted:

> Although the metadata output is showing that you still have about 512M
> available, but the 512M is Global Reserved space, or the unknown one.

Unknown here, as the userspace (btrfs-progs) is evidently too old to show 
it as global reserve, as it does in newer versions...

> The output is really a little confusing. I'd like the change the output
> by adding global reserved into metadata used space and make it a sub
> item for metadata.

Thanks for the clarification.  It's most helpful, here. =:^)

I've at times wondered if global reserve folded into one of the other 
settings.  Apparently it comes from the metadata allocation, but while 
metadata is normally dup (single-device btrfs) or raid1 (multi-device), 
global reserve is single.

It would have been nice if that sort of substructure was described a bit 
better when global reserve first made its appearance, at least in the 
patch descriptions and release announcement, if not then yet in btrfs fi 
df output, first implementations being what they are.  But regardless, 
now at least it should be clear for list regulars who read this thread 
anyway, since the above reasonably clarifies things.

As for btrfs fi df, making global reserve a metadata subentry there would 
be one way to deal with it, preserving the exposure of the additional 
data provided by that line (here, the fact that global reserve is 
actually being used, underlining the fact that the filesystem is severely 
short on space).

Another way of handling it would be to simply add the global reserve into 
the metadata used figure before printing it, eliminating the separate 
global reserve line, and changing the upthread posted metadata line from 
8.48 GiB of 9 GiB used, to 8.98 of 9 GiB used, which is effectively the 
case if the 512 MiB of global reserve indeed comes from the metadata 
allocation.  This would more clearly show how full metadata actually is 
without the added complexity of an additional global reserve line, but 
would lose the fact that global reserve is actually in use, that the 
broken out global reserve line exposes.

I'd actually argue in favor of the latter, directly folding global 
reserve allocation into metadata used, since it'd both be simpler, and 
more consistent if for instance btrfs fi usage didn't report separate 
global reserve in the overall stats, but fail to report it in the per-
device stats and in btrfs dev usage.

Either way would make much clearer that metadata is actually running out 
than the current report layout does, since "metadata used" would then 
either explicitly or implicitly include the global reserve.

-- 
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


  reply	other threads:[~2015-11-19  2:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18 18:53 Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left? linux-btrfs.tebulin
2015-11-18 19:08 ` Hugo Mills
2015-11-19  0:42   ` Qu Wenruo
2015-11-19  2:16     ` Duncan [this message]
2015-11-20 11:39       ` Dmitry Katsubo
2015-11-20 13:21         ` Austin S Hemmelgarn
2015-11-20 13:27           ` Hugo Mills
2015-11-20 13:52             ` Austin S Hemmelgarn
2015-11-20 16:39               ` Dmitry Katsubo
2015-11-19 17:35   ` linux-btrfs.tebulin
2015-11-19 18:28     ` Hugo Mills
2015-11-19 18:45       ` linux-btrfs.tebulin
2015-11-19 18:56         ` linux-btrfs.tebulin
2015-11-19 19:26           ` linux-btrfs.tebulin
2015-11-20  3:14           ` Duncan
2015-11-20  9:38             ` linux-btrfs.tebulin
2015-11-20 10:44               ` Duncan
2015-11-20 14:25             ` Dmitry Katsubo
2015-11-19 20:18       ` Austin S Hemmelgarn
2015-11-19  5:58 ` Roman Mamedov
2015-11-19  8:31   ` Patrik Lundquist
2015-11-19 12:28 ` Austin S Hemmelgarn
2015-11-20  2:11   ` Duncan
2015-11-20 13:13     ` Austin S Hemmelgarn

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$61583$65d817c9$bfda2de6$465dca20@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.