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
