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. -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
