From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: zlang@redhat.com, linux-xfs@vger.kernel.org, guan@eryu.me,
fstests@vger.kernel.org
Subject: Re: [PATCH 6/8] xfs/122: update test to pick up rtword/suminfo ondisk unions
Date: Thu, 29 Feb 2024 09:48:31 -0800 [thread overview]
Message-ID: <20240229174831.GB1927156@frogsfrogsfrogs> (raw)
In-Reply-To: <Zd9TsVxjRTXu8sa5@infradead.org>
On Wed, Feb 28, 2024 at 07:39:29AM -0800, Christoph Hellwig wrote:
> On Tue, Feb 27, 2024 at 05:27:04PM -0800, Darrick J. Wong wrote:
> > On Tue, Feb 27, 2024 at 06:54:41AM -0800, Christoph Hellwig wrote:
> > > Can we please just kill the goddamn test? Just waiting for the
> > > xfsprogs 6.8 resync to submit the static_asserts for libxfs that
> > > will handle this much better.
> >
> > I'll be very happen when we scuttle xfs/122 finally.
> >
> > However, in theory it's still be useful for QA departments to make sure
> > that xfsprogs backports (HA!) don't accidentally break things.
> >
> > IOWs, I advocate for _notrunning this test if xfsprogs >= 6.8 is
> > detected, not removing it completely.
> >
> > Unless someone wants to chime in and say that actually, nobody backports
> > stuff to old xfsprogs? (We don't really...)
>
> Well, who is going to backport changes to the on-disk format in a way
> that is complex enough to change strutures, and not also backport the
> patch to actually check the sizes? Sounds like a weird use case to
> optimize for.
It turns out that xfs/122 also captures ioctl structure sizes, and those
are /not/ captured by xfs_ondisk.h. I think we should add those before
we kill xfs/122.
--D
next prev parent reply other threads:[~2024-02-29 17:48 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 2:00 [PATCHSET] fstests: random fixes for v2024.02.09 Darrick J. Wong
2024-02-27 2:00 ` [PATCH 1/8] generic/604: try to make race occur reliably Darrick J. Wong
2024-02-27 4:04 ` Zorro Lang
2024-02-27 4:27 ` Darrick J. Wong
2024-02-27 4:40 ` [PATCH v1.1 " Darrick J. Wong
2024-02-27 5:15 ` Zorro Lang
2024-02-27 14:52 ` Christoph Hellwig
2024-03-02 11:44 ` Zorro Lang
2024-02-27 2:01 ` [PATCH 2/8] xfs/155: fail the test if xfs_repair hangs for too long Darrick J. Wong
2024-02-27 4:16 ` Zorro Lang
2024-02-27 4:41 ` [PATCH v1.1 " Darrick J. Wong
2024-02-27 5:14 ` Zorro Lang
2024-02-27 14:52 ` Christoph Hellwig
2024-02-27 2:01 ` [PATCH 3/8] generic/192: fix spurious timeout Darrick J. Wong
2024-02-27 4:23 ` Zorro Lang
2024-02-27 4:29 ` Darrick J. Wong
2024-02-27 14:53 ` Christoph Hellwig
2024-02-27 2:01 ` [PATCH 4/8] generic/491: increase test timeout Darrick J. Wong
2024-02-27 4:28 ` Zorro Lang
2024-02-27 14:53 ` Christoph Hellwig
2024-02-27 2:01 ` [PATCH 5/8] xfs/599: reduce the amount of attrs created here Darrick J. Wong
2024-02-27 4:33 ` Zorro Lang
2024-02-27 2:02 ` [PATCH 6/8] xfs/122: update test to pick up rtword/suminfo ondisk unions Darrick J. Wong
2024-02-27 5:10 ` Zorro Lang
2024-02-27 14:54 ` Christoph Hellwig
2024-02-28 1:27 ` Darrick J. Wong
2024-02-28 15:39 ` Christoph Hellwig
2024-02-29 17:48 ` Darrick J. Wong [this message]
2024-02-29 19:42 ` Christoph Hellwig
2024-03-01 13:18 ` Zorro Lang
2024-03-01 17:50 ` Darrick J. Wong
2024-03-02 4:55 ` Zorro Lang
2024-03-07 23:24 ` Darrick J. Wong
2024-02-27 2:02 ` [PATCH 7/8] xfs/43[4-6]: make module reloading optional Darrick J. Wong
2024-02-27 5:31 ` Zorro Lang
2024-02-28 1:28 ` Darrick J. Wong
2024-03-01 17:51 ` [PATCH v1.1 " Darrick J. Wong
2024-03-02 12:04 ` Zorro Lang
2024-02-27 2:02 ` [PATCH 8/8] xfs: test for premature ENOSPC with large cow delalloc extents Darrick J. Wong
2024-02-27 6:00 ` Zorro Lang
2024-02-28 1:36 ` Darrick J. Wong
2024-03-01 17:52 ` [PATCH v1.1 " Darrick J. Wong
2024-03-02 20:50 ` Zorro Lang
2024-03-07 23:17 ` Darrick J. Wong
2024-03-07 23:22 ` [PATCH v1.2 " Darrick J. Wong
2024-03-10 9:17 ` Zorro Lang
2024-03-10 16:26 ` Darrick J. Wong
2024-03-11 13:40 ` Zorro Lang
2024-03-11 15:04 ` Darrick J. Wong
2024-03-03 13:34 ` [PATCHSET] fstests: random fixes for v2024.02.09 Zorro Lang
2024-03-07 23:18 ` Darrick J. Wong
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=20240229174831.GB1927156@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.