shared/289 failures on metadata_csum, e2fsprogs master branch

shared/289 failures on metadata_csum, e2fsprogs master branch

[Eric Whitney]

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

Re: shared/289 failures on metadata_csum, e2fsprogs master branch

[Darrick J. Wong]

On Tue, Mar 11, 2014 at 03:38:19PM -0400, Eric Whitney wrote:
> 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... :-) ).

This is fixed by patch #17 ("libext2fs: fix 64bit overflow in
ext2fs_block_alloc_stats_range") in the patchbomb I sent out earlier today.

--D
> 
> Thanks,
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: shared/289 failures on metadata_csum, e2fsprogs master branch

[Eric Whitney]

* Darrick J. Wong <darrick.wong@oracle.com>:
> On Tue, Mar 11, 2014 at 03:38:19PM -0400, Eric Whitney wrote:
> > 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... :-) ).
> 
> This is fixed by patch #17 ("libext2fs: fix 64bit overflow in
> ext2fs_block_alloc_stats_range") in the patchbomb I sent out earlier today.
> 

Works for me.

Thanks!
Eric


> --D
> > 
> > Thanks,
> > Eric
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html