From: "Theodore Ts'o" <tytso@mit.edu>
To: Eryu Guan <guan@eryu.me>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
guaneryu@gmail.com, linux-xfs@vger.kernel.org,
fstests@vger.kernel.org
Subject: Re: [PATCH 5/9] common/dmthin: make this work with external log devices
Date: Sun, 18 Apr 2021 10:44:08 -0400 [thread overview]
Message-ID: <YHxFuFvbAiiIrbIo@mit.edu> (raw)
In-Reply-To: <YHwlTMySYgKuaw6Y@desktop>
On Sun, Apr 18, 2021 at 08:25:48PM +0800, Eryu Guan wrote:
> > diff --git a/tests/generic/223 b/tests/generic/223
> > index 1f85efe5..a5ace82f 100755
> > --- a/tests/generic/223
> > +++ b/tests/generic/223
> > @@ -43,6 +43,9 @@ for SUNIT_K in 8 16 32 64 128; do
> > _scratch_mkfs_geom $SUNIT_BYTES 4 $BLOCKSIZE >> $seqres.full 2>&1
> > _scratch_mount
> >
> > + # Make sure everything is on the data device
> > + $XFS_IO_PROG -c 'chattr -t' $SCRATCH_MNT
>
> What does this do for non-xfs filesystems? Do we need a FSTYP check and
> do chattr only on XFS?
This clears the FS_NOTAIL_FL flag, which prevents tail merging, on the
root directory of the mounted scratch file system. That should be
harmless on non-xfs file systems; in fact, the only file system that
even uses NOTAIL_FL flag is reiserfs, and the NOTAIL_FL flag is not
set by default on the root directory of a newly created reiserfs file
system.
However, by default reiserfs does not support the
FS_IOC_{GET,SET}FLAGS ioctl unless the mount option "attrs" is given.
Why, I have no idea:
root@kvm-xfstests:~# mount -t reiserfs /vtmp/foo.img /mnt
root@kvm-xfstests:~# xfs_io -c 'chattr -t' /mnt
xfs_io: cannot get flags on /mnt: Inappropriate ioctl for device
So it might be a good idea to redirect stderr for the xfs_io
invocation to /dev/null, for those file systems which do not support
the FS_IOC_{GET,SET}FLAGS ioctls.
I also have no idea why this helps for xfs --- I would think it's a
no-op, but I'm guessing there's some magical side-effect which is
taking place when FS_IOC_SETFLAGS ioctl is processed? Maybe it would
be worth a comment explaining what is going on --- and whether this is
going to make any difference if the patch series which unifies
FS_IOC_{GETSET}FLAGS handling is merged?
- Ted
next prev parent reply other threads:[~2021-04-18 14:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 1:04 [PATCHSET 0/9] fstests: random fixes Darrick J. Wong
2021-04-14 1:04 ` [PATCH 1/9] xfs/506: fix regression on freshly quotachecked filesystem Darrick J. Wong
2021-04-14 6:12 ` Christoph Hellwig
2021-04-14 1:04 ` [PATCH 2/9] generic/563: selectively remove the io cgroup controller Darrick J. Wong
2021-04-14 6:13 ` Christoph Hellwig
2021-04-14 1:04 ` [PATCH 3/9] xfs/521,530: refactor scratch fs check Darrick J. Wong
2021-04-14 6:15 ` Christoph Hellwig
2021-04-14 1:04 ` [PATCH 4/9] common/dump: filter out xfs_restore messages about fallocate failures Darrick J. Wong
2021-04-14 6:16 ` Christoph Hellwig
2021-04-14 1:05 ` [PATCH 5/9] common/dmthin: make this work with external log devices Darrick J. Wong
2021-04-14 6:17 ` Christoph Hellwig
2021-04-18 12:25 ` Eryu Guan
2021-04-18 14:44 ` Theodore Ts'o [this message]
2021-04-19 2:04 ` Dave Chinner
2021-04-19 16:14 ` Darrick J. Wong
2021-04-14 1:05 ` [PATCH 6/9] misc: replace more open-coded _scratch_xfs_db calls Darrick J. Wong
2021-04-14 6:18 ` Christoph Hellwig
2021-04-14 1:05 ` [PATCH 7/9] generic/620: fix order of require_scratch calls Darrick J. Wong
2021-04-14 6:20 ` Christoph Hellwig
2021-04-14 1:05 ` [PATCH 8/9] generic/{094,225}: skip test when the xfs rt extent size is larger than 1 fsb Darrick J. Wong
2021-04-14 6:20 ` Christoph Hellwig
2021-04-14 1:05 ` [PATCH 9/9] xfs/305: make sure that fsstress is still running when we quotaoff Darrick J. Wong
2021-04-14 6:21 ` Christoph Hellwig
2021-04-14 14:38 ` Darrick J. Wong
2021-04-20 6:21 ` Christoph Hellwig
2021-04-18 12:29 ` [PATCHSET 0/9] fstests: random fixes Eryu Guan
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=YHxFuFvbAiiIrbIo@mit.edu \
--to=tytso@mit.edu \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=guan@eryu.me \
--cc=guaneryu@gmail.com \
--cc=linux-xfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox