From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, chandan@mykolab.com
Subject: Re: [PATCH] Abort tests on mkfs failure
Date: Mon, 31 Aug 2015 16:11:37 +0530 [thread overview]
Message-ID: <1627818.5iIukl1gSh@localhost.localdomain> (raw)
In-Reply-To: <20150830232024.GL3902@dastard>
On Monday 31 Aug 2015 09:20:24 Dave Chinner wrote:
> On Sun, Aug 30, 2015 at 08:14:48PM +0530, Chandan Rajendra wrote:
> > When creating small Btrfs filesystem instances (i.e. filesystem size <=
> > 1GiB), mkfs.btrfs can fail if "data block size" does not match "metadata
> > block size". In such cases this commit aborts the test instead of letting
> > it to continue and report misleading results.
>
> NACK. Running the test, even with the wrong mkfs parameters, is more
> valuable to us than not running the test at all. This has been
> explained several times in the past 18 months when similar patches
> have been posted.
>
> What you need to do is prevent mkfs from failing in your new corner
> case on small filesystems, or fail the test in the the filesystem
> specific mkfs routine.
>
> e.g. Filesystems like xfs have custom functions (i.e.
> _scratch_mkfs_xfs) that prevent mkfs from failing in weird corner
> cases or when conflicting options are given (e.g. test option
> conflict with MKFS_OPTIONS given on the CLI).
>
> Or, you can make the btrfs mkfs command in _scratch_mkfs_sized()
> specially handle this specific btrfs configuration correctly, and if
> it can't then it should fail there.
>
Dave, Thanks for the guidance.
For Btrfs filesystem instances <= 1GiB in size, Btrfs creates "mixed"
block-groups i.e. block groups that are capable of holding data and metadata
blocks. Hence the requirement for such instances to have the same block sizes
for "data" and "metadata". On such mismatched block sizes being provided as
input, mkfs.btrfs exits without making any changes to the underlying disk
(which may actually have a different filesystem created on it).
Based on this reasoning, I will write a patch that detects the conflict and
fails in btrfs specific command in _scratch_mkfs_sized() function.
--
chandan
prev parent reply other threads:[~2015-08-31 10:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-30 14:44 [PATCH] Abort tests on mkfs failure Chandan Rajendra
2015-08-30 23:20 ` Dave Chinner
2015-08-31 10:41 ` Chandan Rajendra [this message]
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=1627818.5iIukl1gSh@localhost.localdomain \
--to=chandan@linux.vnet.ibm.com \
--cc=chandan@mykolab.com \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@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).