btrfs subvolume delete --commit-after doesn't wait for deletions

In the man page for btrfs subvolume delete, the --commit-after option says it will "wait for transaction commit at the end of the operation". However, the available disk space continues to increase for several minutes after this command completes. I am running linux kernel 4.4.35 on Gentoo Linux with btrfs-progs-4.9.

Am I misunderstanding how the --commit-after option is supposed to work? If so, is there any other good way to wait for btrfs subvolume delete to complete freeing space before continuing? Has this behavior changed in recent kernels (I tried 4.8.15 before posting this, but it had unrelated issues)?

Thanks.

Bruce Guenter <[email protected]>                http://untroubled.org/

Commit-after/each is only supposed to commit the transaction, in which we orphaned the subvolume, but not deleting it yet.

That's to say, after subvolume delete finished with --commit-after/each, and a powerloss happened, it ensures that we won't see the old subvolume in fs.

Without --comit-after/each, it's possible that a power loss can make the us rollback to previous status, which un-committed subvolumes are still here.

Anyway, subvolume delete only makes subvolume orphan. And real delete happens background. Just like what we delete files.

To wait the deletion finish, please use "btrfs filesystem sync".

Thanks,
Qu

That doesn't entirely work either. It does appear to wait for something, but disk space available continues to increase after it exits.

Bruce Guenter <[email protected]>                http://untroubled.org/

Other than subvolume deleting, is there any other large file deletion?

File deletion in btrfs works in the same way, so the increasing disk space may be related to delayed file deletion.

Thanks,
Qu

There is no other activity on the partition at all.

Bruce Guenter <[email protected]>                http://untroubled.org/