"Transaction commit" in btrfs sub del
Hello,
I was under impression that the "Transaction commit:" setting in 'btrfs sub del' finally allows us to make it not return until all free space from the snapshots that are being deleted, is completely freed up.
However that does not seem to be the case at all, deleting 14 snapshots with a heavy write-load occuring at the same time (Btrfs v3.14.1, kernel 3.14.22), with "Transaction commit: at the end", the 'btrfs' utility exited, and I still observe no change in free space numbers. It got finally freed only a couple of minutes later, i.e. as it usually would, without any commit options.
So what is the purpose of these options, if they do not seem to have an effect?
Signature · 2 lines
With respect, Roman
Quoted 3 lines · Roman Mamedov
I was under impression that the "Transaction commit:" setting in 'btrfs sub del' finally allows us to make it not return until all free space from the snapshots that are being deleted, is completely freed up.
This is not what "commit-each" or "commit-after" options do. These are only to make sure, that the deletion is commited and the subvolume doesn't reappear after a crash.
You probably want "subvolume sync" command, introduced in btrfs-progs 3.17:
btrfs subvolume sync <path> [<subvol-id>...]
Wait until given subvolume(s) are completely removed from the
filesystem.
Regards
Quoted 8 lines · On Thu, 23 Oct 2014 17:44:46 +0200 Piotr Pawłow <[email protected]> wrote:
Quoted 3 lines · Roman Mamedov
I was under impression that the "Transaction commit:" setting in 'btrfs sub del' finally allows us to make it not return until all free space from the snapshots that are being deleted, is completely freed up.
This is not what "commit-each" or "commit-after" options do. These are only to make sure, that the deletion is commited and the subvolume doesn't reappear after a crash.
But is that not already ensured by a regular 'sync', or 'btrfs fi sync'?
Quoted 5 lines
You probably want "subvolume sync" command, introduced in btrfs-progs 3.17:
btrfs subvolume sync <path> [<subvol-id>...]
Wait until given subvolume(s) are completely removed from the
filesystem.
Oh right, *that*'s the one I was thinking of.
Signature · 2 lines
With respect, Roman
On Thu, 23 Oct 2014 17:44:46 +0200
Quoted 7 lines
Quoted 5 lines · Piotr Pawłow
Quoted 3 lines · Roman Mamedov
I was under impression that the "Transaction commit:" setting in 'btrfs sub del' finally allows us to make it not return until all free space from the snapshots that are being deleted, is completely freed up.
Quoted 5 lines
Quoted 3 lines
This is not what "commit-each" or "commit-after" options do. These are only to make sure, that the deletion is commited and the subvolume doesn't reappear after a crash.
But is that not already ensured by a regular 'sync', or 'btrfs fi sync’?
They could have same effects..
but doing ’sync’ is much more heavy than options..
Quoted 16 lines
Quoted 6 lines
You probably want "subvolume sync" command, introduced in btrfs-progs 3.17:
btrfs subvolume sync <path> [<subvol-id>...]
Wait until given subvolume(s) are completely removed from the
filesystem.Oh right, *that*'s the one I was thinking of.
Signature · 6 lines
With respect, Roman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Best Regards,
Wang Shilong