I have a btrfs disk (without raid) that gives me a very big difference between du and df:

$ df -h /pgdata
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-pgdata   85G   77G  7.1G  92% /pgdata

$ du -sh /pgdata
56G     /pgdata

And btrfs commands give me the same result:

$ btrfs fi df -h /pgdata/
Data, single: total=82.94GiB, used=75.63GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=365.73MiB
GlobalReserve, single: total=228.33MiB, used=0.00B

$ btrfs fi du -s /pgdata/
     Total   Exclusive  Set shared  Filename
  55.84GiB    55.36GiB   491.34MiB  /pgdata/

There is no subvolume (I think), btrfs subvolume list /pgdata is empty. I ran btrfs balance start /pgdata/ -dusage=66 but it didn't change much.

$ btrfs fi usage /pgdata/
    Device size:                  85.00GiB
    Device allocated:             85.00GiB
    Device unallocated:            1.00MiB
    Device missing:                  0.00B
    Used:                         76.50GiB
    Free (estimated):              7.15GiB      (min: 7.15GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              228.52MiB      (used: 0.00B)

Data,single: Size:82.94GiB, Used:75.79GiB (91.38%)
   /dev/mapper/ubuntu--vg-pgdata          82.94GiB

Metadata,DUP: Size:1.00GiB, Used:365.78MiB (35.72%)
   /dev/mapper/ubuntu--vg-pgdata           2.00GiB

System,DUP: Size:32.00MiB, Used:16.00KiB (0.05%)
   /dev/mapper/ubuntu--vg-pgdata          64.00MiB

   /dev/mapper/ubuntu--vg-pgdata           1.00MiB

It's not deleted inodes that are the issue (the machine has been rebooted 3 hours ago) and:

$ lsof /pgdata |grep deleted
postgres  4107 postgres    4u   REG   0,58   16777216 238658 /pgdata/postgresql/13/main/pg_wal/00000001000001E40000008A (deleted)
postgres  5589 postgres   45u   REG   0,58   16777216 238753 /pgdata/postgresql/13/main/pg_wal/00000001000001E50000000E (deleted)
postgres  5590 postgres   45u   REG   0,58   16777216 222523 /pgdata/postgresql/13/main/pg_wal/00000001000001E40000006A (deleted)
postgres  5591 postgres   26u   REG   0,58   16777216 238992 /pgdata/postgresql/13/main/pg_wal/00000001000001E4000000F3 (deleted)
postgres  5592 postgres   52u   REG   0,58   16777216 238986 /pgdata/postgresql/13/main/pg_wal/00000001000001E4000000ED (deleted)
postgres  5595 postgres   28u   REG   0,58   16777216 238995 /pgdata/postgresql/13/main/pg_wal/00000001000001E4000000F6 (deleted)
postgres  5596 postgres   19u   REG   0,58   16777216 222523 /pgdata/postgresql/13/main/pg_wal/00000001000001E40000006A (deleted)
postgres  5597 postgres   44u   REG   0,58   16777216 222523 /pgdata/postgresql/13/main/pg_wal/00000001000001E40000006A (deleted)
postgres  5598 postgres   12u   REG   0,58   16777216 238986 /pgdata/postgresql/13/main/pg_wal/00000001000001E4000000ED (deleted)
postgres  5604 postgres   85u   REG   0,58   16777216 238988 /pgdata/postgresql/13/main/pg_wal/00000001000001E4000000EF (deleted)
postgres  5605 postgres   61u   REG   0,58   16777216 238986 /pgdata/postgresql/13/main/pg_wal/00000001000001E4000000ED (deleted)
postgres 12936 postgres   58u   REG   0,58   16777216 238995 /pgdata/postgresql/13/main/pg_wal/00000001000001E4000000F6 (deleted)

I found other posts about this problem, but not having a so big difference (around 40% more used than it should) and it was always metadata or snapshot. Here, it seems it's not the case.

Does anyone has an idea why 20GiB are missing from the free space ?


1 Answer 1


One possible cause of more btrfs space being allocated for data than there is visible data is unreachable parts of extents (data in extents containing older versions of file content which has since been overwritten).

To analyze problems like this, I created btdu, a disk usage profiler for btrfs:


The tool will identify the true cause for the discrepancy.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .