linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: Filipe David Borba Manana <fdmanana@gmail.com>,
	fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] generic/017: skip invalid block sizes for btrfs
Date: Tue, 24 Jun 2014 14:26:46 +1000	[thread overview]
Message-ID: <20140624042646.GD9508@dastard> (raw)
In-Reply-To: <alpine.LFD.2.00.1406231606570.2169@localhost.localdomain>

On Mon, Jun 23, 2014 at 04:09:18PM +0200, Lukáš Czerner wrote:
> On Mon, 23 Jun 2014, Lukáš Czerner wrote:
> 
> > Date: Mon, 23 Jun 2014 14:35:50 +0200 (CEST)
> > From: Lukáš Czerner <lczerner@redhat.com>
> > To: Filipe David Borba Manana <fdmanana@gmail.com>
> > Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
> > Subject: Re: [PATCH] generic/017: skip invalid block sizes for btrfs
> > 
> > On Mon, 23 Jun 2014, Filipe David Borba Manana wrote:
> > 
> > > Date: Mon, 23 Jun 2014 11:28:00 +0100
> > > From: Filipe David Borba Manana <fdmanana@gmail.com>
> > > To: fstests@vger.kernel.org
> > > Cc: linux-btrfs@vger.kernel.org,
> > >     Filipe David Borba Manana <fdmanana@gmail.com>
> > > Subject: [PATCH] generic/017: skip invalid block sizes for btrfs
> > > 
> > > In btrfs the block size (called sector size in btrfs) can not be
> > > smaller then the page size. Therefore skip block sizes smaller
> > > then page size if the fs is btrfs, so that the test can succeed
> > > on btrfs (testing only with block sizes of 4kb on systems with a
> > > page size of 4Kb).
> > 
> > The test itself is wrong, it's trying to do _scratch_mkfs with
> > different block size, but the block size might already be specified
> > by the user (in fact it should be user responsibility to test
> > different block sizes). In the case that mkfs can not handle
> > multiple of the same option like mkfs.xfs for example it will fail,
> > but the test will go on with the original file system.
> > 
> > The test needs to be fixed to just test the file system with options
> > specified by the user. Also we should change _scratch_mkfs() to fail
> > the test if the mkfs failed (no one is actually testing mkfs_status
> > variable anyway.
> 
> Correction, _scratch_mkfs_xfs() is actually testing mkfs_status and
> will attempt to re-run mkfs only with provided options if it failed
> before. But my point remains the same, block size to test should be
> in users hands and we should run all tests with different block
> sizes, if supported.

Follow that line of reasoning to other options. If we take that
argument to it's logical conclusion, no test should be able to set
any mount or mkfs option because that's for the user to control.
This implies we can't even have quota specific tests because they
need to override the mount options (and perhaps mkfs options) the
user has specified to be properly tested.

Some tests only work on specific configurations and therefore they
need to be able to control the execution environment directly. Hence
the behaviour of _scratch_mkfs_xfs(), where it will *attempt* to use
the user provided options. However, if they conflict with what the
test requires it will drop the user options and use what the test
requires.

It's better that the test overrides user provided options than fail
due to incompatible configuration. It makes maintenance of the tests
much easier because we don't have to declare and maintain the
supported list of user options for every test. Either the test works
for all configurations (i.e. whatever the user sets in
MKFS/MOUNT_OPTIONS), or it specifically defines the configuration
it is testing.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2014-06-24  4:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 10:28 [PATCH] generic/017: skip invalid block sizes for btrfs Filipe David Borba Manana
2014-06-23 10:48 ` Satoru Takeuchi
2014-06-23 10:55   ` Filipe David Manana
2014-06-23 11:04     ` Satoru Takeuchi
2014-06-23 11:46   ` Brendan Hide
2014-06-23 12:35 ` Lukáš Czerner
2014-06-23 14:09   ` Lukáš Czerner
2014-06-23 17:39     ` Filipe David Manana
2014-06-24  4:26     ` Dave Chinner [this message]
2014-06-24  5:28       ` Lukáš Czerner
2014-06-23 22:23 ` Zach Brown
2014-06-24  4:58 ` Roman Mamedov

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=20140624042646.GD9508@dastard \
    --to=david@fromorbit.com \
    --cc=fdmanana@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=lczerner@redhat.com \
    --cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).