Linda Walsh wrote:
Robert Hancock wrote:
Have you tried using a different block size to see how that effects
the results? There might be some funny interaction there.
----
There is some interaction with the large block size (but only on the
SATA
disk). Counts were adjusted to keep the read near 2G (~2x physical
memory).
From 1k-16k block sizes, I got into the low-mid 40MB/s on buffered SATA
(compared to 50-60MB/s on ATA & SCSI). Starting at 32k-64k, the read
rate began falling and at 128k block-reads-at-a-time or larger, it drops
below
20MB/s (again, only on buffered SATA). It's hard to imagine what would
slow down buffered SATA reads but not ATA and SCSI reads of the same
size. I'm using the 'cfq' scheduler with everything running at default
priorities, but again, why only SATA slowness? It seems that at the driver
level, using direct reads, the SATA disk has the highest read rate (near
80MB/s).
It would certainly be perverse to have faster driver & device
performance
equate to lower buffered I/O.
Not too sure on that one. I suspect one might have to trace the actual
requests being received at the driver level somehow with buffered reads
in order to diagnose what's going on there..
I wanted to use the newer pata support in the SATA lib, but
got frustrated "real fast" by the lack of disk-parameter support
in the new pata library (hdparm is mostly broken; and the SCSI
utils aren't really intended for ATA(or SATA?) disks using the
SCSI interface.
It's somewhat intentional that some of the hdparm commands (like for
settting transfer modes, enable/disable DMA, etc.) don't work with
libata. Most of them aren't necessary at all as correct DMA settings,
etc. should always be set automatically (if not, please report as a bug).
---
The only way I could tell before was using hdparm to read the
parameters.
Since that doesn't work, it's hard to tell if they are set correctly,
but given
the high performance at the device driver level, I'm guessing the params
are set correctly.
The settings in use should be reported in dmesg.
Since SATA's use ATA-7 (or at least the Seagate disk I
acquired seems to), shouldn't most of the hdparm commands
be functional on the SATA hardware as much as they would
be on PATA? Or...maybe said a different way, is there
an "sdparm" that is to SATA what hdparm is to PATA?
It's the same libata code, so the same applies to some of the hdparm
commands not being implemented, as above.
---
Hmm... might be nice as an "RFE" to at least have the 'read-status'
commands work to see what the params are set to.
More importantly, how does one set parameters for acoustic and power
saving parameters? Some of my disks are used as 'backup' devices for my
other computers. With the ATA disks, they were kept "spun down" when not
being used (only used, 'normally', in early AM hours).
I believe those hdparm commands for power-save and AAM are supposed to
work (they just issue an ATA command to the disk). The ones that aren't
implemented are the ones that actually commanded the IDE layer, like DMA
on/off.
Another new "problem" (not as important) -- even though SATA disks are
called with "sdX", my ATA disks that *were* at hda-hdc are now at hde-hdg.
Devices hda-hdd are not populated in my dev directory on bootup. Of course
this throws off boot-scripts that set diskparams by "hd<name>" and not
by label (using hdparm). Seems like the SATA disks are suffering a partial
identity problem -- seeming to reserve hda-hdd, but using the "sd" disk
names.
Is that a known problem? If not, I'll add it to my queue for bug-filing...
Could be a udev problem, as it's what does the device naming..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
