Parallel IDE drivers

[Posted September 5, 2006 by corbet]

Back in 2003, Jeff Garzik announced the availability of "a new SCSI driver." That driver was, in fact, the libata subsystem, which was to be the foundation for serial ATA support in Linux. In the process, however, Jeff had thought a bit about supporting the current parallel ATA (PATA) drives, but that was not really his goal:

Note that PATA in my driver is only an afterthought. The main area of focus, now and in the future, is SATA.

In the last three years, the parallel ATA drives that most of us use have continued to be driven by the old IDE driver subsystem. Some of this code dates back to the beginning of Linux; since then it has been maintained by a substantial list of people, a number of whom are widely held to have been driven insane by the experience. The current maintainer, Bartlomiej Zolnierkiewicz, has kept a rather low profile for some time now; he signed off no patches in either of the 2.6.17 or upcoming 2.6.18 kernels. Not much has been happening in the IDE area.

That does not mean that things have been quiet in the parallel ATA area, however. Over the last year or so, Alan Cox has been working to bring full PATA support into the libata code. The resulting drivers have been sitting in the -mm tree for a while, but that period is about to end: the PATA driver set has been queued for merging into 2.6.19.

The stated advantages of the new PATA code are many. The code has been reworked from the beginning, and is up to current kernel standards. The use of libata means that these drivers are well integrated with their SATA cousins, bringing two divergent subsystems back together. The new drivers support a number of chipsets that the IDE layer doesn't handle. Error handling has been much improved. Also, according to Alan's announcement from August, the new drivers feature "active maintenance and updates" and "more interesting bugs to find and help fix."

On the other hand, the new PATA drivers are not considered to be ready for production use yet, and distributors are not expected to enable them in the near future. The merging into 2.6.19 is intended mainly to broaden the test base. A completely new disk subsystem is the sort of thing that one likes to test very well before entrusting it with data that one wishes to actually keep; that process may go on for a little while yet. It is also worth noting that the new PATA code also drops support for some ancient IDE controllers.

The issue that gets everybody's attention, however, is that, as with all drives handled through libata, PATA drives show up as if they were SCSI disks, and are named /dev/sd*. Anybody who just switches to the new drivers without updating /etc/fstab (or using the mount-by-label feature) is likely to have a rough bootstrap experience. That is an easy problem to work around, but the use of the SCSI drive namespace seems to bother some people. What appears to be happening in reality is that Linux is slowly moving toward having a generic disk subsystem, where everything can just be called /dev/diskN. All that's left is a few details and a new set of udev rules to rename the device nodes.

Someday, most of us will be using the new PATA code. But this is not a process which is expected to go quickly, and there are no plans to remove or deprecate the existing IDE code:

At this point in time it is premature to discuss or plan the point at which the old IDE layer would go away. That discussion can start at the point where everyone is happy that the new libata based layer is providing better quality and coverage than the old one. Even then there would be no need to hurry.

So it appears that Linux will have parallel subsystems for parallel ATA support for some time.

Index entries for this article
Kernel	libata
Kernel	Parallel ATA

Parallel IDE drivers

Posted Sep 7, 2006 2:28 UTC (Thu) by rvfh (guest, #31018) [Link] (3 responses)

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?

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 (guest, #5246) [Link] (1 responses)

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.

Duncan

Parallel ATA drivers

Posted Sep 8, 2006 19:04 UTC (Fri) by giraffedata (guest, #1954) [Link]

I think one of the best things about this is retirement of "ide" as a misnomer for ATA (PATA) devices, at least in one place.

For those not familiar with the naming mixup: "IDE" is a technology that is used in all modern disk drives, including SCSI. The first IDE drives used the protocol called ATA (now sometimes PATA), and the names got mixed up.