I have the contents of /var/crash/127.0.0.1-2013-12-10-11:19:48 and /var/crash/127.0.0.1-2013-12-10-14:09:01 if you give me somewhere to upload them.  They are around 80 megabytes each (looks like I can't attach anything bigger than 20 megs to this bug).

whoops ignore Comment 1, meant to add that to this bug report (same filesystem, different bug): https://bugzilla.redhat.com/show_bug.cgi?id=1040136

It's not clear that this should behave as you wish.

On the one hand, the generic explanation:  "Force the tune2fs operation to complete even in the face of errors" does sound that way.

But then it goes on to list examples about missing external journals, but doesn't make specific mention of missing but *dirty* journals, which is a bit of a different situation than maybe was originally intended.

Still, it seems like it would make sense to allow this - maybe with two "forces" for good measure or something, I'll discuss it upstream.

(In the meantime, I think Ted suggested a workaround in that debian bug?)

Yes, I do have a workaround.  Thanks for discussing upstream.  Even if it is decided that it will not remove dirty journals, the tune2fs man page should be updated to reflect that.

I'll send a patch upstream which will remove it with "-ff" :


[root@sandeen e2fsprogs]# misc/tune2fs -f -O ^has_journal fsfile.img
tune2fs 1.43-WIP (28-Dec-2013)
The needs_recovery flag is set.  Please run e2fsck before clearing
the has_journal flag.

[root@sandeen e2fsprogs]# misc/tune2fs -ff -O ^has_journal fsfile.img
tune2fs 1.43-WIP (28-Dec-2013)

[root@sandeen e2fsprogs]# dumpe2fs -h fsfile.img  | grep -i featu
dumpe2fs 1.41.12 (17-May-2010)
Filesystem features:      ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize

commit 5fe2bd60844cfe5d805e62a4316afaa5cd9d7c83
Author: Eric Sandeen <sandeen>
Date:   Thu Feb 20 20:18:41 2014 -0500

    tune2fs: allow removal of dirty journal with two "-f" options
    
    Jim pointed out that "tune2fs -f -O ^has_journal" won't remove the
    journal if the needs_recovery flag is set; the manpage seems to indicate
    that it should.  And if you've lost an external journal and can no longer
    replay it, how should one proceed?
    
    Change tune2fs so that two "-f" options will allow removal of a dirty
    journal from a filesystem, even if the filesystem needs recovery.
    
    e2fsck can then do its best to pick up the pieces.
    
    Addresses-Debian-Bug: #559301
    
    Reported-by: Jim Faulkner <james.faulkner>
    Signed-off-by: Eric Sandeen <sandeen>
    Signed-off-by: "Theodore Ts'o" <tytso>

Built in e2fsprogs-1.41.12-19.el6

This problem is trigered under such condition:
1. ext3/ext4 file system with external journal device;
2. external journal device is lost;
3. the file system must get the "has_journal" and "needs_recovery" flag.

I use the way of "freeze->thaw" the sepecified file system to add the "needs_recovery" flag to the distro system, and then do the reproduction and verification.

With the e2fsprogs-1.41.4-el10, e2fsprogs-1.41.12-el14, e2fsprogs-1.41.12-el19, the problem is reproduced, shows as below:
:: [  BEGIN   ] :: Running 'tune2fs -f -O ^has_journal /tmp/18054data.bk.img 2>&1 | grep has_journal 1>/dev/null 2>&1'
:: [   PASS   ] :: Command 'tune2fs -f -O ^has_journal /tmp/18054data.bk.img 2>&1 | grep has_journal 1>/dev/null 2>&1' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'e2fsck /tmp/18054data.bk.img'
e2fsck 1.41.12 (17-May-2010)
e2fsck: need terminal for interactive repairs
:: [   PASS   ] :: Command 'e2fsck /tmp/18054data.bk.img' (Expected 2-12, got 8)
:: [  BEGIN   ] :: Running 'tune2fs -l /tmp/18054data.bk.img | grep has_journal 1>/dev/null 2>&1'

With the e2fsprogs-1.41.12-el20, with the "-ff" option, the problem is fixed. The result is shown as below:
: [  BEGIN   ] :: Running 'tune2fs -f -O ^has_journal /tmp/21158data.bk.img 2>&1 | grep has_journal 1>/dev/null 2>&1'
:: [   PASS   ] :: Command 'tune2fs -f -O ^has_journal /tmp/21158data.bk.img 2>&1 | grep has_journal 1>/dev/null 2>&1' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'e2fsck /tmp/21158data.bk.img'
e2fsck 1.41.12 (17-May-2010)
e2fsck: need terminal for interactive repairs
:: [   FAIL   ] :: Command 'e2fsck /tmp/21158data.bk.img' (Expected 12, got 8)
:: [  BEGIN   ] :: Running 'tune2fs -l /tmp/21158data.bk.img | grep has_journal 1>/dev/null 2>&1'
:: [   PASS   ] :: Command 'tune2fs -l /tmp/21158data.bk.img | grep has_journal 1>/dev/null 2>&1' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'tune2fs -ff -O ^has_journal /tmp/21158data.bk.img'
tune2fs: Invalid argument while trying to open external journal
tune2fs 1.41.12 (17-May-2010)
Journal removed
:: [   PASS   ] :: Command 'tune2fs -ff -O ^has_journal /tmp/21158data.bk.img' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'tune2fs -l /tmp/21158data.bk.img | grep has_journal 1>/dev/null 2>&1'
:: [   PASS   ] :: Command 'tune2fs -l /tmp/21158data.bk.img | grep has_journal 1>/dev/null 2>&1' (Expected 1, got 1)
:: [ 14:26:12 ] :: [ INFO    ] :: Verify the bug 1040122 successfully

More info please check the beaker job:
https://beaker.engineering.redhat.com/jobs/727330.

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-2014-1566.html