All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: zlang@redhat.com, fstests@vger.kernel.org, guan@eryu.me,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH 03/10] generic/710: repurpose this for exchangerange vs. quota testing
Date: Thu, 20 Jun 2024 09:55:26 -0700	[thread overview]
Message-ID: <20240620165526.GW103034@frogsfrogsfrogs> (raw)
In-Reply-To: <20240619172318.GR103034@frogsfrogsfrogs>

On Wed, Jun 19, 2024 at 10:23:18AM -0700, Darrick J. Wong wrote:
> On Tue, Jun 18, 2024 at 11:08:37PM -0700, Christoph Hellwig wrote:
> > On Mon, Jun 17, 2024 at 05:47:32PM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > 
> > > The exchange-range implementation is now completely separate from the
> > > old swapext ioctl.  We're deprecating the old swapext ioctl, so let's
> > > move this test to use exchangerange.
> > 
> > Do we really want to lost the swapext test coverage?  Even if it is
> > deprecated, it will be with us for a long time.  My vote for copy and
> > pasting this into a new test for exchrange.
> 
> Yeah, you're right that we should retain this test for the old swapext
> ioctl.  I'll fork the test into two -- one for swapext, another for
> exchangerange.

...except that the swapext ioctl doesn't support swapping forks if quota
is enabled and any of the user/group/project ids are different:


	/* User/group/project quota ids must match if quotas are enforced. */
	if (XFS_IS_QUOTA_ON(ip->i_mount) &&
	    (!uid_eq(VFS_I(ip)->i_uid, VFS_I(tip)->i_uid) ||
	     !gid_eq(VFS_I(ip)->i_gid, VFS_I(tip)->i_gid) ||
	     ip->i_projid != tip->i_projid))
		return -EINVAL;

I'll amend the commit message:

"There's no point in maintaining this test for the legacy swapext code
because it returns EINVAL if any quota is enabled and the two files have
different user/group/project ids.  Originally I had forward ported the
old swapext ioctl to use commitrange as its backend, but that will be
dropped in favor of porting xfs_fsr to use commitrange directly."

--D

  reply	other threads:[~2024-06-20 16:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18  0:46 [PATCHSET v30.6 2/6] fstests: atomic file updates Darrick J. Wong
2024-06-18  0:47 ` [PATCH 01/10] misc: split swapext and exchangerange Darrick J. Wong
2024-06-19  6:06   ` Christoph Hellwig
2024-06-18  0:47 ` [PATCH 02/10] misc: change xfs_io -c swapext to exchangerange Darrick J. Wong
2024-06-19  6:07   ` Christoph Hellwig
2024-06-18  0:47 ` [PATCH 03/10] generic/710: repurpose this for exchangerange vs. quota testing Darrick J. Wong
2024-06-19  6:08   ` Christoph Hellwig
2024-06-19 17:23     ` Darrick J. Wong
2024-06-20 16:55       ` Darrick J. Wong [this message]
2024-06-20 19:06         ` Zorro Lang
2024-06-20 19:20           ` Darrick J. Wong
2024-06-18  0:47 ` [PATCH 04/10] generic/717: remove obsolete check Darrick J. Wong
2024-06-19  6:09   ` Christoph Hellwig
2024-06-19 16:31     ` Darrick J. Wong
2024-06-20 18:58       ` Zorro Lang
2024-06-18  0:48 ` [PATCH 05/10] ltp/{fsstress,fsx}: make the exchangerange naming consistent Darrick J. Wong
2024-06-19  6:09   ` Christoph Hellwig
2024-06-18  0:48 ` [PATCH 06/10] misc: flip HAVE_XFS_IOC_EXCHANGE_RANGE logic Darrick J. Wong
2024-06-19  6:09   ` Christoph Hellwig
2024-06-18  0:48 ` [PATCH 07/10] src/fiexchange.h: update XFS_IOC_EXCHANGE_RANGE definitions Darrick J. Wong
2024-06-19  6:10   ` Christoph Hellwig
2024-06-18  0:48 ` [PATCH 08/10] xfs/122: fix for exchrange conversion Darrick J. Wong
2024-06-19  6:10   ` Christoph Hellwig
2024-06-18  0:49 ` [PATCH 09/10] xfs/206: screen out exchange-range from golden output Darrick J. Wong
2024-06-19  6:10   ` Christoph Hellwig
2024-06-18  0:49 ` [PATCH 10/10] swapext: make sure that we don't swap unwritten extents unless they're part of a rt extent(??) Darrick J. Wong
2024-06-19  6:11   ` Christoph Hellwig
2024-06-19 16:58     ` Darrick J. Wong
2024-06-20  4:24       ` Christoph Hellwig

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=20240620165526.GW103034@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.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.