# btrfs reports 0 Bytes free

## toralf

I do wonder why this happens:

```
# df -Pk img1

Filesystem     1024-blocks      Used Available Capacity Mounted on

/dev/sda5       1782579200 372973140         0     100% /home/tinderbox/img1

```

The fs is a 

```
# btrfs filesystem show 

Label: none  uuid: 2d40195c-953b-4b95-bda6-ca3914034afa

        Total devices 2 FS bytes used 341.39GiB

        devid    1 size 850.00GiB used 178.01GiB path /dev/sda5

        devid    2 size 850.00GiB used 178.01GiB path /dev/sdb1

```

Last edited by toralf on Wed Dec 18, 2019 9:46 am; edited 3 times in total

----------

## shrike

toralf,

As I've recently learned it is 'unallocated' space not 'free' space that is accurate.

```

 # btrfs filesystem usage /mnt/raid_btrfs

Overall:

    Device size:                   7.28TiB

    Device allocated:              6.67TiB

    Device unallocated:          623.98GiB

    Device missing:                  0.00B

    Used:                          6.56TiB

    Free (estimated):            731.15GiB      (min: 419.16GiB)

    Data ratio:                       1.00

    Metadata ratio:                   2.00

    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID0: Size:6.65TiB, Used:6.55TiB

   /dev/sdb        3.33TiB

   /dev/sdc        3.33TiB

Metadata,RAID1: Size:8.00GiB, Used:6.81GiB

   /dev/sdb        8.00GiB

   /dev/sdc        8.00GiB

System,RAID1: Size:32.00MiB, Used:528.00KiB

   /dev/sdb       32.00MiB

   /dev/sdc       32.00MiB

Unallocated:

   /dev/sdb      311.99GiB

   /dev/sdc      311.99GiB
```

```
# df -h /mnt/raid_btrfs/

Filesystem      Size  Used Avail Use% Mounted on

/dev/sdb        7.3T  6.6T  732G  91% /mnt/raid_btrfs
```

This site lays out the details:

https://ohthehugemanatee.org/blog/2019/02/11/btrfs-out-of-space-emergency-response/

Regards,

shrike

----------

## toralf

Hhm,

I do not use subvolumes, snapshots etc.

I do wonder if this is a kernel 5.4.x issue. The eclass in Gentoo uses "du -Pk /usr" to decide whether a package can be emerged or not. This worked for years.

But suddenly I run into the issue of failed emerge operations in the prepare phase accordingly to "too less space".

```
mr-fox ~ # btrfs filesystem usage /home/tinderbox/img1

Overall:

    Device size:                   1.66TiB

    Device allocated:            392.02GiB

    Device unallocated:            1.28TiB

    Device missing:                  0.00B

    Used:                        389.65GiB

    Free (estimated):              1.28TiB      (min: 654.66GiB)

    Data ratio:                       1.00

    Metadata ratio:                   2.00

    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID0: Size:360.00GiB, Used:359.34GiB

   /dev/sda5     180.00GiB

   /dev/sdb1     180.00GiB

Metadata,RAID1: Size:16.00GiB, Used:15.15GiB

   /dev/sda5      16.00GiB

   /dev/sdb1      16.00GiB

System,RAID1: Size:8.00MiB, Used:48.00KiB

   /dev/sda5       8.00MiB

   /dev/sdb1       8.00MiB

Unallocated:

   /dev/sda5     653.99GiB

   /dev/sdb1     653.99GiB

```

----------

## shrike

toralf,

Hard to imagine 1.28TiB being "too less space". Clearly space is not the issue on your btrfs filesystem.

Sorry for pointing you in the wrong direction! 

Regards,

shrike

----------

## toralf

Well, known bug (https://lkml.org/lkml/2019/12/11/1647)

----------

## haarp

Same bug here. You put [solved] in the title, did you find a patch or something? Not being able to use emerge and half of my apps refusing to write data kinda sucks  :Smile:  Can't even receive Email because Thunderbird won't work.

Thanks!

PS, here are two more relevant KML threads:

https://www.spinics.net/lists/linux-btrfs/msg95278.html

https://www.spinics.net/lists/linux-btrfs/msg95365.htmlLast edited by haarp on Sun Dec 15, 2019 10:35 pm; edited 1 time in total

----------

## toralf

I switched back to 5.3(.16) and will follow that stable series till 5.4.x is fixed.

FWIW there're few BTRFS patches in stable queue for 5.3:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=2f9fad77db9775ecdb17e0d93d9599495f4c0c57

and 5.4 :

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=3963aed711f6a2bb34be61d1fdfff17a97db1857

----------

## haarp

Someone posted a patch on the btrfs list that fixed the issue for me. Scroll to the bottom of https://lore.kernel.org/linux-btrfs/CAJCQCtQEu_+nL_HByAWK2zKfg2Zhpm3Ezto+sA12wwV0iq8Ghg@mail.gmail.com/T/#t

----------

## toralf

 *haarp wrote:*   

> Someone posted a patch on the btrfs list that fixed the issue for me. Scroll to the bottom of https://lore.kernel.org/linux-btrfs/CAJCQCtQEu_+nL_HByAWK2zKfg2Zhpm3Ezto+sA12wwV0iq8Ghg@mail.gmail.com/T/#t

 You mean this quirk? : https://marc.info/?l=linux-btrfs&m=157647271114157&w=3

----------

## haarp

Yeah, this patch

```

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c

index 1b151af25772..b8b67ab05f72 100644

--- a/fs/btrfs/super.c

+++ b/fs/btrfs/super.c

@@ -2032,7 +2032,6 @@ static int btrfs_statfs(struct dentry *dentry, struct kstatfs *buf)

    unsigned factor = 1;

    struct btrfs_block_rsv *block_rsv = &fs_info->global_block_rsv;

    int ret;

-   u64 thresh = 0;

    int mixed = 0;

 

    rcu_read_lock();

@@ -2085,26 +2084,9 @@ static int btrfs_statfs(struct dentry *dentry, struct kstatfs *buf)

    if (ret)

       return ret;

    buf->f_bavail += div_u64(total_free_data, factor);

+   buf->f_bavail -= block_rsv->size;

    buf->f_bavail = buf->f_bavail >> bits;

 

-   /*

-    * We calculate the remaining metadata space minus global reserve. If

-    * this is (supposedly) smaller than zero, there's no space. But this

-    * does not hold in practice, the exhausted state happens where's still

-    * some positive delta. So we apply some guesswork and compare the

-    * delta to a 4M threshold.  (Practically observed delta was ~2M.)

-    *

-    * We probably cannot calculate the exact threshold value because this

-    * depends on the internal reservations requested by various

-    * operations, so some operations that consume a few metadata will

-    * succeed even if the Avail is zero. But this is better than the other

-    * way around.

-    */

-   thresh = SZ_4M;

-

-   if (!mixed && total_free_meta - thresh < block_rsv->size)

-      buf->f_bavail = 0;

-

    buf->f_type = BTRFS_SUPER_MAGIC;

    buf->f_bsize = dentry->d_sb->s_blocksize;

    buf->f_namelen = BTRFS_NAME_LEN;

```

----------

## toralf

/me would feel better if an appropriate patch would land in the stable 5.4.x series, but till now it is not the case :-/

----------

## toralf

 *haarp wrote:*   

> Someone posted a patch on the btrfs list that fixed the issue for me. Scroll to the bottom of https://lore.kernel.org/linux-btrfs/CAJCQCtQEu_+nL_HByAWK2zKfg2Zhpm3Ezto+sA12wwV0iq8Ghg@mail.gmail.com/T/#t

 Maybe this is the solution? : https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=ed4710bc06a6e688ed0a6c3f432d1a1d2d9ba665

----------

## Gatak

Linux 5.5.x has the fixes.

----------

