My hand was ultimately forced today. The device remove running since last weekend bombed out with a "no space" message in the kernel log despite there being plenty of free space on all devices. The file system had been remounted read-only. When I brought it back up, the mount system call blocked while it underwent what was apparently a lengthy file system check. (I got one message about a block group free space cache being rebuilt). It really doesn't seem like such a good idea for a really basic system call like "mount" to block indefinitely during system boot. systemd eventually gives up, but it does take a while. Lots and lots of stack traces in dmesg about system calls blocking for more than 120 sec. Usually mount, but also sd-sync when trying to shut the system down gracefully. Eventually I was forced to hit hard reset. These blocking mounts make it kinda painful to get a root shell just so you can see what's going on. This is why I'll never put a root filesystem on btrfs. I keep my root filesystems in XFS or ext4 on a SSD so I can at least pull all the other drives and boot up single user fairly quickly. I'll manually rsync the root file system onto a spare disk partition as a backup. Before rebooting I physically pulled the drive I was trying to replace and set noauto in /etc/fstab on the btrfs fs. Back in multi-user mode at last, I did a mount with degraded enabled and got the expected message about the missing device (confirming I pulled the right one). It's still madly doing I/O, but since it's not telling me what's going on (and the mount has not completed) I have to assume from the I/O patterns that it's continuing the device remove without it being physically present. I guess if I'm lucky I'll be able to use my filesystem in a week or so. I do have a backup but I'd rather not touch it except as a last resort. (resending) --Phil
