[CentOS] hdparm: Inappropriate ioctl for device

Wed Sep 7 14:20:57 UTC 2005
Bryan J. Smith <b.j.smith at ieee.org>

Kai <centos.newsgroup at sandsengen.com> wrote:
> Does it exist a tool for sata? Or are there no need?

Has nothing to do with SATA (although libata does, see
below).

hdparm _only_ works when the Integrated Drive Electronics
(IDE) are talking directly to the system over the AT
Attachment (ATA) arbitrator.

IN OTHER WORDS:  That means the device _must_ appear as a
/dev/hd* block device so hdparm can work.

When the device is supported via the SCSI subsystem, which is
typical of newer ATA/SATA drivers that are not yet feature
complete, all bets are off.  They _may_ be supported via
various SCSI-2 commands, but most of the time, they are not.

YOUR BEST BET:  Use "modinfo -p" on the vendor's SCSI driver
to see what options are supported at load time.

Understand that ATA is typically statically compiled in for
all ATA device support, and hdparm is a way to control
individual ATA channels.  Unlike SCSI modules, which can have
individual module options, and therefore can be individually
controlled.

Now there is the libata support library.  I haven't
investigated it much, let alone I don't know if it requires
ATA (hd) or it can also support SCSI (sd).  I think it can
support both, but I haven't gotten into it yet to even know
what it features.

IN THE END:  SATA requires _little_ optimization.  There is
no "EIDE" or other "PIO" IDE backward compatibility AFAIK,
only full UltraATA compliant modes.  SATA was designed to
_avoid_ a lot of the issues ATA had with EIDE and other
backward compatibility, while still be backward compatible
with newer ATA specifications.

So, are you having a particular issue with SATA?
If so, have you investigated the SATA module's options yet?
If not, then that's your first move.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)