Red Hat Bugzilla – Bug 657553
[xfstests 243] ext4 incosistency with EOFBLOCK_FL
Last modified: 2011-05-23 16:29:51 EDT
Description of problem: When running xfstests test no. 243, ext4 filesystem becomes incosistent (EOFBLOCK_FL flag is lost). Version-Release number of selected component (if applicable): kernel-2.6.32-71.el6.x86_64 and kernel-2.6.32-71.8.1.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Install xfstests dependencies and xfstests: yum install rh-tests-kernel-filesystems-xfs-xfstests-1.4-66.noarch xfs-kmod xfsprogs xfsdump perl quota acl attr bind-utils bc indent rpm-build autoconf libtool popt-devel libblkid-devel readline-devel gettext policycoreutils-python shadow-utils libuuid-devel e4fsprogs e2fsprogs-devel gdbm-devel libaio-devel libattr-devel libacl-devel xfsprogs-devel (not all of them exists in rhel6 but that is not an issue) 2. Run xfstests test no. 243 for ext4, watch the output, e.g.: cd /mnt/tests/kernel/filesystems/xfs/xfstests TEST_PARAM_RUNTESTS="243" TEST_PARAM_FSTYPE="ext4" make 3. Watch the output Actual results: Ext4 will have EOFBLOCK_FL flag set incorrectly causing ext4 fs inconsistency Expected results: Test passes. Additional info: Related beaker links: https://beaker.engineering.redhat.com/logs/2010/11/338/33854/67050/750980/2338583///test_log--kernel-filesystems-xfs-xfstests-243.log https://beaker.engineering.redhat.com/recipes/67049#task750975 Output of test: Running test 243 #! /bin/bash # FS QA Test No. 243 # # Test to ensure that the EOFBLOCK_FL gets set/unset correctly. # # As found by Theodore Ts'o: # If a 128K file is falloc'ed using the KEEP_SIZE flag, and then # write exactly 128K, the EOFBLOCK_FL doesn't get cleared correctly. # This is bad since it forces e2fsck to complain about that inode. # If you have a large number of inodes that are written with fallocate FSTYP -- ext4 PLATFORM -- Linux/x86_64 intel-s3e36-01 2.6.32-71.el6.x86_64 MKFS_OPTIONS -- /dev/loop1 MOUNT_OPTIONS -- -o acl,user_xattr -o context=system_u:object_r:nfs_t:s0 /dev/loop1 /mnt/testarea/scratch 243 [failed, exit status 1] - output mismatch (see 243.out.bad) --- 243.out 2010-11-24 11:24:48.000000000 -0500 +++ 243.out.bad 2010-11-26 06:34:31.031175880 -0500 @@ -5,9 +5,3 @@ XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 40960/40960 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) -wrote 40960/40960 bytes at offset 0 -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) -wrote 4096/4096 bytes at offset 262144 -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) -wrote 4096/4096 bytes at offset 262144 -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) _check_generic_filesystem: filesystem on /dev/loop0 is inconsistent (see 243.full) Ran: 243 Failures: 243 Failed 1 of 1 tests === 243.full === Test 1: Fallocate 40960 bytes and write 4096 bytes (buffered io). EOFBLOCK_FL bit is set. Test 2: Fallocate 40960 bytes and write 4096 bytes (direct io). EOFBLOCK_FL bit is set. Test 3: Fallocate 40960 bytes and write 40960 bytes (buffered io). EOFBLOCK_FL bit is set. Error: Current bit state incorrect. _check_generic filesystem: filesystem on /dev/loop0 is inconsistent *** fsck.ext4 output *** fsck from util-linux-ng 2.17.2 e2fsck 1.41.12 (17-May-2010) Pass 1: Checking inodes, blocks, and sizes Inode 14 should not have EOFBLOCKS_FL set (size 40960, lblk 9) Clear? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/loop0: ********** WARNING: Filesystem still has errors ********** /dev/loop0: 14/327680 files (0.0% non-contiguous), 55932/1310720 blocks *** end fsck.ext4 output *** mount output *** /dev/mapper/vg_intels3e3601-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") /dev/sda1 on /boot type ext4 (rw) /dev/mapper/vg_intels3e3601-lv_home on /home type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /dev/loop1 on /mnt/testarea/scratch type ext4 (rw,acl,user_xattr,context="system_u:object_r:nfs_t:s0") *** end mount output === 243.out.bad === QA output created by 243 wrote 4096/4096 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 4096/4096 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) wrote 40960/40960 bytes at offset 0 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) /kernel/filesystems/xfs/xfstests/243 result: FAIL metric: 0 Log: /tmp/tmp.LTqVrN DMesg: /tmp/dmesg.log Info: Searching AVC errors produced since 1290771263.84 (Fri Nov 26 06:34:23 2010) Info: No AVC messages found with /usr/bin/env LC_ALL=en_US.UTF-8 /sbin/ausearch -sv no -m AVC -m USER_AVC -m SELINUX_ERR -ts 11/26/2010 06:34:23 < /dev/null AvcLog: /tmp/tmp.IoPTfm
Likely solved by commit 58590b06d79f7ce5ab64ff3b6d537180fa50dc84 Author: Theodore Ts'o <tytso@mit.edu> Date: Wed Oct 27 21:23:12 2010 -0400 ext4: fix EOFBLOCKS_FL handling It turns out we have several problems with how EOFBLOCKS_FL is handled. First of all, there was a fencepost error where we were not clearing the EOFBLOCKS_FL when fill in the last uninitialized block, but rather when we allocate the next block _after_ the uninitalized block. Secondly we were not testing to see if we needed to clear the EOFBLOCKS_FL when writing to the file O_DIRECT or when were converting an uninitialized block (which is the most common case). Google-Bug-Id: 2928259 Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Yep we should get this in, even if it's a bit of a corner case.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Patch(es) available on kernel-2.6.32-112.el6
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0542.html