shared/289 failures on metadata_csum, e2fsprogs master branch

DISCUSSION Eric Whitney 2 participants 3 messages Mar 11, 2014

Share & tools

Eric Whitney

author

2014-03-11 19:38 UTC #0 lore 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

Darrick J. Wong

2014-03-11 20:45 UTC #1 lore raw

Quoted 15 lines · 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).

Quoted 8 lines

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

Quoted 7 lines

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

Eric Whitney

author

2014-03-11 21:20 UTC #2 lore raw

* Darrick J. Wong <[email protected]>:

Quoted 25 lines · Eric Whitney

Quoted 15 lines
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).
Quoted 8 lines
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... :-) ).

Quoted 3 lines

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

Quoted 8 lines

--D
Quoted 7 lines
Thanks,
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html