Bug 885083 - Backport commit '63b3913dbc0bc7cdf8a63f3bdb0c8d7d605e9a40' and '6d75685e2b76f4099589ad33732cf59f279b5d65' from upstream e2fsprogs to RHEL6 e2fsprogs
Backport commit '63b3913dbc0bc7cdf8a63f3bdb0c8d7d605e9a40' and '6d75685e2b76f...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
6.5
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Eric Sandeen
Eryu Guan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-07 08:23 EST by Vimal Kumar
Modified: 2013-11-21 17:43 EST (History)
4 users (show)

See Also:
Fixed In Version: e2fsprogs-1.41.12-15.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 17:43:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vimal Kumar 2012-12-07 08:23:17 EST
Description of problem:

This bug has been opened to backport the following patches to RHEL6 e2fsprogs from e2fsprogs 1.42.4. This was discussed in the bugzilla 'https://bugzilla.redhat.com/show_bug.cgi?id=850803' comment 16 to be backported to RHEL5. As per the customer, they would like to see this backported to RHEL6 as well. 

a ) commit 63b3913dbc0bc7cdf8a63f3bdb0c8d7d605e9a40
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Jun 10 23:35:43 2012 -0400

    e2fsck: correctly propagate error from journal to superblock
    
    If the file system is mounted read-only after a file system error has
    been detected, the fact that an error occurred is written to the
    journal.  This is important because while the journal is getting
    replayed, the error indication in the superblock may very well get
    overwritten.
    
    Unfortunately, the code to propagate the error indication from the
    journal to superblock was broken because this was being done before
    the old file system handle is thrown away and the file system is
    re-opened to ensure that no stale data is in the file system handle.
    As a result, the error indication in the superblock was never written
    out.
    
    To fix this, we need to move the check if the journal's error
    indicator has been set after the file system has been freed and
    re-open.
    
    Reported-by: Ken Sumrall <ksumrall@google.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>



b ) commit 6d75685e2b76f4099589ad33732cf59f279b5d65
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu May 31 19:19:02 2012 -0400

    e2fsck: handle an already recovered journal with a non-zero s_error field
    
    If a file system was remounted read-only after a file system
    corruption is detected, and then that file system is mounted and
    unmounted by the kernel, the journal would have been recovered, but
    the kernel currently leaves the s_errno field still set.  This is
    arguably a bug, since it has already propgated the non-zero s_errno
    field to the file system superblock, where it will be retained until
    e2fsck has been run.
    
    However, e2fsck should handle this case for existing kernel by
    checking the journal superblock's s_errno field even if journal
    recovery is not required.
    
    Without this commit, e2fsck would not notice anything wrong with the
    file system, but a subsequent mount of the file system by the kernel
    would mark the file system's superblock as needing checking (since the
    journal's s_errno field would still be set), resulting an full e2fsck
    run at the next reboot, which would find nothing wrong --- and then
    when the file system was mounted, the whole cycle would repeat again.
    
    I had seen reports of this in the past, but it wasn't until recently
    that I realized exactly how this had come about, since normally e2fsck
    would be run automatically before the file system is mounted again,
    thus avoiding this problem.  However, a user using a rescue CD who
    didn't run e2fsck before mounting the a file system in this condition
    could trigger this situation, and unfortunately, with previous
    versions of e2fsprogs and the kernel, there would be no way out no
    matter what the user tried to do.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Comment 2 RHEL Product and Program Management 2012-12-14 03:36:08 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 11 Eryu Guan 2013-09-10 01:30:29 EDT
According to bug 850803 comment 23, with these two patches, e2fsck -p should report corrupted orphan inode list and force a manual fsck.

Test image is from bug 850803

Reproduced with e2fsprogs-1.41.12-14.el6, e2fsck -p reports clean

[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# rpm -q e2fsprogs
e2fsprogs-1.41.12-14.el6.x86_64
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# cp 10-sda3.image test.img
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# losetup /dev/loop0 test.img
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# e2fsck -p /dev/loop0
/: recovering journal
/: Clearing orphaned inode 2243137 (uid=27, gid=27, mode=0100600, size=0)
/: Clearing orphaned inode 2242888 (uid=27, gid=27, mode=0100600, size=0)
/: Clearing orphaned inode 2242810 (uid=27, gid=27, mode=0100600, size=0)
/: Clearing orphaned inode 2242806 (uid=27, gid=27, mode=0100600, size=0)
/: Clearing orphaned inode 2242805 (uid=27, gid=27, mode=0100600, size=0)
/: clean, 562706/4404224 files, 3872808/4429056 blocks
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]#

Verified with e2fsprogs-1.41.12-18.el6, e2fsck find the corrupted orphan inode list.

[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# rpm -q e2fsprogs
e2fsprogs-1.41.12-18.el6.x86_64
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# cp 10-sda3.image test.img
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# losetup `losetup -f` test.img 
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# losetup -a
/dev/loop0: [fd00]:540787 (/root/bz885083-e2fsprogs-backport-commits/test.img)
[root@hp-dl388g8-03 bz885083-e2fsprogs-backport-commits]# e2fsck -p /dev/loop0
/: recovering journal
/ contains a file system with errors, check forced.
/: Deleted inode 2242805 has zero dtime.  FIXED.
/: Inodes that were part of a corrupted orphan linked list found.  

/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

Set to VERIFIED
Comment 12 errata-xmlrpc 2013-11-21 17:43:10 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1689.html

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