From: Roman Mamedov <rm@romanrm.net>
To: David Sterba <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org, clm@fb.com,
Alex Lyakas <alex.btrfs@zadarastorage.com>
Subject: Re: [PATCH] btrfs-progs: add options to sync filesystem after subvol delete
Date: Fri, 29 Nov 2013 01:36:38 +0600 [thread overview]
Message-ID: <20131129013638.01ede78a@natsu> (raw)
In-Reply-To: <1385657947-26145-1-git-send-email-dsterba@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
On Thu, 28 Nov 2013 17:59:07 +0100
David Sterba <dsterba@suse.cz> 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?
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
--
With respect,
Roman
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2013-11-28 19:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-28 16:59 [PATCH] btrfs-progs: add options to sync filesystem after subvol delete David Sterba
2013-11-28 19:36 ` Roman Mamedov [this message]
2013-11-29 2:04 ` Wang Shilong
2013-11-29 17:37 ` David Sterba
2013-12-02 9:02 ` Wang Shilong
2013-12-09 23:32 ` David Sterba
2013-12-10 13:17 ` Chris Mason
2013-12-10 17:36 ` David Sterba
2013-12-10 18:24 ` Chris Mason
2013-12-12 18:07 ` David Sterba
2013-11-29 5:13 ` Miao Xie
2013-11-29 17:05 ` David Sterba
2013-11-29 8:05 ` Anand Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131129013638.01ede78a@natsu \
--to=rm@romanrm.net \
--cc=alex.btrfs@zadarastorage.com \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).