Bug 28768 - Parallel fsck fails to parallelize properly.
Parallel fsck fails to parallelize properly.
Product: Red Hat Linux
Classification: Retired
Component: e2fsprogs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Florian La Roche
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-02-21 23:12 EST by Ed McKenzie
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-24 02:07:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ed McKenzie 2001-02-21 23:12:34 EST
fsck checks my /boot and /home partitions simultaneously, causing lots of
disk thrashing and taking longer than it would otherwise. Both have fsck
priority 2 in fstab, which is what anaconda assigned at install time.
Comment 1 Karsten Hopp 2001-02-22 07:22:09 EST
Parallel checks should only be done on different disks, but never on partitions
of the same disk. I think that this should be assigned to the anaconda
Comment 2 Ed McKenzie 2001-03-07 03:11:17 EST
Fresh install of Wolverine does the same thing. /, /boot, and /home are all on
/dev/hde, and while / has priority 1, /boot and /home have priority 2 in fstab.
After an unclean shutdown, e2fsck thrashes the disk checking /boot and /home at
the same time. Not a _big_ problem for me (boot is small), but when I had things
partitioned as /usr and /home, this was a major issue. :-/
Comment 3 Ed McKenzie 2001-03-07 03:23:20 EST
After RTFM, it seems that anaconda is indeed correct in assigning passno=2 to
all non-root filesystems, and e2fsck is responsible for parallelizing properly.
IIRC parallelized fsck worked properly in RH6.2, and my uninformed guess would
be that mount-by-label might be the causative factor. Testing this hypothesis
now ... meanwhile, reassigning to e2fsprogs.
Comment 4 Ed McKenzie 2001-03-07 03:33:22 EST
fsck does parallelize properly with explicit device names in fstab. Using LABEL=
notation in fstab seems to break fsck's drive ordering.
Comment 5 Florian La Roche 2001-03-07 03:44:00 EST
This should be fixed with e2fsprogs-1.19-2. Thanks for the bug-report.
Comment 6 Ed McKenzie 2001-04-09 18:26:26 EDT
This is still broken in 1.19-3. I'm investigating.
Comment 7 j. alan eldridge 2001-04-15 16:03:08 EDT
I somehow suspect that this has the same root cause as getting a "Couldn't find
filesystem: LABEL=/somelabel" error on fsck at startup.

Although that is *really* weird because it ONLY happens when fsck is run by
initlog. It does NOT happen when fsck is run directly from rc.sysinit. Jeeeezuz.
WTF could be happening there? And it ONLY happens on system startup. Great. ONLY
on system startup, from rc.sysinit, ONLY when initlog is the parent of fsck.
Aaaauuuugggghhhhh! Debug that, Batman! 
Comment 8 j. alan eldridge 2001-04-15 16:04:25 EDT
Oh... I'm running Wolverine with Rawhides e2fsprogs (1.19-3). So I've got the
latest and greatest here. Bleah.
Comment 9 j. alan eldridge 2001-04-15 21:31:16 EDT
See bug 35980 for a major fix to problems with LABEL/UUID.
Comment 10 Ed McKenzie 2001-04-24 02:07:18 EDT
This does appear to be working in 7.1-release. I'll do some further checking to
make sure this is the case.
Comment 11 Florian La Roche 2001-05-15 12:25:46 EDT
Ok, closing bug. e2fsprogs-1.20 will have even better code to detect partitions
on the same disk.

Thanks for the bug-report,

Florian La Roche

Note You need to log in before you can comment on or make changes to this bug.