User: Password:
Subscribe / Log in / New account

Parallel IDE drivers

Parallel IDE drivers

Posted Sep 7, 2006 2:28 UTC (Thu) by rvfh (subscriber, #31018)
Parent article: Parallel IDE drivers

Last time I checked, hdparm could not send much commands to 'SCSI' hard disk - in my case a USB-attached IDE hard disk -, and especially could not spin it down. Is that sorted now? Or does the [slow] move to libata remove some power management features?

(Log in to post comments)

Parallel IDE drivers

Posted Sep 7, 2006 10:20 UTC (Thu) by cortana (subscriber, #24596) [Link]

I believe this is a limitation of USB mass storage devices--similar to how you can't run smartctl on them. You might be able to do a few things with sdparm that you couldn't with hdparm, however--since they are 'SCSI' devices, after all.

Parallel IDE drivers

Posted Sep 7, 2006 13:07 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]

What about sdparm, given libata disks show up as SCSI?

LibATA and PATA drivers, hdparm/sdparm, and partitions

Posted Sep 19, 2006 10:43 UTC (Tue) by Duncan (guest, #6647) [Link]

sdparm is FAR less mature than hdparm, and in many cases is essentially a
read-only interface (like hdparm -i/-I). That doesn't seem to be changing
very fast, either. OTOH, hdparm is slowly but surely developing
additional general SCSI and libATA specific capacities. The biggest
holdup initially was that libATA didn't support pass-thru of the needed
ATA command set, so hdparm couldn't get the necessary commands thru to the
hardware or the necessary results back from the hardware, but that seems
to be changing with the latest kernels (2.6.17-rcX+, AFAIK). Apparently,
hdparm has actually had the ability to send the commands to libATA for
some time and was only waiting on libATA to pass them thru, so the hdparm
actually working functionality has been "magically" improving with the
latest kernels, even without new versions of hdparm.

One can therefore come to a relatively safe conclusion that hdparm will
continue to function more or less as it always has, possibly with no
actual user visible changes at all, as libATA capacities in regard to PATA
hardware improve.

Of course, the other big issue is that the traditional IDE interface has
allowed for 63 partitions, while SCSI has only allowed for 15. On my last
PATA drive I had some 20-plus partitions, some of which were backup images
of others. Fortunately, I saw mention of fact that the 15 partition SCSI
limit applied to libATA SATA drives as well, before I tried switching
over, so I wasn't caught unaware and was able to prepare. However, there
will likely be those for whom it's a problem.

(As it happened, by the time I actually switched to SATA, I had decided to
go quad SATA drive kernel RAID, RAID-1 boot, partitioned RAID-6 main
system, RAID-0 for temporary and recacheable/redownloadable data. On the
RAID-6, I ran three partitions, root, root-bak, and a third partition
overlaid with LVM2, which contained most of my former partitions as LVM2
logical volumes, so I didn't run into the issue. However, had I not seen
the warning about the 15 partition limit on SCSI including libATA, I
likely would have switched to SATA earlier and would have run into the
issue, so yes, it's a very real one for some people.)

Maybe the libATA PATA work bypasses the 15-partition SCSI limit some way?
I'd certainly be nice if it did for those not running RAID or LVM, given
the half-terabyte and larger drives we are seeing now.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds