I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
Barracuda drives.
The performance under 2.6 kernels is *very* poor (Timing buffered disk
reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
buffered disk reads around 60 MB/sec).
Below three hdparm reads on three different liveCDs (kernels 2.6.11.6,
2.4.28, 2.6.11).
Kernel 2.6.11.6, Slax 5.0.1
root@slax:~# hdparm -Tt /dev/sda /dev/sdb
/dev/sda:
Timing cached reads: 1124 MB in 2.00 seconds = 560.68 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
Timing buffered disk reads: 60 MB in 3.10 seconds = 19.38 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
/dev/sdb:
Timing cached reads: 1128 MB in 2.00 seconds = 563.80 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
Timing buffered disk reads: 60 MB in 3.09 seconds = 19.39 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
Kernel 2.4.28, Slax 4.1.4
root@slax:~# hdparm -Tt /dev/sda /dev/sdb
/dev/sda:
Timing buffer-cache reads: 1152 MB in 2.00 seconds = 576.00 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
Timing buffered disk reads: 180 MB in 3.01 seconds = 59.80 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
/dev/sdb:
Timing buffer-cache reads: 1124 MB in 2.00 seconds = 562.00 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
Timing buffered disk reads: 180 MB in 3.07 seconds = 58.63 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
Kernel 2.6.11, Knoppix 3.8.1:
# hdparm -Tt /dev/sda /dev/sdb
/dev/sda:
Timing cached reads: 1188 MB in 2.00 seconds = 592.61 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
Timing buffered disk reads: 50 MB in 3.09 seconds = 16.19 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
/dev/sdb:
Timing cached reads: 1176 MB in 2.00 seconds = 586.92 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
Timing buffered disk reads: 54 MB in 3.19 seconds = 16.94 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate
ioctl for device
I tested it also with Mandrake 10.2 (it is shipped with 2.6.11 kernel):
Timing cached reads was about 100 MB/sec and Timing buffered disk
reads was about 10 MB/sec.
Another test on Mandrake with 2.6.8.1 kernel - it's the fastest of all
test:
# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1064 MB in 2.00 seconds = 531.81 MB/sec
BLKFLSBUF failed: Operation not supported
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not
supported
Timing buffered disk reads: 310 MB in 3.02 seconds = 102.49 MB/sec
So on three distros with 2.6.11.x kernels (Knoppix, Slax, Mandrake),
SATA performance was extremely bad for me.
Coincidence, or something SATA-related got borked in 2.6.11?
Tomek
On Thu, Apr 14, 2005 at 06:23:30PM +0200, Tomasz Chmielewski wrote:
> I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
> Barracuda drives.
Bad combination.
> The performance under 2.6 kernels is *very* poor (Timing buffered disk
> reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
> buffered disk reads around 60 MB/sec).
2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
driver-controller combination.
See: http://home-tj.org/m15w/
--
Tomasz Torcz To co nierealne - tutaj jest normalne.
[email protected] Ziomale na ?ycie maj? tu patenty specjalne.
Tomasz Torcz wrote:
> On Thu, Apr 14, 2005 at 06:23:30PM +0200, Tomasz Chmielewski wrote:
>
>>I have a Silicon Image SIL3112A SATA PCI controller + 2x 200GB, 8MB
>>Barracuda drives.
>
>
> Bad combination.
OK, from the link you gave I can see that there might be some problems
with SIL3112 controller + seagate disks...
>>The performance under 2.6 kernels is *very* poor (Timing buffered disk
>>reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
>>buffered disk reads around 60 MB/sec).
>
>
> 2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
> driver-controller combination.
>
> See: http://home-tj.org/m15w/
...but this link just doesn't explain why performance is sooo bad with
2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is
just OK with older 2.6 kernels (Timing buffered disk reads even at about
100 MB/sec with 2.6.8.1).
any clue?
or should I wait for 2.6.11.7 (?), where it should be corrected?
Tomek
* Tomasz Chmielewski ([email protected]) wrote:
> or should I wait for 2.6.11.7 (?), where it should be corrected?
Wait, no longer, 2.6.11.7 has been here already ;-) However, nothing in
this area was touched. If there's an outstanding issue, please chase it
down, and if it's reasonable regression fix we can consider it for
the -stable tree.
thanks,
-chris
On Fri, Apr 15, 2005 at 12:08:15AM +0200, Tomasz Chmielewski wrote:
> >>The performance under 2.6 kernels is *very* poor (Timing buffered disk
> >>reads never more than 20 MB/sec); under 2.4 it runs quite fine (Timing
> >>buffered disk reads around 60 MB/sec).
> >
> >
> > 2.4 risk data corruption. 2.6 sata_sil.c contains blacklist for some
> >driver-controller combination.
> >
> > See: http://home-tj.org/m15w/
>
> ...but this link just doesn't explain why performance is sooo bad with
> 2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is
> just OK with older 2.6 kernels (Timing buffered disk reads even at about
> 100 MB/sec with 2.6.8.1).
>
> any clue?
The sata_sil blacklist grown over time. Older version didn't mark your
drive as bad. Check sata_sil history at
http://www.linuxhq.com/kernel/file/drivers/scsi/sata_sil.c ,
you may find exact time when your drive got blacklisted.
--
Tomasz Torcz To co nierealne - tutaj jest normalne.
[email protected] Ziomale na ?ycie maj? tu patenty specjalne.
Tomasz Torcz wrote:
>>>See: http://home-tj.org/m15w/
>>
>>...but this link just doesn't explain why performance is sooo bad with
>>2.6.11.x kernels (Timing buffered disk reads at 10-20 MB/sec), and is
>>just OK with older 2.6 kernels (Timing buffered disk reads even at about
>>100 MB/sec with 2.6.8.1).
>>
>>any clue?
>
>
> The sata_sil blacklist grown over time. Older version didn't mark your
> drive as bad. Check sata_sil history at
> http://www.linuxhq.com/kernel/file/drivers/scsi/sata_sil.c ,
> you may find exact time when your drive got blacklisted.
OK thanks, I'll look for that.
What is this blacklisting really (besides that it gives bad performance
for me)?
Does it mean that if I use a kernel which performs well on this hardware
(i.e. 2.6.8.1, does not seem to have this blacklisting enabled yet) I
risk data corruption?
And on a kernel in which my hardware is blacklisted, and therefore which
performs poorly, I don't risk data corruption (at least when it comes to
transferring data between the drive and the SATA controller)?
Tomek
Chris Wright wrote:
> * Tomasz Chmielewski ([email protected]) wrote:
>
>>or should I wait for 2.6.11.7 (?), where it should be corrected?
well, indeed, a week ago or more :)
> Wait, no longer, 2.6.11.7 has been here already ;-) However, nothing in
> this area was touched. If there's an outstanding issue, please chase it
> down, and if it's reasonable regression fix we can consider it for
> the -stable tree.
OK so Tomasz Torch suggested that my drive was blacklisted somewhere
after 2.6.8.1 (it's the last kernel on which I have good performance).
Does drive blacklisting = very poor performance?
And no drive blacklisting = good performance, and possibly data corruption?
Tomek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tomasz Chmielewski wrote:
>
> OK so Tomasz Torch suggested that my drive was blacklisted somewhere
> after 2.6.8.1 (it's the last kernel on which I have good performance).
>
> Does drive blacklisting = very poor performance?
> And no drive blacklisting = good performance, and possibly data corruption?
>
That's what has already been told some posts ago. The kernel developers
don't blacklist anything that works just for fun. There seems to be a
serious problem when combining this pieces of hardware so the
combination is blacklisted to get it working properly but with (much)
less performance.
cu
- --
- -----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d-(--) s++:-a- c++(++) UL+++(+) P--- L++ ! EW++ !N !o K? w--- O@ M?
V? PS+
PE- Y+ PGP+++ t+ 5++ X++ R+ tv+ b++ DI- D+ Ge+++ hr(-) y+(+)
- ------END GEEK CODE BLOCK------
They say that when you play a Microsoft CD backwards you can hear
demonic voices...
But that's nothing - When you play it forwards it installs Windows
- -------------------------------
My public key can be found at
http://www.keyserver.net
my fingerprint is
302C FD91 2CE0 487E E086 EEBC D8D9 2865 E32F 4D56
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCX24m29koZeMvTVYRAharAJ4r4aCCuDNt+B0zjv88tGgOEQIGMACgsVYm
xibnwIYSV+8LUcnXaMImorE=
=NHfy
-----END PGP SIGNATURE-----
Andre Bender wrote:
>>OK so Tomasz Torch suggested that my drive was blacklisted somewhere
>>after 2.6.8.1 (it's the last kernel on which I have good performance).
>>
>>Does drive blacklisting = very poor performance?
>>And no drive blacklisting = good performance, and possibly data corruption?
>
>
> That's what has already been told some posts ago. The kernel developers
> don't blacklist anything that works just for fun. There seems to be a
> serious problem when combining this pieces of hardware so the
> combination is blacklisted to get it working properly but with (much)
> less performance.
I see, there were people reporting "drive hangups".
They were reporting it happens quite quickly.
I don't experience those under 2.6.8.1, in which my drive wasn't
blacklisted yet (it seems it got blacklisted in 2.6.11, see this link
http://www.linuxhq.com/kernel/v2.6/11-rc2-bk6/drivers/scsi/sata_sil.c ).
My setup is SiI 3112 SATA PCI controller, 2x Seagate Barracuda 200 GB, 8
MB cache, 7200 rpm (Model: ST3200822AS ) connected into one Linux md0
raid1, ext3 filesystem on md0.
I am running several tests:
1) creating 1 GB file from /dev/zero using dd, then calculating it's
md5sum (it should always be the same; it stresses drive, too), then
copying it with a new name, calculating md5sum again - if it doesn't
match, the script will quit
I run two of these tests in parallel.
2) tar'ring / to a file (so it opens many files), then calculating its
md5sum (md5sums will differ, but it stresses the drive)
3) copying /dev/hda1 partition (which is 800 megs big on an IDE disk) to
Seagate SATA drives, then calculating it's md5sum (which should be
always the same, as /dev/hda1 is not used)
4) rsyncing / to /root/test4, then removing it - so it opens many files
and creates many, too.
These 4 tests are running simultaneously, each in a loop.
I believe it is quite stressing for the drives.
So far no hangup, weird system log, etc. unexpected behaviour.
It's 4 hours they are running now, I know it's not much, but people
reported almost instant hangups.
Or perhaps my "tests" are wrong?
# cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
# lspci -vv (for SiI 3112 SATA PCI controller):
02:09.0 Unknown mass storage controller: Silicon Image, Inc. (formerly
CMD Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller
(rev 02)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc)
SiI 3112 SATALink Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 4800 [size=8]
Region 1: I/O ports at 4400 [size=4]
Region 2: I/O ports at 4000 [size=8]
Region 3: I/O ports at 3c00 [size=4]
Region 4: I/O ports at 3800 [size=16]
Region 5: Memory at d0101400 (32-bit, non-prefetchable) [size=512]
Expansion ROM at <unassigned> [disabled] [size=512K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Tomek
----------------------------------------------------------------------
Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c