At 01/05/2017 09:46 AM, Bruce Guenter wrote:
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)?
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
Thanks.
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
