Robert Hancock wrote:
quoted text
>> 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.
quoted text
>
>> 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.

quoted text
>
>> 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).

    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...

thanks,
Linda

  

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/