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:
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
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
Created attachment 324402 [details] Simple test case shell script I can confirm this with e2fsprogs-1.41.3-2.fc9.i386.
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.
I've sent a trivial pach upstream for this: http://marc.info/?l=linux-ext4&m=122736617511248&w=2
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
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
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
*** Bug 457964 has been marked as a duplicate of this bug. ***
Hm, sent upstream but ignored. I'll reping and get this taken care of.
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
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
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
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.