Re: btrfs wrongly reports 0 space available in 5.4.15

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

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