Bug 28845 - formatting filesystems takes a long time
Summary: formatting filesystems takes a long time
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-22 13:42 UTC by Chris Runge
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-08 17:56:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Chris Runge 2001-02-22 13:42:56 UTC
Wolverine (RC1)

NFS install on a dual processor/1GHz/512MB/18GB Ultra 160 SCSI system. I
select Disk Druid and create my partitions. I say that I want all
partitions formatted, but not to check the disk during formatting.
Formatting the partitions takes a long time. Whereas before it would format
all partitions in a couple of seconds it now takes several minutes. The
progress meter appears to "hang" for each partition. Switching over to a
console shows that it appears to "hang" when writing inode tables.

I've tested this twice now and ran into the problem both times.

FWIW, I've had no problems installing previous 7.1 betas or 7.0 on this
same machine. I also don't remember this problem when I installed Wolverine
on a laptop with an IDE disk.

Marking as high since the delay is significant enough that I thought the
installer had hung.

Comment 1 Michael Fulbright 2001-02-22 17:15:52 UTC
Please summarize your hardware.

Comment 2 Doug Ledford 2001-02-22 20:21:45 UTC
This is an already resolved issue.  There was a patch missing from the RC1
kernel that caused the aic7xxx module to get built with incorrect tagged queue
depth settings.  The delay you are seeing is the driver sending out and
immediately getting back thousands of commands per second with a status of
QUEUE_FULL on each command.  This continues until the driver is able to reduce
the queue depth to a reasonable value and then things perform as normal.  As a
workaround in the meantime, you can boot the system in expert mode, then when
you select the aic7xxx driver from the list of SCSI drivers, specify that you
want to pass it some options.  Then, pass it an option similar to the following:


and things should work.  If you have more than one aic7xxx controller, or any
drives at an ID higher than 7, then you will need to modify that tag_info string
appropriately.  Instructions for how to do that can be found on my web page at
http://people.redhat.com/dledford under the README for the aic7xxx driver.

Comment 3 Chris Runge 2001-03-04 16:17:34 UTC
I've reopened this as it is still a problem with RC2, although it does appear to
be a little better.

This is with an on-board Adaptec aic7899 chipset and a Seagate Cheetah 10K
(16GB) drive.

Comment 4 Michael K. Johnson 2001-03-13 03:49:19 UTC
There is another patch (generic SCSI layer) in 2.4.2-0.1.20 that fixes
this problem.  Feel free to reopen if that kernel or later (check
rawhide) does not solve the problem.

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