linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Out of space on small-ish partition, clobber and other methods haven't worked
Date: Fri, 22 Jan 2016 12:08:41 +0000 (UTC)	[thread overview]
Message-ID: <pan$978c4$c1c61c61$74128c09$7a6863e0@cox.net> (raw)
In-Reply-To: CAJCQCtQpHuN9QYeTY+dZ7KH09cjD1=CPUw1Ba8vY-8bVgicTdQ@mail.gmail.com

Chris Murphy posted on Thu, 21 Jan 2016 10:40:51 -0700 as excerpted:

>> Global reserve is normally reserved from metadata, which of course is
>> shared data/metadata here, due to the size of the filesystem (which
>> makes shared a practical necessity, the problems would be much worse if
>> data and metadata chunks were separate!).
>>
>> So of the 506 MiB in data/metadata, 12 MiB are global reserve.  Which
>> means there's only 494 MiB of normal data/metadata space, plus 12 MiB
>> of global reserve.
>>
>> But the DF shows 500.39 MiB of data/metadata used, which means we're
>> roughly 6.4 MiB past normal data/metadata usage into the emergency use
>> only global reserve, which is indeed (roughly) what global reserve
>> shows,
>> 6.45 MiB used.
> 
> OK that's a fine explanation, but the UI is not explaining this at all.
> In fact it's completely misleading *away* from the explanation you give.
> It's suggesting there's free space by the fact "used" is less than
> "total".

... Which is why there's already a proposal (and patch, IIRC) to indent 
global reserve under metadata, increasing the "used" metadata value by 
the "total" value of global reserve, tho there's an alternate viewpoint 
in the discussion saying that global reserve shouldn't be shown at all, 
just included in the metadata "used" figure, unless an option is given to 
show it.

With David, IIRC, as another viewpoint, saying that fi df is fine as-is, 
as it's intended for dev and advanced users who know the score, while fi 
usage should be recommended for normal users.

But as I pointed out (my viewpoint) until David's patches that made it 
into -progs 4.4, usage didn't work in some cases, namely --mixed mode, 
with a warning at the top and often returning 8 EiB (on 64-bit anyway) as 
something was going negative due to a screwy formula (thus the 
unsupported warning) but then being reported as the ridiculously high 
unsigned value.  Between that and the fact that fi usage is itself 
relatively new compared to the old fi show and fi df recommendation, it's 
simply impractical to recommend fi usage in the generic case, without a 
big hairy explanation of why it might not even be there (too old 
userspace) or be reporting absolutely crazy values (--mixed mode before 
it was properly supported in the still very new 4.4 userspace).  So 
recommending users post their btrfs fi show and btrfs fi df is going to 
remain the only practical option for another year or two, and  
interpreting the global reserve line in btrfs fi df is as much a 
challenge for those not "in the know" as is interpreting the global total 
vs. device total in btrfs fi show is.  In both cases, interpretation is 
definitely a form of art, only doable by those who know the inside tricks 
of interpretation.

So yeah, interpretation of btrfs fi df, particularly the global reserve 
as part of metadata, is tricky, requiring internal knowledge to do 
correctly, but so is interpreting btrfs fi show, and we've gotten so used 
to dealing with that, that it's hardly ever remarked on any more, except 
perhaps in explaining to newbies that the simplest thing to do there is 
to ignore the global total line and only look at the individual device 
lines.  (The numbers in show's global total have a value, but they're not 
what people intuitively think they are, and it's often easier to simply 
tell people to pretend that line doesn't exist than to explain where the 
number actually comes from, doing the required math[1] along the way.)

Meanwhile, simply adding global reserve total to metadata used, tends to 
work pretty well, and if that total is then more than metadata total, the 
difference is found in global reserved used, which if non-zero, really 
does indicate a filesystem in pretty dire straits.

And yes, it's a bug if btrfs gets into a jam so tight it can't even 
delete a file to make more room, but the reporter wasn't on the latest 
kernel either, and there's a reason the latest is recommended.  As I 
said, I think I saw some patches go by that should I believe be in 4.4, 
that may very well allow btrfs to use the global reserve for file 
deletions.  And if so, that bug is not only known, but already fixed.

---
[1] Doing the required math: Heh, I just typoed that as doing the 
required meth... which might explain some things about these "gotta know 
the inside story to interpret" lines in both sub-commands!  =;^p

-- 
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:[~2016-01-22 12:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 21:22 Out of space on small-ish partition, clobber and other methods haven't worked Jerry Steinhauer
2016-01-21  2:28 ` Chris Murphy
2016-01-21 10:41   ` Duncan
2016-01-21 17:40     ` Chris Murphy
2016-01-22 12:08       ` Duncan [this message]
2016-01-22 12:11     ` Jerry Steinhauer
     [not found]   ` <CAHRikPHt7SmFhzQsZ-XKLYSbwCAgCeccEFXbw+YXBobJx8w1Ew@mail.gmail.com>
2016-01-23 15:23     ` Jerry Steinhauer

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$978c4$c1c61c61$74128c09$7a6863e0@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).