From: Marc Lehmann <schmorp@schmorp.de>
To: linux-btrfs@vger.kernel.org
Subject: btrfs wrongly reports 0 space available in 5.4.15
Date: Sat, 1 Feb 2020 21:40:31 +0100 [thread overview]
Message-ID: <20200201204031.GA4203@schmorp.de> (raw)
Hi!
I upgraded one machine from 5.2.21 to 5.4.15, and one (freshly-created)
btrfs filesystem wrongly shows 0 avail in df after writing a bit of data:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_ssd-data 6.5G 160M 0 100% /ssd
When at the same time, the filesystem should claim gobs of free space
(the df output corresponds to a time a bit earlier when not all data was
written yet):
Overall:
Device size: 6.00GiB
Device allocated: 0.63GiB
Device unallocated: 5.37GiB
Device missing: 0.00GiB
Used: 0.22GiB
Free (estimated): 5.77GiB (min: 5.77GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 0.00GiB (used: 0.00GiB)
Data,single: Size:0.62GiB, Used:0.22GiB
/dev/mapper/vg_ssd-data 0.62GiB
Metadata,single: Size:0.01GiB, Used:0.00GiB
/dev/mapper/vg_ssd-data 0.01GiB
System,single: Size:0.00GiB, Used:0.00GiB
/dev/mapper/vg_ssd-data 0.00GiB
Unallocated:
/dev/mapper/vg_ssd-data 5.37GiB
This didn't happen under 5.2.21 for me, obviously.
Deleting some files makes the remaining space appear again, creating
them again changes to 0 free. I retried with a 76G partition but had
essentially the same results.
Only df output seems affected, the fs is still writable (I only realized
because apt told me the disk was full - the fs only stores apt package
lists and the apt cache).
When writing, this switch to 0 free happens suddenly (example with bigger
partition):
/dev/mapper/vg_ssd-data 76G 3.9M 76G 1% /ssd
/dev/mapper/vg_ssd-data 76G 3.9M 76G 1% /ssd
/dev/mapper/vg_ssd-data 76G 122M 76G 1% /ssd
/dev/mapper/vg_ssd-data 76G 201M 0 100% /ssd
/dev/mapper/vg_ssd-data 76G 244M 0 100% /ssd
Mount options are noatime,nossd,discard.
I see there were multiple reports for this and some discussion in december
(https://www.spinics.net/lists/linux-btrfs/msg95694.html), but apparently
nothing came of it and the bug still persists.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
next reply other threads:[~2020-02-01 20:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-01 20:40 Marc Lehmann [this message]
2020-02-02 0:00 ` btrfs wrongly reports 0 space available in 5.4.15 Qu Wenruo
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=20200201204031.GA4203@schmorp.de \
--to=schmorp@schmorp.de \
--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.