RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 657553 - [xfstests 243] ext4 incosistency with EOFBLOCK_FL
Summary: [xfstests 243] ext4 incosistency with EOFBLOCK_FL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.1
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: Boris Ranto
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-26 12:59 UTC by Boris Ranto
Modified: 2011-05-23 20:29 UTC (History)
2 users (show)

Fixed In Version: kernel-2.6.32-112.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-23 20:29:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0542 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 6.1 kernel security, bug fix and enhancement update 2011-05-19 11:58:07 UTC

Description Boris Ranto 2010-11-26 12:59:29 UTC
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

Comment 2 Eric Sandeen 2010-11-26 20:30:37 UTC
Likely solved by

commit 58590b06d79f7ce5ab64ff3b6d537180fa50dc84
Author: Theodore Ts'o <tytso>
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>

Comment 3 RHEL Program Management 2011-01-07 04:21:53 UTC
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.

Comment 5 Eric Sandeen 2011-01-07 15:35:27 UTC
Yep we should get this in, even if it's a bit of a corner case.

Comment 6 Suzanne Logcher 2011-01-07 16:08:06 UTC
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.

Comment 7 RHEL Program Management 2011-01-07 16:08:57 UTC
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.

Comment 9 Aristeu Rozanski 2011-02-03 19:05:49 UTC
Patch(es) available on kernel-2.6.32-112.el6

Comment 13 errata-xmlrpc 2011-05-23 20:29:51 UTC
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


Note You need to log in before you can comment on or make changes to this bug.