Re: [PATCH] btrfs: do not zero f_bavail if we have available space

Marc MERLIN
2020-02-21T05:38:16Z

On Thu, Feb 20, 2020 at 01:46:49PM -0800, Marc MERLIN wrote:
> Well, turns out this was a more serious bug than we thought.
> With dm-thin overcommit, it causes this:
> [1324107.675334] BTRFS info (device dm-13): forced readonly
> [1324107.692909] BTRFS warning (device dm-13): Skipping commit of aborted transaction.
> [1324107.717141] BTRFS: error (device dm-13) in cleanup_transaction:1828: errno=-5 IO failure
> [1324107.743298] BTRFS info (device dm-13): delayed_refs has NO entry
> [1324107.817671] device-mapper: thin: 252:9: switching pool to write mode
> [1324108.662095] BTRFS error (device dm-13): bad tree block start, want 9050645626880 have 0
> [1324108.694286] BTRFS error (device dm-13): bad tree block start, want 9050645626880 have 0

I had a closer look, and even with 5.4.20, my whole lv is full now:
LV Name thinpool2
Allocated pool data 99.99%
Allocated metadata 59.88%

Sure enough, that broken ubuntu one (that really only needs 4GB or so),
is now taking 60% of the mapped size (i.e. everything that was left)
LV Name ubuntu
Mapped size 60.26%

I'm now running this overnight, but any command on that filesystem, just
hangs for now:
gargamel:/mnt/btrfs_pool2/backup/ubuntu# fstrim -v .

Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.

Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08