search for: btrfs_create_pending_block_group

...c21.x86_64 from rawhide, reboot and try again. The rebalancing works well this time but is, as expected, very slow (about 50GB in half a day). I return home and leave the pc runnung all the night. The morning I find this: Sep 30 23:11:53 tambura kernel: [37787.652143] BTRFS error (device sdc2) in btrfs_create_pending_block_groups:8516: errno=-5 IO failure Sep 30 23:11:53 tambura kernel: [37787.652145] BTRFS info (device sdc2): forced readonly the whole messages.log is here: http://paste.fedoraproject.org/44143/24287138/ N.B: sdc2 is the partition of the new drive that, however, has no relocated nor pending sectors accord...

caching_thread()s do all their work under read access to extent_commit_sem. They give up on this read access only when need_resched() tells them, or when they exit. As a result, somebody that wants a WRITE access to this sem, might wait for a long time. Especially this is problematic in cache_block_group(), which can be called on critical paths like find_free_extent() and in commit path via