linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Whitney <enwlinux@gmail.com>
To: linux-ext4@vger.kernel.org
Subject: shared/289 failures on metadata_csum, e2fsprogs master branch
Date: Tue, 11 Mar 2014 15:38:19 -0400	[thread overview]
Message-ID: <20140311193819.GA2274@wallace> (raw)

Xfstest shared/289 fails when run on an ext4 test filesystem created with
the metadata_csum and 64bit options and using executables from the latest
e2fsprogs master branch (46d2a26683).  I've seen the problem on kernel
versions from 3.14-rc1 through 3.14-rc6, but I think this is an e2fsprogs
regression rather than a kernel problem.

The failing portion of shared/289 can be boiled down to:

mkfs.ext4 -O metadata_csum,64bit /dev/vdc
dumpe2fs -h /dev/vdc 2>/dev/null | awk '/Free blocks:/{print $3}'

The problem (in my test config) is that the reported free block value is
184684916231 (much larger than my test device) where the reported block
count is 1382400 (much saner).

The bug appears to have been introduced between two merges of the maint
branch: 72958b6670 (good - 10 Jan) and f0996c12d5 (bad - 30 Jan).  Some
weeks ago, I thought I'd bisected the problem to a specific patch
(8e44eb64bb - libext2fs: mark group data blocks when loading block bitmap),
which seemed like a plausible candidate.  However, I find I can't
reproduce the bisection now, as e2fsprogs doesn't want to support the
metadata_csum, 64bit options during bisection in the master branch (that'll
teach me for not mentioning this earlier... :-) ).

Thanks,
Eric

             reply	other threads:[~2014-03-11 19:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11 19:38 Eric Whitney [this message]
2014-03-11 20:45 ` shared/289 failures on metadata_csum, e2fsprogs master branch Darrick J. Wong
2014-03-11 21:20   ` Eric Whitney

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=20140311193819.GA2274@wallace \
    --to=enwlinux@gmail.com \
    --cc=linux-ext4@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).