All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Miao Xie <miaox@cn.fujitsu.com>
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 18:05:47 +0100	[thread overview]
Message-ID: <20131129170547.GO25312@suse.cz> (raw)
In-Reply-To: <52982287.4040808@cn.fujitsu.com>

On Fri, Nov 29, 2013 at 01:13:43PM +0800, Miao Xie wrote:
> >  static int cmd_subvol_delete(int argc, char **argv)
> >  {
> > -	int	res, fd, len, e, cnt = 1, ret = 0;
> > +	int	res, len, e, ret = 0;
> > +	int cnt;
> > +	int fd = -1;
> >  	struct btrfs_ioctl_vol_args	args;
> >  	char	*dname, *vname, *cpath;
> >  	char	*dupdname = NULL;
> >  	char	*dupvname = NULL;
> >  	char	*path;
> >  	DIR	*dirstream = NULL;
> > +	int sync_mode = 0;
> > +	struct option long_options[] = {
> > +		{"sync-after", no_argument, NULL, 's'},	/* sync mode 1 */
> > +		{"sync-each", no_argument, NULL, 'S'},	/* sync mode 2 */
> > +		{NULL, 0, NULL, 0}
> > +	};
> 
> Generally, we put it out of the functions.

I see that there are several long option definitions inside the function
that uses them, one example is in the same file in cmds_subvol_list, and
I've followed that pattern.

I think it makes a bit more sense to keep the options local to the
function, definition and usage are close together. The does not have
more than one user, although this is possible but unlikely among btrfs
commands.

> > @@ -285,14 +326,38 @@ again:
> >  		goto out;
> >  	}
> >  
> > +	if (sync_mode == 1) {
> > +		res = ioctl(fd, BTRFS_IOC_SYNC);
> 
> It will flush all the dirty pages, it is unnecessary. I think
> BTRFS_IOC_{START, WAIT}_SYNC is better.

I agree and this is what I actually wanted.

  reply	other threads:[~2013-11-29 17:05 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
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 [this message]
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=20131129170547.GO25312@suse.cz \
    --to=dsterba@suse.cz \
    --cc=alex.btrfs@zadarastorage.com \
    --cc=clm@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=miaox@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.