From: Chris Mason <clm@fb.com>
To: <dsterba@suse.cz>, David Sterba <dsterba@suse.cz>,
Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Cc: <dsterba@suse.cz>, Roman Mamedov <rm@romanrm.net>,
<linux-btrfs@vger.kernel.org>,
Alex Lyakas <alex.btrfs@zadarastorage.com>
Subject: Re: [PATCH] btrfs-progs: add options to sync filesystem after subvol delete
Date: Tue, 10 Dec 2013 08:17:07 -0500 [thread overview]
Message-ID: <20131210131707.16869.32138@ret> (raw)
In-Reply-To: <20131209233245.GF10658@twin.jikos.cz>
Quoting David Sterba (2013-12-09 18:32:45)
> On Mon, Dec 02, 2013 at 05:02:49PM +0800, Wang Shilong wrote:
> > >So an enahced interface could look like this:
> > >
> > >subvol delete:
> > >--commit-each - run the ioc sync/wait ioctl after each delete ioctl
> > >--commit-after - dtto but sync/wait after all are deleted
> > >--wait-for-cleanup - wait until all given subvols are cleaned
> > >
> > >'filesystem sync' exteded to wait for subvol cleanup has following
> > >cases:
> > >- wait for a specific subvolume to be cleaned
It may be hard to wait for a specific subvolume from btrfs fi sync.
You'd have to know the id, or have an interface that shows a list of ids
currently under deletion (not a bad idea ;)
> > >- wait for all currently deleted, do not care if more subvols are
> > > deleted in the meantime
> > >- wait until there are no subvolumes left to clean
> > I think it is unnecessary to add such options for 'filesystem sync'.
> > we may wait a long time until all subvolume deletion are finished as
> > async subvolume deletion is implemented in cleaner thread.:-)
>
> I mean that 'filesystem sync' will stay as it is now, but will be
> enhanced with a few options to further specify what else should be
> synced.
It's more natural to have the waiting in the subvol delete command, but
I'm not against adding a few ways to wait in btrfs fi sync too, as long
as they share the same core implementation.
-chris
next prev parent reply other threads:[~2013-12-10 13:32 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
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 [this message]
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=20131210131707.16869.32138@ret \
--to=clm@fb.com \
--cc=alex.btrfs@zadarastorage.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
--cc=wangsl.fnst@cn.fujitsu.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.