All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcos Paulo de Souza <mpdesouza@suse.de>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.com, wqu@suse.com
Subject: Re: [PATCH] btrfs: Add new flag to rescan quota after subvolume creation
Date: Wed, 09 Jun 2021 14:44:45 -0300	[thread overview]
Message-ID: <b70c23ab25fe327b8a4a18511a5d1b2d1c2ae3f5.camel@suse.de> (raw)
In-Reply-To: <20210525162054.GE7604@twin.jikos.cz>

On Tue, 2021-05-25 at 18:20 +0200, David Sterba wrote:
> On Fri, May 21, 2021 at 11:38:11AM -0300, Marcos Paulo de Souza
> wrote:
> > Adding a new subvolume/snapshot makes the qgroup data inconsistent,
> > so
> > add a new flag to inform the subvolume ioctl to do a quota rescan
> > right
> > after the subvolume/snapshot creation.
> > 
> > Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
> > ---
> > 
> >  This is an attempt to help snapper to create snapshots with
> > 'timeline'
> >  cleanup-policy to keep the qgroup data consistent after a new
> > snapshot is
> >  created.
> 
> I'm not sure adding something like rescan into subvolume creation. It
> can be started separately as a workaround. The problem I see is that
> there are two big things happening and both can fail, but there's
> only
> one return value and the user can tell which one failed.

Agreed. Indeed, it's much easier to issue another ioctl to do a quota
rescan.

> 
> > +	if (vol_args->flags & BTRFS_SUBVOL_QGROUP_RESCAN) {
> > +		if (!capable(CAP_SYS_ADMIN)) {
> > +			ret = -EPERM;
> 
> Eg. here, did the subvolume creation fail due to EPERM, or the
> rescan?

Agreed.

> 
> > +			goto free_args;
> > +		}
> > +
> > +		quota_rescan = true;
> > +	}
> > +
> >  	if (vol_args->flags & BTRFS_SUBVOL_RDONLY)
> >  		readonly = true;
> >  	if (vol_args->flags & BTRFS_SUBVOL_QGROUP_INHERIT) {
> > @@ -1843,6 +1869,22 @@ static noinline int
> > btrfs_ioctl_snap_create_v2(struct file *file,
> >  					subvol, readonly, inherit);
> >  	if (ret)
> >  		goto free_inherit;
> > +
> > +	if (quota_rescan) {
> > +		ret = do_quota_rescan(file);
> > +		/*
> > +		 * EINVAL is returned if quota is not enabled. There is
> > already
> > +		 * a warning issued if quota rescan is started when
> > quota is not
> > +		 * enabled, so skip a warning here if it is the case.
> > +		 */
> > +		if (ret < 0 && ret != -EINVAL)
> > +			btrfs_warn(btrfs_sb(file_inode(file)->i_sb),
> > +		"Couldn't execute quota rescan after snapshot creation:
> > %d",
> > +					ret);
> > +		else
> > +			ret = 0;
> 
> That's another special case and the system error message is required
> to
> interpret the error code but we've seen in the past that this is not
> a
> good usability pattern.

Agreed.

> 
> > +#define BTRFS_SUBVOL_QGROUP_RESCAN	(1ULL << 5)
> > +
> >  #define BTRFS_VOL_ARG_V2_FLAGS_SUPPORTED		\
> >  			(BTRFS_SUBVOL_RDONLY |		\
> >  			BTRFS_SUBVOL_QGROUP_INHERIT |	\
> >  			BTRFS_DEVICE_SPEC_BY_ID |	\
> > -			BTRFS_SUBVOL_SPEC_BY_ID)
> > +			BTRFS_SUBVOL_SPEC_BY_ID |	\
> > +			BTRFS_SUBVOL_QGROUP_RESCAN)
> 
> The idea of bits is to extend mode of operation of the ioctls, not to
> proxy other functionality. What I'd see as reasonable would be
> something
> like conditionally marking the quotas inconsistent by setting a bit
> after snapshot creation and when quotas are enabled. But the snapshot
> creation should do only snapshot creation.

It's much easier to change snapper in order to execute a quota rescan
when the quota data is inconsistent (due to a new snapshot being
created for example).



      reply	other threads:[~2021-06-09 17:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 14:38 [PATCH] btrfs: Add new flag to rescan quota after subvolume creation Marcos Paulo de Souza
2021-05-25 16:20 ` David Sterba
2021-06-09 17:44   ` Marcos Paulo de Souza [this message]

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=b70c23ab25fe327b8a4a18511a5d1b2d1c2ae3f5.camel@suse.de \
    --to=mpdesouza@suse.de \
    --cc=dsterba@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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.