Re: "make check" broken on maint branch?

[Zheng Liu <gnehzuil.liu@gmail.com>]

Hi Andreas,

On Thu, Oct 31, 2013 at 09:35:25PM +0000, Dilger, Andreas wrote:
> It seems that the current e2fsprogs "maint" branch has broken tests?
> At least on two different systems I tried this on had the same problem:
> 
>   r_64bit_big_expand: very large fs growth using ext4 w/64bit: failed
>   r_bigalloc_big_expand: ext4 with bigalloc: failed
>   r_ext4_big_expand: very large fs growth using ext4: failed
> 
> The test logs show:
> 
>   /tmp/e2fsprogs-tmp.VitAZy: 13/32768 files (7.7% non-contiguous),
> 6870/131072 blocks
>   ../resize/resize2fs -d 31 /tmp/e2fsprogs-tmp.VitAZy 2T
>   resize2fs 1.42.8 (20-Jun-2013)
>   The containing partition (or device) is only 131072 (4k) blocks.
>   You requested a new size of 536870912 blocks.
> 
> 
> I tried to add in a "truncate -s $SIZE_2 $TMPFILE", but it complains that
> it
> isn't able to truncate the file in /tmp to 2TB:
> 
>   truncating `/tmp/e2fsprogs-tmp.OGxb09' at 2199023255552 bytes: File too
> large
> 
> Testing manually, it seems I'm not allowed to create a file in tmpfs larger
> than 256GB.  How large does this file need to be for this test to be valid?
> 
> 
> I'm also seeing a consistent test failure in f_extent_oobounds on ONE of
> the
> two systems, though I can't see why the results are inconsistent since they
> have the same GCC, glibc and almost the same kernel (RHEL
> 2.6.32-358.11.1.el6
> and 2.6.32-279.5.1.el6, not that it should make any difference).
> 
>   more f_extent*.failed
>   --- f_extent_oobounds/expect.1  2013-10-31 20:01:06.299616314 +0000
>   +++ f_extent_oobounds.1.log     2013-10-31 21:16:21.008616804 +0000
>   @@ -1,24 +1,20 @@
>    Pass 1: Checking inodes, blocks, and sizes
>   -Inode 12, end of extent exceeds allowed value
>   -       (logical block 15, physical block 200, len 30)
>   -Clear? yes
>   -
>   -Inode 12, i_blocks is 154, should be 94.  Fix? yes
>   +Inode 12, i_blocks is 154, should be 0.  Fix? yes
> 
> This is still true after "make distclean" and rebuilding the whole tree.
> It seems that e2fsck isn't detecting the new PR_1_EXTENT_END_OUT_OF_BOUNDS
> problem on this system for some reason?  Usually this kind of inconsistency
> is due to some uninitialized stack variable being used that is different
> on the two systems.
> 
> 
> Anyone else seen these problems, or do I need to dig in further?

Yes, I also can see these problems.

Thanks,
                                                - Zheng