Bug 885073

Description of problem:

This bug has been opened to backport the following patches to RHEL5 e2fsprogs from upstream e2fsprogs 1.42.4, as discussed in the bugzilla 'https://bugzilla.redhat.com/show_bug.cgi?id=850803' comment 16.

a ) commit 63b3913dbc0bc7cdf8a63f3bdb0c8d7d605e9a40
Author: Theodore Ts'o <tytso>
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>
    Signed-off-by: "Theodore Ts'o" <tytso>



b ) commit 6d75685e2b76f4099589ad33732cf59f279b5d65
Author: Theodore Ts'o <tytso>
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>