Bug 471925

Summary: Complete scan of filesystems expanded online
Product: [Fedora] Fedora Reporter: Naresh Sukhija <nareshsukhija>
Component: e2fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: esandeen, jochen, kzak, oliver, rhbugs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.41.4-5.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-09 04:22:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Simple test case shell script none

Description Naresh Sukhija 2008-11-17 17:59:56 UTC
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 18:05:34 UTC
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?)

Thanks,
-Eric

Comment 2 Naresh Sukhija 2008-11-18 07:56:19 UTC
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 09:52:28 UTC
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 14:14:38 UTC
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 05:06:51 UTC
I've sent a trivial pach upstream for this:

http://marc.info/?l=linux-ext4&m=122736617511248&w=2

Comment 6 Naresh Sukhija 2008-11-23 19:38:47 UTC
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

Regards,

Naresh

Comment 7 Eric Sandeen 2008-11-23 20:44:47 UTC
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.

-Eric

Comment 8 Bug Zapper 2008-11-26 05:31:19 UTC
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Eric Sandeen 2008-12-02 20:18:30 UTC
*** Bug 457964 has been marked as a duplicate of this bug. ***

Comment 10 Eric Sandeen 2009-03-26 16:08:51 UTC
Hm, sent upstream but ignored.  I'll reping and get this taken care of.

Comment 11 Eric Sandeen 2009-04-11 13:23:09 UTC
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.

-Eric

Comment 12 Fedora Update System 2009-04-11 13:41:22 UTC
e2fsprogs-1.41.4-5.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/e2fsprogs-1.41.4-5.fc10

Comment 13 Fedora Update System 2009-04-13 19:35:44 UTC
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 04:22:04 UTC
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.