From: "Dilger, Andreas" <andreas.dilger@intel.com>
To: "tytso@mit.edu" <tytso@mit.edu>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: "make check" broken on maint branch?
Date: Thu, 31 Oct 2013 21:35:25 +0000 [thread overview]
Message-ID: <CE98293A.7BB07%andreas.dilger@intel.com> (raw)
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?
Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel High Performance Data Division
next reply other threads:[~2013-10-31 21:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 21:35 Dilger, Andreas [this message]
2013-11-01 2:35 ` "make check" broken on maint branch? Zheng Liu
2013-11-01 3:21 ` Theodore Ts'o
2013-11-01 13:12 ` Zheng Liu
2013-11-01 16:48 ` Theodore Ts'o
2013-11-04 6:20 ` Zheng Liu
2013-11-01 18:24 ` Dilger, Andreas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CE98293A.7BB07%andreas.dilger@intel.com \
--to=andreas.dilger@intel.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.