From: Dave Chinner <david@fromorbit.com>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: fstests@vger.kernel.org, fdmanana@gmail.com
Subject: Re: [PATCH 2/2] generic/017: Do not create file systems with different block sizes
Date: Tue, 24 Jun 2014 15:48:54 +1000 [thread overview]
Message-ID: <20140624054854.GG9508@dastard> (raw)
In-Reply-To: <alpine.LFD.2.00.1406240643160.2556@localhost.localdomain>
On Tue, Jun 24, 2014 at 06:50:15AM +0200, Lukáš Czerner wrote:
> On Tue, 24 Jun 2014, Dave Chinner wrote:
>
> > Date: Tue, 24 Jun 2014 14:38:35 +1000
> > From: Dave Chinner <david@fromorbit.com>
> > To: Lukas Czerner <lczerner@redhat.com>
> > Cc: fstests@vger.kernel.org, fdmanana@gmail.com
> > Subject: Re: [PATCH 2/2] generic/017: Do not create file systems with
> > different block sizes
> >
> > On Mon, Jun 23, 2014 at 04:54:15PM +0200, Lukas Czerner wrote:
> > > User takes care about specifying mkfs options he wishes to test and the
> > > test itself should not change it if it's not strictly necessary for the
> > > test itself.
> > >
> > > In this case it is not necessary and we should only test configuration
> > > provided by the user. Moreover if the block size was already specified
> > > some mkfs utilities does not handle multiple of the same parameters and
> > > the mkfs utility fails making it re-try with only provided options
> > > (ignoring what user specified), which is wrong.
> >
> > I disagree strongly with this justification. The test is perfectly
> > fine: it is allowed to do whatever it wants with mkfs and mount
> > options.
> >
> > It is up to the implementations of the specific FSTYP mkfs
> > implementation called from _scratch_mkfs to handle
> > conflicting/unsupported options sanely, not the test....
>
> I agree, the test should not care about those options at all.
That's not what I said. I said the test is perfectly entitled
to test whatever options it wants to.
The user specified configs are *behavioural modifiers*, not a
draconian "this is all we test" rule.
> That's
> why I removed it. What was done in this test was entirely
> unnecessary and was not done in any other similar test before.
Not true. There are tests that override user specified configs all
over the place. There's at least 50 calls to _scratch_mkfs_xfs with
specific options across all the XFS tests, some of which
specifically override block size so they can test sub-page block
size behaviour.
Indeed, there's a bunch of specific options passed into
_scratch_mkfs in the btrfs tests, too, so this sort of constrained
test configuration behaviour is not limited to just XFS.
IOWs, what needs to happen here is that btrfs needs to grow an
equivalent _scratch_mkfs_btrfs that drops conflicting options and
filters unsupported options so that tests don't need to care about
what a filesystem supports or doesn't support....
> Yes, we can test all block size in every test from now on, but
> what's the point? We have a config file and the user can set
> whatever block size he wants to test. I do not dispute that there
> is a time when we really want to set a specific mkfs options in
> the test, but this is not the case at all.
Most people don't test multiple different block sizes, so unless
there is excessive runtime saying "but you can specify it manually"
is not a valid reason for preventing a single test from iterating
over multiple mkfs and/or mount configurations.
> Moreover, if I want to test specific mkfs configuration the current
> approach might not work as it will replace the options.
Only if they conflict. And in that case, it's better to simply run
the test the way it was intended to be run than it is to fail or
not_run it...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2014-06-24 5:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 14:54 [PATCH 1/2] xfstests: Introduce get_block_size() helper Lukas Czerner
2014-06-23 14:54 ` [PATCH 2/2] generic/017: Do not create file systems with different block sizes Lukas Czerner
2014-06-23 18:12 ` Filipe David Manana
2014-06-24 4:38 ` Dave Chinner
2014-06-24 4:50 ` Lukáš Czerner
2014-06-24 5:48 ` Dave Chinner [this message]
2014-06-24 6:17 ` Lukáš Czerner
2014-06-24 6:45 ` Dave Chinner
2014-06-24 9:08 ` Lukáš Czerner
2014-06-24 8:40 ` Filipe David Manana
2014-06-23 18:12 ` [PATCH 1/2] xfstests: Introduce get_block_size() helper Filipe David Manana
2014-06-24 4:28 ` Dave Chinner
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=20140624054854.GG9508@dastard \
--to=david@fromorbit.com \
--cc=fdmanana@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=lczerner@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.