Bug 28768 - Parallel fsck fails to parallelize properly.
Summary: Parallel fsck fails to parallelize properly.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: e2fsprogs
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Florian La Roche
QA Contact: Aaron Brown
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-22 04:12 UTC by Ed McKenzie
Modified: 2007-04-18 16:31 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-04-24 06:07:23 UTC
Embargoed:


Attachments (Terms of Use)

Description Ed McKenzie 2001-02-22 04:12:34 UTC
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 12:22:09 UTC
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
maintainers.

Comment 2 Ed McKenzie 2001-03-07 08:11:17 UTC
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 08:23:20 UTC
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 08:33:22 UTC
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 08:44:00 UTC
This should be fixed with e2fsprogs-1.19-2. Thanks for the bug-report.


Comment 6 Ed McKenzie 2001-04-09 22:26:26 UTC
This is still broken in 1.19-3. I'm investigating.

Comment 7 j. alan eldridge 2001-04-15 20:03:08 UTC
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 20:04:25 UTC
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-16 01:31:16 UTC
See bug 35980 for a major fix to problems with LABEL/UUID.

Comment 10 Ed McKenzie 2001-04-24 06:07:18 UTC
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 16:25:46 UTC
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.