]> git.hungrycats.org Git - linux/commit
btrfs: statfs: report zero available if metadata are exhausted
authorDavid Sterba <dsterba@suse.com>
Sat, 10 Oct 2015 15:59:53 +0000 (17:59 +0200)
committerZygo Blaxell <zblaxell@thirteen.furryterror.org>
Sat, 16 Jan 2016 03:37:16 +0000 (22:37 -0500)
commit2a6fe4e0124389d380267e81fa1154bd6adeacdd
tree270b0e9b602766ea6715c3789512e334cee76831
parentaa8aee6b6eaf4757f1b31fb0d82e23fcd92c3286
btrfs: statfs: report zero available if metadata are exhausted

There is one ENOSPC case that's very confusing. There's Available
greater than zero but no file operation succeds (besides removing
files). This happens when the metadata are exhausted and there's no
possibility to allocate another chunk.

In this scenario it's normal that there's still some space in the data
chunk and the calculation in df reflects that in the Avail value.

To at least give some clue about the ENOSPC situation, let statfs report
zero value in Avail, even if there's still data space available.

Current:
  /dev/sdb1             4.0G  3.3G  719M  83% /mnt/test

New:
  /dev/sdb1             4.0G  3.3G     0 100% /mnt/test

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.

Signed-off-by: David Sterba <dsterba@suse.com>
(cherry picked from commit ca8a51b3a979d57b082b14eda38602b7f52d81d1)
fs/btrfs/super.c