| Summary: | fsck.gfs2 stuck in pass1 on i686 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | RHEL Program Management <pm-rhel> |
| Component: | gfs2-utils | Assignee: | Robert Peterson <rpeterso> |
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 5.6 | CC: | adas, bmarzins, edamato, jkortus, mjuricek, pm-eus, rpeterso, swhiteho |
| Target Milestone: | rc | Keywords: | Regression, ZStream |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | gfs2-utils-0.1.62-28.el5_6.1 | Doc Type: | Bug Fix |
| Doc Text: |
On 32-bit x86 architectures, an attempt to check a large GFS2 file system caused the fsck.gfs2 utility to enter an infinite loop, utilizing 100% of available CPU resources. When run with the "-vv" option, the fsck.gfs2 command would produce output similar to the following:
(pass1.c:1453) Already processed system inode 33121 (0x8161)
This update applies an upstream patch that prevents such infinite loop, and large GFS2 file systems now successfully complete their file system check on both 32-bit and 64-bit architectures.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-02 08:12:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 667769 | ||
| Bug Blocks: | |||
|
Description
RHEL Program Management
2011-02-08 08:44:03 UTC
The same patch applies to the RHEL56 tree. I pushed it to the cluster.git repo's RHEL56 branch for inclusion into 5.6.z. Changing status to POST until we do a 5.6.z build. I built this into a 5.6.z z-stream build of gfs2-utils. The build ID is 3097723. This is now fixed in this rpm: gfs2-utils-0.1.62-28.el5_6.1 Changing status to MODIFIED until it gets incorporated into an erratum.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
On 32-bit x86 architectures, an attempt to check a large GFS2 file system caused the fsck.gfs2 utility to enter an infinite loop, utilizing 100% of available CPU resources. When run with the "-vv" option, the fsck.gfs2 command would produce output similar to the following:
(pass1.c:1453) Already processed system inode 33121 (0x8161)
This update applies an upstream patch that prevents such infinite loop, and large GFS2 file systems now successfully complete their file system check on both 32-bit and 64-bit architectures.
fsck.gfs2 runs OK with package gfs2-utils-0.1.62-28.el5_6.1 [root@sgi-xe240-02 tmp]# uname -a Linux sgi-xe240-02.rhts.eng.bos.redhat.com 2.6.18-238.el5PAE #1 SMP Sun Dec 19 14:42:44 EST 2010 i686 i686 i386 GNU/Linux [root@sgi-xe240-02 tmp]# rpm -qa | grep gfs2 gfs2-utils-0.1.62-28.el5_6.1 [root@sgi-xe240-02 tmp]# mkfs.gfs2 -p lock_nolock /dev/loop0 This will destroy any data on /dev/loop0. It appears to contain a gfs2 filesystem. Are you sure you want to proceed? [y/n] y Device: /dev/loop0 Blocksize: 4096 Device Size 500.00 GB (131072000 blocks) Filesystem Size: 500.00 GB (131071998 blocks) Journals: 1 Resource Groups: 2000 Locking Protocol: "lock_nolock" Lock Table: "" UUID: F447B6C2-1A18-505D-ACD6-C9F22329F77F [root@sgi-xe240-02 tmp]# fsck.gfs2 /dev/loop0 Initializing fsck Validating Resource Group index. Level 1 RG check. (level 1 passed) Starting pass1 Pass1 complete Starting pass1b Pass1b complete Starting pass1c Pass1c complete Starting pass2 Pass2 complete Starting pass3 Pass3 complete Starting pass4 Pass4 complete Starting pass5 Pass5 complete gfs2_fsck complete [root@sgi-xe240-02 tmp]# An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0476.html |