"Transaction commit" in btrfs sub del

"Transaction commit" in btrfs sub del

[Roman Mamedov]

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?

-- 
With respect,
Roman

Re: "Transaction commit" in btrfs sub del

[Piotr Pawłow]

On 23.10.2014 16:24, Roman Mamedov wrote:
> 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

Re: "Transaction commit" in btrfs sub del

[Roman Mamedov]

On Thu, 23 Oct 2014 17:44:46 +0200
Piotr Pawłow <pp@siedziba.pl> wrote:

> On 23.10.2014 16:24, Roman Mamedov wrote:
> > 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'?

> 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.

-- 
With respect,
Roman

Re: "Transaction commit" in btrfs sub del

[Wang Shilong]

On Thu, 23 Oct 2014 17:44:46 +0200
> Piotr Pawłow <pp@siedziba.pl> wrote:
> 
>> On 23.10.2014 16:24, Roman Mamedov wrote:
>>> 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’?

They could have same effects..
but doing ’sync’ is much more heavy than options..


> 
>> 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.
> 
> -- 
> With respect,
> Roman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Best Regards,
Wang Shilong