ide1 stalls while tar xvfz'ing

[Les Schaffer]

Greetings:

I installed a few months ago a new hard drive (Maxtor 4 Megish) on
ide1 as /dev/hdc, and have noticed something queer which last nite i
took the trouble to characterize clearly:

lets say i go 'tar xvfz large-many-file-archive.tar.gz' onto
/dev/hdc. you see the files start to spin out fast, then stop, then go
a little bit, then stop and wait, then go again. and the stop and wait
are not on large files, could be any size.

when i go and tar xvfz the same archive on /dev/hda it speeds right
through all the files.

so i figure something is up with /dev/hdc.

(gustav)~/: hdparm -I /dev/hdc

/dev/hdc:

Model=aMtxro9 40233D , FwRev=AW8S7293, SerialNo=3K40K7AJ
Config={ Fixed }
RawCHS=8374/16/63, TrkSize=0, SectSize=0, ECCbytes=29
BuffType=3(DualPortCache), BuffSize=256kB, MaxMultSect=16, MultSect=8
DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=2(fast)
CurCHS=8374/16/63, CurSects=8440992, LBA=yes, LBAsects=8440992
tDMA={min:120,rec:120}, DMA modes: mword0 mword1 *mword2
IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4

[memo to Mark Lord: hdparm is swapping characters in the Model name,
that should be Maxtor 94......]

originally i had MultiSect=0 and then set it to 8, but that didnt
help.

i am using irqtune to fix poor PPP download rates.

irqtune: trying command -- rmmod irqtune_mod
I00/P05: 377686 timer
I01/P06: 3596 keyboard
I02/P07: 0 cascade
I03/P00: 31164 + serial
I04/P01: 31127 + serial
I08/P09: 0 + rtc
I11/P12: 529 + aha152x
I13/P14: 1 math error
I14/P07: 42916 + ide0
I15/P08: 85861 + ide1

but i dont think explains anything, since ide0 is just one higher
priority than ide1 (and lower than the I03 serial, which carries PPP),
but ide0 has no problem with stall.

Any suggestions to fix this damn thing?

thanks much.

(gustav)~/: df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hdc1 1783483 502559 1262488 28% /
/dev/hda3 277136 160070 102753 61% /opt
/dev/hdc2 1585000 777714 725361 52% /usr/local
/dev/hdc3 654200 327048 293359 53% /home/godzilla
/dev/sda1 98191 84589 13577 86% /zip

--
____ Les Schaffer godz...@netmeg.net ___| --->> Engineering R&D <<---
Theoretical & Applied Mechanics | Designspring, Inc.
Center for Radiophysics & Space Research | Westport, CT USA
Cornell Univ. scha...@tam.cornell.edu | l...@designspring.com

[TS Stahl]

IDE only handles one device at a time. If you are reading/writing drive 1, then
requests to drive 2 have to wait. I t would seem that linux is doing its work on 1,
and then puttin the files out to 2. This is an overly simplistic explanation of
course, but I have similar problems on my ide systems. I have not seen this on SCSI
chains, so I believe the explanation quite plausible. HTH

Les Schaffer wrote:

--
Scott Stahl
MIS Asst.
Illinois Housing Development Authority
401 N. Michigan Ave. Ste. 900
Chicago, IL 60611

[Les Schaffer]

>>>>> "TS" == TS Stahl <tss...@hotmail.com> writes:

TS> IDE only handles one device at a time. If you are
TS> reading/writing drive 1, then requests to drive 2 have to
TS> wait. I t would seem that linux is doing its work on 1, and
TS> then puttin the files out to 2. This is an overly simplistic
TS> explanation of course, but I have similar problems on my ide
TS> systems. I have not seen this on SCSI chains, so I believe
TS> the explanation quite plausible. HTH

sounds almost plausible, but consider this:

1.) i never USED TO have this problem. its just something i noticed in
the last few months, but it didnt start to bother me till last week or
two, when i further characterized the problem. in this time, i have
moved up through 2.0.33 --> 2.0.35, so i wondered if it could be
kernel/fs related.

2.) i am talking STALL here. consider this: i time a tar -xvf
large-tar-package.tar to the drive. then i untarred the archive
elsewhere and did a cp -Rpd un-tarred-dir-tree to the same place as
former test (after having wiped out the dir tree structure with a rm
-rf first)

guess what? 'time tar xvf ... ' gave me like 3m40s while 'time cp -Rpd
...' gave me like 0m20s.

i call that a STALL!! and when you watch top with refresh set to 1
sec. you see the tar process go down to the bottom of the active
pile very often. and the light on the drive is OFF during those
times.

something aint right here in denmark.

les schaffer

[Orlando Andico]

TS Stahl wrote:
>
> IDE only handles one device at a time. If you are reading/writing drive 1, then
> requests to drive 2 have to wait. I t would seem that linux is doing its work on 1,
> and then puttin the files out to 2. This is an overly simplistic explanation of
> course, but I have similar problems on my ide systems. I have not seen this on SCSI
> chains, so I believe the explanation quite plausible.

Depends on the chipset. IDE can't parallelize I/O on
the same controller, but from the previous poster's
info, he had the other drive on the secondary IDE
controller. Some PCI chipsets (VIA Apollo VP1 and above, SiS chipsets,
e.g. non-Intel ones) have either
a "split FIFO" or "dual FIFO" which allows I/O on both
the primary and secondary controller at the same time.

Only the Intel chipsets can't do I/O on both the
primary and secondary simultaneously (well, some SiS
can't either but most can).

--

Cheers,
Orly