Bug 471925 - Complete scan of filesystems expanded online
Complete scan of filesystems expanded online
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
: 457964 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-11-17 12:59 EST by Naresh Sukhija
Modified: 2009-05-09 00:22 EDT (History)
5 users (show)

See Also:
Fixed In Version: 1.41.4-5.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-09 00:22:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Simple test case shell script (255 bytes, text/plain)
2008-11-22 04:52 EST, Hans Ulrich Niedermann
no flags Details

  None (edit)
Description Naresh Sukhija 2008-11-17 12:59:56 EST
Description of problem:
After filesystem expanding, the e2fsck scans complete filesystem at next boot

Version-Release number of selected component (if applicable):
Fedora 10 Preview x86_64

How reproducible:
Expand a filesystem using lvextend and resize2fs and reboot

Steps to Reproduce:
1. Expand a filesystem using lvextend and resize2fs commands
2. Reboot or Unmount and run "e2fsck <filesystem_device>

Actual results:
The complete filesystem is scanned:

[root@f10 ~]# e2fsck /dev/rootvg/exportlv
e2fsck 1.41.3 (12-Oct-2008)
/dev/rootvg/exportlv primary superblock features different from backup, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/rootvg/exportlv: ***** FILE SYSTEM WAS MODIFIED *****
/dev/rootvg/exportlv: 35887/8683520 files (2.0% non-contiguous), 32996602/34717696 blocks
[root@f10 ~]#

Expected results:

[root@f10 ~]# e2fsck /dev/rootvg/exportlv
e2fsck 1.41.3 (12-Oct-2008)
/dev/rootvg/exportlv: clean, 35887/8683520 files, 32996602/34717696 blocks
[root@f10 ~]#

Additional info:
Comment 1 Eric Sandeen 2008-11-17 13:05:34 EST
That extra flag checking has been a bit of a pain.  We'll need to see which flags differ, and caused the full check.  (I assume that /dev/rootvg/exportlv is the device that you expanded, right?  If it is the root fs, how did you do this, from a rescue cd, or with a readonly root, or?)

Comment 2 Naresh Sukhija 2008-11-18 02:56:19 EST
Yes, /dev/rootvg/exportlv is the device I expanded

No, it's not the root device

I used lvextend and resize2fs commands, I expanded it only by 200MB
Comment 3 Hans Ulrich Niedermann 2008-11-22 04:52:28 EST
Created attachment 324402 [details]
Simple test case shell script

I can confirm this with e2fsprogs-1.41.3-2.fc9.i386.
Comment 4 Eric Sandeen 2008-11-22 09:14:38 EST
Thanks, for anyone playing along at home, this works w/o lvm too:

dd if=/dev/zero of=fsfile bs=1M count=500
mkfs.ext3 -F fsfile -b 4096 64000
mkdir -p test
mount -o loop fsfile  test/
resize2fs /dev/loop0
umount test
e2fsck fsfile 

It seems to be the needs_recovery flag that differs:

e2fsck 1.41.3 (12-Oct-2008)
Primary    Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Backup   1 Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
fsfile primary superblock features different from backup, check forced.

IIRC the current superblock gets copied out to the others during online resize,  and since it's mounted, needs_recovery is set.  I thought we skipped this one in the comparisons, and we probably should... 

I'll think about the right way to fix this, thanks.
Comment 5 Eric Sandeen 2008-11-23 00:06:51 EST
I've sent a trivial pach upstream for this:

Comment 6 Naresh Sukhija 2008-11-23 14:38:47 EST
Hi Eric,
I tested the patch on e2fsprogs-1.41.3. It works fine.

Is it possible to promote this patch at the earlies, so that upcoming Fedora 10 is not affected


Comment 7 Eric Sandeen 2008-11-23 15:44:47 EST
I'm 99% certain that upstream will take the patch as-is, but I'd like to give it a day or two to be sure that happens before I commit it to F10.

F10 is already cooked, so the e2fsprogs there is what it is for the GA, but yes, this can certainly be a very early update.

Comment 8 Bug Zapper 2008-11-26 00:31:19 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 9 Eric Sandeen 2008-12-02 15:18:30 EST
*** Bug 457964 has been marked as a duplicate of this bug. ***
Comment 10 Eric Sandeen 2009-03-26 12:08:51 EDT
Hm, sent upstream but ignored.  I'll reping and get this taken care of.
Comment 11 Eric Sandeen 2009-04-11 09:23:09 EDT
Ted says it's applied to the maint branch but I still don't see it.  I'll get this in for F11 anyway though, can't wait forever.  Sorry this one took a while.

Comment 12 Fedora Update System 2009-04-11 09:41:22 EDT
e2fsprogs-1.41.4-5.fc10 has been submitted as an update for Fedora 10.
Comment 13 Fedora Update System 2009-04-13 15:35:44 EDT
e2fsprogs-1.41.4-5.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update e2fsprogs'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3533
Comment 14 Fedora Update System 2009-05-09 00:22:04 EDT
e2fsprogs-1.41.4-5.fc10 has been pushed to the Fedora 10 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.