Feature Request: provide a way to monitor progress of snapshot delete.

[julie777]

I am struggling with device replace (I won't put details here) and I thought that removing some of the snapshots would help.

1. I ran btrfs snapshot delete on a couple snapshots and it returned immediately.
2. On the third deletion it took quiet some time for the command to finish so I assumed that deletion was being run during the command and that when the command finished the snapshot deletion was complete.
3. I tried to unmount the filesystem in order to run btrfs-check before running device-replace.

• umount failed with "target is busy"
• it has now been about 24 hours and umount still fails with "target is busy"

I cannot find any way to check progress of snapshot delete or determine when I will be able to unmount the filesystem.

Is there anything I can do?

[Forza-tng]

You can use btrfs subvolume sync /path.

https://btrfs.readthedocs.io/en/latest/btrfs-subvolume.html#man-subvolume-sync

[Zygo]

btrfs sub list -d /mnt will show snapshots that are awaiting deletion. If you watch that, you can follow along as each snapshot is removed.

The inability to umount is more likely to be due to other causes. On most filesystems, an open fd on a deleted file prevents the inode from being removed (it becomes an "orphan inode" with no names), and prevents the filesystem from being umounted. Lazy umounts remove the mount point, but don't close the open files, so the umount is not completed and the device will appear busy even though umount returns success. Snapshots have a similar mechanism, except that an open fd on a deleted snapshot prevents the entire snapshot from being deleted. This can result in both observed effects:

1. The snapshot delete takes a long time, since it won't start until the last open file on the snapshot is closed.
2. The umount fails with EBUSY, since umount will fail with EBUSY until the last open file on the mount point is closed.

It can be difficult to identify which files are still open on a deleted snapshot, since the deleted snapshot removes the snapshot path from /proc/*/fd/* filenames, and they could be referenced in private mount namespaces. Tools like fuser or lsof can't find them.

umount does not return EBUSY while snapshot deletes are running--but it does wait for the snapshot deletes in the current transaction to finish, so it can take a while. It will wait for some snapshots and leave others to start deletion after the first commit on the next mount.

Snapshots deletes are more or less atomic (meaning the delete code doesn't break the delete up into smaller commits). In the worst case, each deletion can take several hours or even days on spinning drives. If you force a reboot with echo b > /proc/sysrq-trigger, any interrupted delete will restart from the beginning.

You can run device replace during the snapshot removal. They operate on different layers within btrfs, so they don't interfere with each other.

You cannot run device delete during snapshot removal. While you can start both without error, they will lock each other out, so one runs after the other. If you notice you're running low on space while shrinking or removing a device, snapshot delete will wait until the shrink/remove runs out of space, then delete the snapshots.

There is normally no need to run btrfs check before replacing a device (or at any other time). Device replace will copy the metadata as-is, so any metadata issues will be the same in the copy as they are in the original.

If there is corrupted data on one of the devices, do not run btrfs check until you have resolved all corruption detected by scrub. btrfs check might bypass csum checks and try to interpret corrupted metadata, and cause fatal filesystem corruption.