Description of problem: e2fsck takes unreasonable long when checking filesystems. It takes many times more than checking a similar filesystem on RHEL 2.1 or RHEL4. This has not always been the case, but was introduced by some update release. I think it was U3. Version-Release number of selected component (if applicable): RHEL3 U7 fully patched. How reproducible: Install RHEL3 U0 and run fsck on a big filesystem, measure time. Update to U7, fsck again and measure time. Steps to Reproduce: 1. 2. 3. Actual results: e2fsck is slower with the newer releases. Expected results: e2fsck should perform identically. Additional info: This is going on my nerves for some time now and I am just waiting for an fsck run to finish, so I file a bug. I believe I first noticed it when I applied U3 to our servers and suddenly had to wait an hour instead of 5 minutes. I see this effect on all my 10+ RHEL3 systems. RHEL2.1 and RHEL4 is notably faster.
Sorry for the long time w/ no response on this bug. Can you say whether this is still a problem in RHEL3? I think RHEL3 is getting close to a maintenance mode where non-critical (not security, corruption, etc) bugs will have a hard time getting updates, I'm afraid. how much slower is it, do you have any timing info? Thanks, -Eric
Hi Eric, > how much slower is it, do you have any timing info? It feels like 5 times and it is still in there. However, I do not have ressources to investigate at the moment to give you exact figures and as the usage of RHEL3 is on the decline anyways, we may just leave the bug open and rest in peace. regards, Gunther
Gunther, thanks. I can certainly do some testing here too. If it persists to RHEL5, it's well worth making sure I/we know exactly why it's slower - even if we don't fix it in RHEL3. Maybe it was a fix for some missed case, or maybe it was simply a mistake that slowed things down. I'll try to get to the bottom of it. Thanks, -Eric
I have to clarify my statement. I have never observed the problem with RHEL4 ( and I have no experience with fsck on RHEL 5 yet). regards, Gunther
Note to myself: e2fsprogs versions for RHEL3: GOLD: e2fsprogs-1.32-15 U1: e2fsprogs-1.32-15 U2: e2fsprogs-1.32-15 U3: e2fsprogs-1.32-15 U4: e2fsprogs-1.32-15.1 U5: e2fsprogs-1.32-15.1 U6: e2fsprogs-1.32-15.1 U7: e2fsprogs-1.32-15.1 U8: e2fsprogs-1.32-15.3 U9: e2fsprogs-1.32-15.3 The only change I see in the changelog is: +* Mon Apr 24 2006 Thomas Woerner <twoerner> - 1.32-15.3 + +- added support for 32M directory limit in e2fsck (#162576) +- fixed offline filesystem resizing issue (#144486) + +* Tue Apr 18 2006 Karel Zak <kzak> - 1.32-15.2 + +- fix unexpected fsck error message (#185534) + +* Mon Oct 04 2004 Thomas Woerner <twoerner> - 1.32-15.1 + +- rebuilt for multilib + but I'll pull the trees & look. I just want to make sure there's not some regression that persists until today....
Hm, literally the only difference between GOLD & U7 was a rebuild to support multilib. There were *no* code changes to e2fsprogs. Perhaps this was a kernel performance regression.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.