On 10/1/13 10:35 AM, Eric Sandeen wrote: > On 10/1/13 10:26 AM, Eric Sandeen wrote: >> On 9/30/13 8:57 PM, Theodore Ts'o wrote: >>> On Mon, Jul 08, 2013 at 04:27:21PM -0500, Eric Sandeen wrote: >>>> >>>> The actual problem seems to be that the test does successive "-M" minimal resizes, and eventually we resize into the middle of an inode table, leaving the end of the table beyond the fs. >>>> >>>> Point "resize2fs -M" at the attached image once or twice w/ fscks in between and you should see it. >>> >>> I've been going through my patch backlog, so I finally had a chance to >>> take a very close look at your test image. I now understand why >>> things are failing. >>> >>> 1) The test image (which you said was generated on a ppc e2fsprogs?) >>> was doing something very weird as far as the location of the >>> allocation bitmaps and inode table: >> >> Yes, this was just during a fedora build, during the "make check" phase. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=980519 >> >> No idea why things should be coming out differently, that's a bit >> alarming in and of itself. >> >> (Fedora isn't carrying any interesting patches to speak of). > > But I am doing this: > > %check > +# XXX ERS Hack for now; this bug has existed for a while, > +# i.e. it is not a regression in this release, but there > +# is no fix yet, and we need to get this package building. > +# See Bug 987133 - resize2fs tests failing on ppc, s390 > +rm -rf tests/r_1024_small_bg* > +rm -rf tests/r_64bit_big_expand* > +rm -rf tests/r_bigalloc_big_expand* > +rm -rf tests/r_ext4_big_expand* > make check > > I'll retest w/ your patches, thanks. Now all are passing on ppc64, last 3 are still failing on s390. :( -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
