Discussion:
"Transaction commit" in btrfs sub del
(too old to reply)
Roman Mamedov
2014-10-23 14:24:11 UTC
Permalink
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Piotr Pawłow
2014-10-23 15:44:46 UTC
Permalink
Post by 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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Roman Mamedov
2014-10-23 16:18:03 UTC
Permalink
On Thu, 23 Oct 2014 17:44:46 +0200
I was under impression that the "Transaction commit:" setting in 'b=
trfs sub
del' finally allows us to make it not return until all free space f=
rom the
snapshots that are being deleted, is completely freed up.
=20
This is not what "commit-each" or "commit-after" options do. These ar=
e=20
only to make sure, that the deletion is commited and the subvolume=20
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=
=20
btrfs subvolume sync <path> [<subvol-id>...]
Wait until given subvolume(s) are completely removed from th=
e=20
filesystem.
Oh right, *that*'s the one I was thinking of.

--=20
With respect,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Wang Shilong
2014-10-23 16:28:08 UTC
Permalink
On Thu, 23 Oct 2014 17:44:46 +0200
=20
I was under impression that the "Transaction commit:" setting in 'b=
trfs sub
del' finally allows us to make it not return until all free space f=
rom the
snapshots that are being deleted, is completely freed up.
=20
This is not what "commit-each" or "commit-after" options do. These a=
re=20
only to make sure, that the deletion is commited and the subvolume=20
doesn't reappear after a crash.
=20
But is that not already ensured by a regular 'sync', or 'btrfs fi syn=
c=E2=80=99?

They could have same effects..
but doing =E2=80=99sync=E2=80=99 is much more heavy than options..
=20
You probably want "subvolume sync" command, introduced in btrfs-prog=
=20
btrfs subvolume sync <path> [<subvol-id>...]
Wait until given subvolume(s) are completely removed from th=
e=20
filesystem.
=20
Oh right, *that*'s the one I was thinking of.
=20
--=20
With respect,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Best Regards,
Wang Shilong

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...