On 11/29/2013 03:36 AM, Roman Mamedov wrote:
On Thu, 28 Nov 2013 17:59:07 +0100
David Sterba <dsterba@xxxxxxx> wrote:
Subvolume deletion does not do a full transaction commit. This can lead
to an unexpected result when the system crashes between deletion and
commit, the subvolume directory will appear again. Add options to request
filesystem sync after each deleted subvolume or after the last one.
If the command with sync option finishes succesfully, the subvolume(s)
deletion status is safely stored on the media.
A feature that people pretty often request, is a way to delete a subvolume,
and have some way to "sync", i.e. pause execution of their script until all
the space freed up by the deletion has been recovered and made available (e.g.
for the next round of their backup to run).
Does this patch now make this possible?
My understanding here is:
No, deleting subvolume is 'async'. this patch only gurantee that
subvolume deletion status is on-disk, but subvolume deletion work
still have not finished, it will run in the backgroud, if a crash happens,
the work will continue after rebooting.
Also, did you consider enhancing "btrfs fi sync" to sync the snapshot deletion
(it currently doesn't), rather than adding the "sync" options to deletion
itself? E.g. comparing to traditional tools, people would logically do:
$ rm /some/dir/some/file
$ sync
rather than something akin to
$ rm --sync /some/dir/some/file
subvolume deletion is a little different from command 'rm'.
To delete a subvolume, we have to run:
btrfs sub delete <subv>
If you run 'btrfs file sync' after 'btrfs sub delete' it will have same
effect as david's 'btrfs sub delete --sync' i think.
Thanks,
Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
