public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
* btrfs wrongly reports 0 space available in 5.4.15
@ 2020-02-01 20:40 Marc Lehmann
  2020-02-02  0:00 ` Qu Wenruo
  0 siblings, 1 reply; 2+ messages in thread
From: Marc Lehmann @ 2020-02-01 20:40 UTC (permalink / raw)
  To: linux-btrfs

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
      -=====/_/_//_/\_,_/ /_/\_\

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: btrfs wrongly reports 0 space available in 5.4.15
  2020-02-01 20:40 btrfs wrongly reports 0 space available in 5.4.15 Marc Lehmann
@ 2020-02-02  0:00 ` Qu Wenruo
  0 siblings, 0 replies; 2+ messages in thread
From: Qu Wenruo @ 2020-02-02  0:00 UTC (permalink / raw)
  To: Marc Lehmann, linux-btrfs


[-- Attachment #1.1: Type: text/plain, Size: 2698 bytes --]



On 2020/2/2 上午4:40, Marc Lehmann wrote:
> 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 discussion on how to fix it has finally settled down.
https://patchwork.kernel.org/patch/11359995/

Will be backported to related stable trees.

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-02-02  0:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-01 20:40 btrfs wrongly reports 0 space available in 5.4.15 Marc Lehmann
2020-02-02  0:00 ` Qu Wenruo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox