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

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

[Bruce Guenter]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]


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 <bruce@untroubled.org>                http://untroubled.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Qu Wenruo]

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

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

[Bruce Guenter]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

On Thu, Jan 05, 2017 at 10:03:17AM +0800, Qu Wenruo wrote:
> To wait the deletion finish, please use "btrfs filesystem sync".

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 <bruce@untroubled.org>                http://untroubled.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Qu Wenruo]

At 01/07/2017 06:43 AM, Bruce Guenter wrote:
> On Thu, Jan 05, 2017 at 10:03:17AM +0800, Qu Wenruo wrote:
>> To wait the deletion finish, please use "btrfs filesystem sync".
>
> That doesn't entirely work either. It does appear to wait for something,
> but disk space available continues to increase after it exits.
>

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

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

[Bruce Guenter]

On Mon, Jan 09, 2017 at 09:44:15AM +0800, Qu Wenruo wrote:
> At 01/07/2017 06:43 AM, Bruce Guenter wrote:
> > On Thu, Jan 05, 2017 at 10:03:17AM +0800, Qu Wenruo wrote:
> >> To wait the deletion finish, please use "btrfs filesystem sync".
> >
> > That doesn't entirely work either. It does appear to wait for something,
> > but disk space available continues to increase after it exits.
> 
> 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.

There is no other activity on the partition at all.

-- 
Bruce Guenter <bruce@untroubled.org>                http://untroubled.org/