From: Eryu Guan <guaneryu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH v2 4/5] shared,generic: move shared/006 to generic/
Date: Sun, 7 Jul 2019 20:51:19 +0800 [thread overview]
Message-ID: <20190707125119.GI7943@desktop> (raw)
In-Reply-To: <20190706034053.GB11665@mit.edu>
On Fri, Jul 05, 2019 at 11:40:53PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 05, 2019 at 04:07:57PM +0800, Eryu Guan wrote:
> > > +_require_scratch_inode_limits()
> > > +{
> > > + _require_scratch
> > > + _scratch_mkfs > /dev/null 2>&1
> > > + _scratch_mount
> > > + if [ $(_get_free_inode $SCRATCH_MNT) -eq 0 ]; then
> > > + _notrun "$FSTYP does not have a fixed number of inodes available"
> > > + fi
> > > + _scratch_unmount
> > > +}
> >
> > I think testing against $TEST_DIR should be sufficient, so we could
> > avoid the mkfs & mount & umount SCRATCH_DEV time.
>
> I was following the pattern that I saw with other similar _require
> tests (for example: _require_scratch_shutdown). I *thought* the
> reason why this is was done is because if the test only uses the
> SCRATCH_DEV, there's no making it a requirement that TEST_DEV be
> available --- since IIRC, we do support SCRATCH_DEV being available,
> but not TEST_DEV.
>
> I personally don't use xfstests in that way --- when I run xfstests,
> TEST_DEV is always available and in some cases, SCRATCH_DEV won't be
> present. But I thought that's why _require_test exists --- so that
> tests can be skipped if TEST_DEV does not exist.
xfstests assumes TEST_DEV is always present and SCRATCH_DEV is optional
(but recommended). _require_test not only checks if TEST_DEV is avaiable
& properly mounted but also implies we should do fsck against TEST_DEV
after test, as _require_test does "touch ${RESULT_DIR}/require_test" as
well.
Regarding to _require_scratch_xxx, that's usually because the
requirement being checked might change when mkfs with different options.
But a filesystem will always have a fixed number of inodes no matter
what mkfs options it uses (the same is true for not having a fixed
number of inodes). So in this case, I think check against
TEST_DEV/TEST_DIR should be fine.
Thanks,
Eryu
next prev parent reply other threads:[~2019-07-07 12:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 22:59 [PATCH v2 1/5] shared,ext4: move ext4-specific tests out of shared/ Theodore Ts'o
2019-06-28 22:59 ` [PATCH v2 2/5] check: add ext4 group list when testing ext2 and ext3 Theodore Ts'o
2019-06-28 22:59 ` [PATCH v2 3/5] shared,ext4: move ext[234]-specific tests out of shared/ Theodore Ts'o
2019-06-28 22:59 ` [PATCH v2 4/5] shared,generic: move shared/006 to generic/ Theodore Ts'o
2019-07-05 8:07 ` Eryu Guan
2019-07-06 3:40 ` Theodore Ts'o
2019-07-07 12:51 ` Eryu Guan [this message]
2019-06-28 22:59 ` [PATCH v2 5/5] shared,generic: move tests using duperemove " Theodore Ts'o
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=20190707125119.GI7943@desktop \
--to=guaneryu@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=tytso@mit.edu \
/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.