[lkml]   [2007]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card);
    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
    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
    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

    It would certainly be perverse to have faster driver & device
    equate to lower buffered I/O.
    >> 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
    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.

    >> 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
    Is that a known problem? If not, I'll add it to my queue for bug-filing...


     \ /
      Last update: 2008-01-01 01:23    [W:0.039 / U:30.796 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site