From: Martin Steigerwald <martin@lichtvoll.de>
To: Chris Murphy <lists@colorremedies.com>
Cc: David Sterba <dsterba@suse.cz>,
Martin Raiber <martin@urbackup.org>,
linux-btrfs@vger.kernel.org
Subject: Re: With Linux 5.5: Filesystem full while still 90 GiB free
Date: Thu, 30 Jan 2020 20:58:38 +0100 [thread overview]
Message-ID: <16325152.4fYaUy9WYm@merkaba> (raw)
In-Reply-To: <CAJCQCtSwJHR2+jEXY=eK41xR7Z0=+Jf5xhsD03Qvoh92bAHO6g@mail.gmail.com>
Chris Murphy - 30.01.20, 20:31:40 CET:
> > > Is that mount option sufficient? Or does it take a filtered
> > > balance?
> > > What's the most minimal balance needed? I'm hoping -dlimit=1
> > >
> > > I can't figure out a way to trigger this though, otherwise I'd be
> > > doing more testing.
> >
> > I haven't checked but I think the suggested workarounds affect
> > statfs as a side effect. Also as the reservations are temporary,
> > the numbers change again after a sync.
>
> Yeah I'm being careful to qualify to mortal users that any workarounds
> are temporary and uncertain. I'm not even certain what the pattern
> is, people with new file systems have hit it. A full balance seems to
> fix it, and then soon after the problem happens again. I don't do any
> balancing these days, for over a year now, so I wonder if that's why
> I'm not seeing it.
>
> But yeah a small number of people are hitting it, but it also stops
> any program that does a free space check (presumably using statfs).
>
> A more reliable/universal work around in the meantime is still useful;
> in particular if it doesn't require changing mount options, or only
> requires it temporarily (e.g. not added to /etc/fstab, where it can
> be forgotten for the life of that system).
I did not balance either. Except maybe for a very short time during
holding trainings in order to show to people how it works.
I never bought into balancing regularily.
Thanks,
--
Martin
next prev parent reply other threads:[~2020-01-30 19:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 19:33 With Linux 5.5: Filesystem full while still 90 GiB free Martin Steigerwald
2020-01-29 20:04 ` Martin Raiber
2020-01-29 21:20 ` Martin Steigerwald
2020-01-29 22:55 ` Chris Murphy
2020-01-30 10:41 ` Martin Steigerwald
2020-01-30 16:37 ` Chris Murphy
2020-01-30 20:02 ` Martin Steigerwald
2020-01-30 20:18 ` Chris Murphy
2020-01-30 20:59 ` Josef Bacik
2020-01-30 21:09 ` Chris Murphy
2020-01-30 21:32 ` Martin Raiber
2020-01-30 21:42 ` Josef Bacik
2020-01-30 21:12 ` Martin Steigerwald
2020-01-30 21:10 ` Martin Steigerwald
2020-01-30 21:20 ` Remi Gauvin
2020-01-30 23:12 ` Martin Steigerwald
2020-01-31 1:43 ` Matt Corallo
2020-01-31 1:57 ` Qu Wenruo
2020-03-02 1:57 ` Etienne Champetier
2020-03-02 1:59 ` Qu Wenruo
2020-01-31 4:12 ` Etienne Champetier
2020-01-30 17:19 ` David Sterba
2020-01-30 19:31 ` Chris Murphy
2020-01-30 19:58 ` Martin Steigerwald [this message]
2020-01-31 3:00 ` Zygo Blaxell
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=16325152.4fYaUy9WYm@merkaba \
--to=martin@lichtvoll.de \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=martin@urbackup.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