Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1250717 - ext4 sets NEEDS_RECOVERY when unfreezing a journal-less filesystem (ext2); blkid gets confused
Summary: ext4 sets NEEDS_RECOVERY when unfreezing a journal-less filesystem (ext2); bl...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 22
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-05 20:01 UTC by Stu Mark
Modified: 2016-06-28 16:03 UTC (History)
12 users (show)

Fixed In Version: 4.1.6-201.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-15 15:36:08 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1350895 1 None None None 2021-01-20 06:05:38 UTC

Description Stu Mark 2015-08-05 20:01:35 UTC 
Description of problem:

This problem exists in fedora 20, 21 and 22 but not CentOS 7

If you have an ext2 volume and it uses the ext4 driver (by having lvm or some ext4 volumes as well), if you fsfreeze then unfreeze the ext2 partition, the UUID dissappears from blkid for that ext2 volume.

blkid -p on the specific volume yields nothing.

To fix it, before you reboot, if you umount and mount the partition again, it will fix the UUID and the machine will boot ok.

We also found that if you only have ext2 volumes you will get a 'not supported' error if you try to fsfreeze the ext2 volume, so we're thinking it's the ext4 driver that, when used to fsfreeze ext2, causes the problem.

When you run fsfreeze the UUID is still there, it's when you fsfreeze --unfreeze that the problem happens.
After you unfreeze, blkid will not show the UUID, but lsblk -f will.
If you then refreeze the volume, the UUID will reappear in blkid while it's frozen, but disappear again when you unfreeze.

Version-Release number of selected component (if applicable):
We saw this in util-linux 2.24 and 2.25

How reproducible:
Consistently.

Steps to Reproduce:
1. install fedora core 20, 21 or 22
2. create an lvm or some ext4 volumes on the same disk
3. create a /boot volume with ext2
4. blkid (note the UUID)
5. fsfreeze --freeze /boot
6. fsfreeze --unfreeze /boot
7. blkid (note the lack of UUID)

Actual results:
No UUID for the ext2 volume

Expected results:
UUID should still exist for ext2 volume.

Additional info:
If you make ext2 volumes on one disk, and ext4 volumes on another disk, the problem will not happen. It seems to happen if there are ext2 and ext4 volumes mixed on the same block device, definitely happens if there's an lvm on the same disk.

This was all tested on virtual machines (virtualbox) with fedora 20, 21 and 22 for different tests. The behavior was the same.
Comment 1 Eric Sandeen 2015-08-05 20:17:06 UTC 
Ok, that's pretty weird.  (I can see it here, too).  Not sure what's up yet.
Comment 2 Eric Sandeen 2015-08-05 20:34:10 UTC 
the needs_recovery feature is set when the fs is unfrozen (which is an odd thing to set on a filesystem w/o a journal)

It's not set on the original mount, but is set after the filesystem is frozen & unfrozen.  This probably confuses blkid's probing.

Yup, derp:

static int ext4_unfreeze(struct super_block *sb)
{
        if (sb->s_flags & MS_RDONLY)
                return 0;

        /* Reset the needs_recovery flag before the fs is unlocked. */
        EXT4_SET_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER);

it's setting it unconditionally.

This shouldn't be set if it doesn't have a journal, I'll see how that regressed, and send a patch upstream.

It looks like:

commit 9ca92389c5312a51e819c15c762f0abdc7f3129b
Author: Theodore Ts'o <tytso>
Date:   Fri May 1 12:52:25 2009 -0400

    ext4: Use separate super_operations structure for no_journal filesystems
    
    By using a separate super_operations structure for filesystems that
    have and don't have journals, we can simply ext4_write_super() ---
    which is only needed when no journal is present --- and ext4_freeze(),
    ext4_unfreeze(), and ext4_sync_fs(), which are only needed when the
    journal is present.
    
    Signed-off-by: "Theodore Ts'o" <tytso>


followed by:

commit f6e63f90809946d410c42045577cb159fedabf8c
Author: Theodore Ts'o <tytso>
Date:   Thu Sep 18 17:12:30 2014 -0400

    ext4: fold ext4_nojournal_sops into ext4_sops
    
    There's no longer any need to have a separate set of super_operations
    for nojournal mode.
    
    Signed-off-by: Theodore Ts'o <tytso>

messed this up.

-Eric
Comment 3 Eric Sandeen 2015-08-05 22:14:17 UTC 
I've sent a patch upstream for this.
Comment 4 Stu Mark 2015-08-06 13:09:45 UTC 
Thanks, you rock, this was driving us nuts. Much appreciated.
Comment 5 Josh Boyer 2015-08-06 15:03:09 UTC 
(In reply to Eric Sandeen from comment #3)
> I've sent a patch upstream for this.

Got a URL to the thread?
Comment 6 Eric Sandeen 2015-08-06 17:35:18 UTC 
http://www.spinics.net/lists/linux-ext4/msg48688.html
Comment 7 Josh Boyer 2015-08-06 17:44:22 UTC 
(In reply to Eric Sandeen from comment #6)
> http://www.spinics.net/lists/linux-ext4/msg48688.html

Should probably CC stable?  I'd reply on-list, but I'm not subscribed to the fs-specific lists.
Comment 8 Eric Sandeen 2015-08-06 18:10:28 UTC 
I suppose; it's kind of a corner case, but probably worth fixing up.
Comment 9 Neal Gompa 2015-08-11 11:40:07 UTC 
Has the fix been pushed to stable kernels yet?
Comment 10 Eric Sandeen 2015-08-11 16:22:41 UTC 
It's had no response on the ext4 list yet.  :(
Comment 11 Josh Boyer 2015-08-13 12:16:33 UTC 
(In reply to Eric Sandeen from comment #10)
> It's had no response on the ext4 list yet.  :(

Right.  Not that I don't trust Eric entirely, but I at least wanted to see if upstream had a comment before backporting.
Comment 12 Neal Gompa 2015-08-13 14:45:23 UTC 
Would it be possible to introduce this fix into the Fedora kernels while we wait for it to be upstreamed?
Comment 13 Neal Gompa 2015-08-13 14:47:15 UTC 
Oops, it has been reviewed and declared good[0]. So backporting should be okay too.

[0]: http://www.spinics.net/lists/linux-ext4/msg48740.html
Comment 14 Josh Boyer 2015-08-20 17:58:04 UTC 
Added in Fedora git.
Comment 15 Fedora Update System 2015-08-24 21:56:20 UTC 
kernel-4.2.0-0.rc8.git0.1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14151
Comment 16 Fedora Update System 2015-08-27 17:57:27 UTC 
kernel-4.2.0-0.rc8.git0.1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 17 Fedora Update System 2015-09-05 01:03:01 UTC 
kernel-4.1.6-201.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130
Comment 18 Fedora Update System 2015-09-06 18:51:56 UTC 
kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15130
Comment 19 Fedora Update System 2015-09-11 17:21:32 UTC 
kernel-4.1.6-201.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2015-09-15 17:36:22 UTC 
kernel-4.1.7-100.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933
Comment 21 Fedora Update System 2015-09-17 01:02:50 UTC 
kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15933
Comment 22 Fedora Update System 2015-09-23 00:20:13 UTC 
kernel-4.1.7-100.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.