All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.