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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
