# IDE PATA - old stack or the libata?

## clavko

I was wondering are there any advantages of

using libata drivers for an all PATA system?

Thanks!

----------

## NeddySeagoon

clavko,

You get DMA working for free with the libata drivers. 

Its simpler to set up

----------

## Dairinin

With IDE stack you get 32-bit io. Libata is limited to 16. Also there is irq unmask feature

The only right answer is: test both and select what perform better  :Smile: 

----------

## clavko

Thanks, people!

Ofcourse, it's all about choices, I've grasped that philosophy by now.

You can't always follow all of the news from all of the areas of computing,

so I needed to know if libata were "the way to go" (TM) in a way KDE once

was for our beloved Linus. I'll test them both, but predict very similar results.

Thanks once more!   :Very Happy: 

----------

## depontius

Maintenance and development are going into libata.  Right now IDE may be better, but that situation won't last forever, since the kernel developers are putting their energy elsewhere.  There is a certain value to sticking with the mainstream, unless you're sufficiently skilled to wander.  Of course the word "sufficient" itself is open to question.  Right now I'm using XFS for my media partition for MythTV, but am keeping in mind moving it over to ext4 once people are happier with it.  By the same token, the rest of my data is on ext3.

Not the most daring or technically correct approach, but there's a certain value to safety in numbers, too.

----------

## NeddySeagoon

Dairinin,

irq_unmask was a dirty hack introduced before UARTS had FIFOs.

It was needed to allow the lower priority serial port IRQs to be processed while a disk IRQ was being serviced, which in turn alled the UART to operate above 9600 characters per second without dropped characters. 

It should be disabled now, except on very old hardware that still makes use of such serial ports.

Enabling irq_unmask today has a down side. If some device, like a network card, gets a lower priority IRQ than the hard drive, under heavy network traffic, the additional IRQ processing can cause the disk IRQ to time out. When that happens, the kernel reverts the drive to PIO mode.

32 bit I/O is far less important with DMA than it was with PIO. It applies only from the disk controller on the motherboard to RAM.

There is still only a 16 bit bus from the drive to the drive controller.

----------

## eccerr0r

Not sure if this is really a pro or not for the legacy drivers... it seems that detecting disks on the legacy drivers is a bit faster... but not totally sure about this... all my libata machines take a bit longer to detect disks...

One time cost, yes, but it does add to boot time...

Also I think the legacy ATA drivers is smaller in terms of memory footprint...again not too sure about this.

----------

## Cyker

One other thing you should be aware of is that libata names all disks using /dev/sdx whereas the BLK_DEV drivers use /dev/hdx, so swapping between them will cause a major headache unless you don't use those names to reference them.

I personally prefer the old BLK_DEV drivers:

a) They are more mature and better tested

b) hdparm works with them much more cleanly

c) They are loaded before libata

d) They don't use sdx

c) & d) mean that if you're booting off an IDE disk, you can't bugger up the boot by, e.g., plugging in a USB or eSATA/SAS drive into the system (Which will disrupt anything that relies on /dev/sdx naming because alll the sdx stuff is assigned on a first-come-first-served basis, whereas BLK_DRV assigns by controller, so for the built-in controllers at least, you are guaranteed that hda is Primary Master, hdb is Primary Slave, hdc is Secondary Master etc.)

I really dislike how libata doesn't seem to pass any useful params for determining what controller something is on; I've been trying to hack up some udev rules to assign the sdx's based on controller (And also put back hdx for IDE controllers!) but I've only done it on a machine-specific basis, and even then if you use eSATA/SAS/SCSI it all goes out the window anyway!

So... yeah, I'm sticking with the 'Ain't broke, don't fix it' way for now  :Smile: 

I don't really understand what this push for moving IDE to libata is anyway; It currently has less functionality than BLK_DEV and seems to be reinventing the wheel slightly differently just for the sake of needless unification  :Sad: 

----------

## tld

 *Cyker wrote:*   

> One other thing you should be aware of is that libata names all disks using /dev/sdx whereas the BLK_DEV drivers use /dev/hdx, so swapping between them will cause a major headache unless you don't use those names to reference them.
> 
> I personally prefer the old BLK_DEV drivers:
> 
> a) They are more mature and better tested
> ...

 

Wow...am I glad I read this.  I just started another thread with questions about making this switch.  I never even thought about that sd* first come first serve naming stuff.  That is pretty scary.

What's more, I can't seem to find out what hdparm stuff is supported by libata in 2.6.29, or how to tell /etc/conf.d/hdparm to do anything to /etc/sr0.

I'm starting to think I might stick with IDE as well.

Question: One machine of mine has both the old IDE and the libata compiled into the kernel (only because the machine actually has an SATA controller that I'm not using).  For IDE drives, will the IDE always get used instead of the libata if it's enabled, even with the 2.6.28 kernel?

Tom

----------

## NeddySeagoon

tld,

libata has lots of small parts, if you don't enable the PATA part for your PATA interface, the old driver can still be used.

Its a really bad idea to enable both the old and new drivers for the same hardware at the same time.

It won't do any damage to the hardware but it won't work either.

PATA drivers under the SCSI layer have to obey the SCSI specification, so things like DMA cannot be turned off.

Hopefully they don't do IRQ unmasking either but I've not looked.

----------

## tld

 *NeddySeagoon wrote:*   

> tld,
> 
> libata has lots of small parts, if you don't enable the PATA part for your PATA interface, the old driver can still be used.
> 
> Its a really bad idea to enable both the old and new drivers for the same hardware at the same time.
> ...

 

That's odd...I just looked in the kernel config of the machine I mentioned above (a Dell 4600...my MythTV backend, which has only IDE drives installed).  Under the new libata section I do in fact have the PATA interface enabled...in my case for the Intel ICH controller.  I also have it enabled under the old ATA/ATAPI/MFM/RLL section (again for Intel ICH).

Up until now at least (running a 2.6.27 kernel) it's been using only the old IDE interface for both the drives (both IDE) and the cdrom.  Is the issue you're referring to specifically if I were actually trying to use SATA drives at the same time?  That sounds like the issue discussed here:

http://linux-ata.org/faq.html#combined

...which frankly confuses the hell out of me.  I have no clue as to whether this would apply to, for example, by MythTV frontend (a Dell 4700C) which has a SATA drive and an IDE DVD drive.  Currently that's using libata for the hard drive and IDE for the DVD drive (which is using /dev/hda).  32 bit IO and DMA seem to enable just fine on the DVD.

Tom

----------

## Cyker

Hmm.. I think 2 different but related issues are being talked about here, hence the confusion.

Neddy's talking about where you have some IDE controller, but you have both BLK_DEV *and* libata PATA drivers compiled for that controller; This is not a good idea and can result in 'Undefined Behavior'. Usually the BLK_DEV gets first pick and will lock out the libata driver (Safe), but there have been instances where this didn't happen and both drivers tried to control the IDE controller at the same time which resulted in interesting kernel panics  :Mr. Green: 

example:

If you have (BLK_DEV_AMD74XX) and (PATA_AMD), these are both targetted at the same controller (nVidia/AMD IDE controller - The former is BLK_DEV's, the latter is libata's) and hilarity may or may not enschew.

OTOH, if you have (BLK_DEV_AMD74XX) and (SATA_NV), these are okay to mix as the former controls AMD/nVidia IDE while the latter controls AMD/nVidia SATA.

EDIT: I though you were talking about SATA controllers pretending to be IDE controllers (For backward compatibility), and getting control conflicts from BLK_DEV/libata-SATA/libata-PATA, but it seems this Intel problem you linked to is a THIRD (!!!) problem I haven't even come across before...

I don't actually know what 'combined mode' is, but it sounds like it merges the resources of the controller in some way that prevents two different drivers programming it for DMA access. Or something. ;>.>

I'm also confused by where it says in the FAQ to set IDE mode to AHCI; I don't understand how that is even possible o.O (Unless it meant setting the SATA controller to AHCI and they mistakenly wrote IDE??!)

----------

## NeddySeagoon

Cyker,

Combined mode is covered correctly in the kernel now.  It was introduced with the ICH7 IDE/SATA chip set.

The two interfaces share some registers which meant it was not possible to set up both interfaces correctly with separate drivers.

Hence in the early days, you could have IDE or SATA working properly but not both at the same time.

The libata driver for the ICH7 IDE/SATA chipset sets up both interfaces now and it all just works.

The old IDE driver should not be used with this chip set.

----------

## eccerr0r

I've started migrating most of my machines over to libata.  The only exceptions are ones that are memory limited (those with less than 512MB RAM) and "legacy" applications (my PATA RAID) ... however my RAID will be migrated to libata with the disk upgrade.

I used to be run the legacy ATA drivers on my i865 (ICH5?) boards that have SATA.  Currently I'm running it via bios legacy mode but with libata drivers... (seems to work... main reason for one system was due to wanting the subsystem to look the same as it was before to Windows when the old PATA hard drive was replaced with an SATA.)

I think my last machine to migrate is my laptop with 1GB RAM, using ICH4 ... mostly for uniformity between machines despite legacy working just fine.

----------

## Cyker

 *NeddySeagoon wrote:*   

> Cyker,
> 
> Combined mode is covered correctly in the kernel now.  It was introduced with the ICH7 IDE/SATA chip set.
> 
> The two interfaces share some registers which meant it was not possible to set up both interfaces correctly with separate drivers.
> ...

 

Ahh, thanks for clearing that up!  :Mr. Green: 

I must admit I was having a wtf?! moment reading that part of the FAQ!

----------

## tld

 *NeddySeagoon wrote:*   

> 
> 
> The libata driver for the ICH7 IDE/SATA chipset sets up both interfaces now and it all just works.
> 
> The old IDE driver should not be used with this chip set.

 

Are you referring to the 2.6.28 kernel?  Does that kernel automatically set DMA for IDE CD/DVD drives when using libata?  The two machines I that I have with SATA controllers are ICH5 and ICH6.  Does the same apply for them?  Actually I have a third machine with an 82801BA IDE U100 (with no SATA ata all).  If I'm going to switch I'd prefer to switch all of them.

 *Cyker wrote:*   

> 
> 
> Neddy's talking about where you have some IDE controller, but you have both BLK_DEV *and* libata PATA drivers compiled for that controller; This is not a good idea and can result in 'Undefined Behavior'. Usually the BLK_DEV gets first pick and will lock out the libata driver (Safe), but there have been instances where this didn't happen and both drivers tried to control the IDE controller at the same time which resulted in interesting kernel panics 

 

I'm guessing that I may just be getting lucky with the IDE DVD drive on my MythTV frontend.  I guess the IDE driver is getting to it first and blocking the libata driver.  I checked in the BIOS of that machine and it does in fact have a BIOS setting for "Combined Mode" which isn't selected...the other option ("Normal") is.

Tom

----------

## energyman76b

 *NeddySeagoon wrote:*   

> clavko,
> 
> You get DMA working for free with the libata drivers. 
> 
> Its simpler to set up

 

you get dma for free with pata too - if you don't enable the 'generic' driver.

But apart from that: 

libata is the better choice. Sure, the error messages suck compared to the pata error messages, but if you have to deal with them, you have other problems anyway, but on the plus side, timeouts are much shorter - so even if you hit an obstacle it will be a lot less annoying  :Wink: 

Another good thing: if you have SATA and PATA devices and go libata, remove the old ide layer, your kernel is smaller! Smaller = better  :Wink: 

----------

## tld

I've converted one of my IDE systems to libata under 2.6.28-gentoo-r5.  Here's one thing that throws me a bit:

One of the hdparm settings that apparently isn't supported is -m (R/W multiple sector transfer).  Apparently the max on my drives is 16, and libata is defaulting to 8.  The odd part is that the old drivers used to default this to 16...I never specified any -m args in /etc/conf.d/hdparm.

My big concern is with my MythTV backend machine.  That has 2 500GB Seagate drives.  The lvm that I have recordings on spans the drive that also has the / partition and the MySQL databases.  That's a non-ideal situation, but one I can't do anything about easily.  In spite of that however, I'm able to record HD programs on all three tuners at once while watching another recording all at the same time, even with some commercial flagging going on.  I'm pretty sure I don't have room to loose even the slightest bit of disk performance there.

Except in the possible case of WD drives, I don't see anything in the hdparm man page that leads me to believe 8 would be a better setting.  If anyone knows more about this I'd like to hear about it.

Tom

----------

