Breaking the ATA Addressing Barrier

BitMan sent in an overview of the next step in addressing large disk drives. I tend to run into these every few years when I try to add a new, large drive to an older machine and find out that some factor is keeping me from being able to use the full drive capacity. Well, the next step will push those limits out quite a ways, giving us a few more years of ever-increasing drive space.

BitMan writes: "If you haven't heard, there has been a new disk geometry limitation looming for some time at 128GB (gigabytes of 2^30 bytes), which is 137GB (gigabytes of 10^9 bytes). As many will note, there have been various BIOS and OS limitations in disk geometry before -- e.g., 512/528MB, 2GB, 8GB, 32/33GB, etc... But what makes the latest 128/137GB "limit" different is that it revolves around the "hard, physical addressing" limitations of the ATA (AT Attachment) interface. 28-bits are used for addressing, which results in the 2^28 sector * 512 bytes/sector = 128/137GB limitation. As such, hardware fiends like myself were wondering when the industry would get around to addressing this "hard" limitation in the ATA interface.

Fortunately, the solution is already in the works. The ANSI ATA committee has accepted a proposal from Maxtor that extends the ATA bus addressing to 48-bits. This allows for up to 128 pB (petabytes of 2^50), which is 144pB (petabytes of 10^15), sizes. This should tide the PC world over until the 2TB (terabytes of 2^40) limit is reached, which is the maximum number of sectors a 32-bit OS can address -- i.e. 2^32 sector * 512 bytes/sector = 2TB.

In addition to breaking the addressing limitation, another addressing limitation was overcome for performance considerations. The maximum number of sectors transferrable in any command was boosted from 8-bit = 256 sectors/command (~128KB max. transfer/command) to 16-bit = 65,536 sectors/command (~32MB max. transfer/command). This should increase ATA/IDE performance in burst transfers and many other operations.

A whitepaper on the new proposal can be found here from Maxtor. Small correction in the article: Maxtor says 144 pB (petabytes) = 144,000 GB (gigabytes), which is quite incorrect. 144pb (petabytes of 10^15) = 144,000 TB (terabytes of 10^12) = 144,000,000 GB (gigabytes of 10^9).

Thanx goes to the most excellent StorageReview site where I first heard of this."

Comments

Human Consciousness

[edashofy]

A. C. Clarke says you can store an entire human consciousness in a petabyte. This should be a big enough address space, then, for a while anyway.

Re:Human Consciousness

[saberwolf]

Just think how helpful the next version of The Annoying Paperclip Thing in MS Office could be with a petabyte of consciousness. I'd be afraid to turn it off for fear of causing it some irreporable psychological trauma.

Re:Human Consciousness

[unitron]

Yeah, right, the guy who came up with the idea of geo-synchronous satellites and bouncing radio signals off the moon wasn't a scientist. Your definition of scientist must be very narrow.

Argh, can't they get it right ONCE

[UnknownSoldier]

Why can't the hardware and bios just use a 64-bit sector number. There, problem solved, and no more stupid limititions because someone is trying to save a buck or two since they only used a 12-bit address, er, now 16, er, now 28-bit address.

ENOUGH already. Design it RIGHT the 1st time.

Re:Argh, can't they get it right ONCE

[Anonymous Coward]

There are good reasons for using smaller address words, caching efficiency chief among them. On systems which run their filesystems fully-asynchronously (like linux), filesystem caching efficiency is a primary factor in limiting performance for filesystem-intensive applications. When your file data set exceeds main memory's ability to cache it, performance can plummet like a stone. If your filesystem cache metadata takes up 25% more space because you are using 64-bit address words instead of 32-bit (64 bits is 100% larger than 32 bits, but metadata records contain a lot more than just address words), then your maximum cacheable filesystem is only 80% (1.0/1.25=0.8) what it could have been.

Even with small data set sizes, this can mean a lot, because you see performance degradation when you spill L1 cache, and another when you spill L2. It's a lot easier to get 25% more compact metadata than it is to get 25% larger L1 and L2 caches!

What makes the most sense is to design our operating systems to be able to treat filesystems as large (2+ TB) or small (2- TB), and use cache data structures to match. That way we'll have higher performance in the "common case", and corporations who need to be able to support (eg) huge databases will be able to do so.

For the past few years, hard drive data density per dollar (in best density per dollar products, not top or bottom of the line products) has been increasing exponentially at a rate of 2.15x per year. If we project that naively and assume it holds steady (which is unlikely, so take this with appropriate salt) then we should expect to bump into the 2 TB limit on our home desktop computers in about 10 years. To me, that makes filesystem-segmented 32-bit sector addressing "good enough" for a good long time.

(I have been tracking hardware trends since the early 90's; the past two years' worth has been collected automatically via web-bot from the same vendor, so it is easily indexable .. I hope to enter my hard-copy data some day as well, but what a pain! I have made parts of it, from 1999-01-05 to 2000-09-12, available on my web site here. Collection is ongoing, and I'll refresh the web site from the master records sometime too.)

-- Guges --

Re:Argh, can't they get it right ONCE

[istartedi]

Well, if you really want to kill this problem you need some kind of call that will tell you how many bits the address is. Even if that number is just 32-bits, the actual sector number could as large as 4 gigabits wide. How much is 2^(2^32)?. A bloody huge inconceivable mind exploding number (that's the technical term for it). Right now I can't think of any reason for having more sectors than there are atoms in the universe, but don't dismiss it. That's the same kind of thinking that got us the 640k barrier.

48 bits is a lot

[delmoi]

I'm sure it has to do with physical limitations and performance. Anyway, this is a different problem then the BIOS one, ATA has been able to handle 137gig drives since it's creation. And now were talking about increasing that capability by A Million Even if we apply more's law to hard drives, that's still over 30 years away. 64bit on the other hand would be useful for about 54 years. Either solution would will work for quite a while, and I doubt being able to use the same hard drive standard between 2030 and 2056 is really that much more then performance considerations today.

Re:A better solution to this problem.

[Greg Lindahl]

ATA already has features which don't "bog the CPU"
and "cripple the user interface". Your criticism is 5 years old; a few OSes (like Linux) have this fully
implemented.

Of course, the OS can also cripple the user interface during heavy disk access, SCSI or ATA.

What is a gigabyte?

[cperciva]

Is a gigabyte 10^9 bytes, or is it 2^30 bytes? It depends what you're talking about.

For computer memory, the SI prefixes are certainly used to refer to powers of 2: 640 kB of RAM means 655360 bytes, not 640000 bytes.

For networks or clock speeds, the SI prefixes are certainly used to refer to powers of 10: 10Mbps ethernet can carry 10^7 bits per second, not 10*2^20 bps; similarly, a 1GHz processor runs at 10^9 Hz, not at 2^30 Hz.

And disk space? The manufacturers all specify their sizes in terms of decimal powers. And why not? Everything else, with the exception of computer memory, is expressed in terms of decimal powers.

Let's put this silly argument to rest; I'm sure people have much more important things to argue about (vi vs emacs, BSD vs linux, bash vs ksh...)

Enough!

[Waffle Iron]

Why even have "sector"-based addressing when the hard drive is just going to munge the addresses into some other physical layout anyway? It's been sector/cylinder/head compatibility hell for the last twenty years.

Maybe just once they should make the painful switch to a simple flat 128-bit address space and be done with it.

Re:Enough!

[David Gould]

Sectors are referenced by a single number, cylinders and heads are no longer used.

The problem is that sometimes, for people who need to do seriously high-performance I/O, you want to be able to know the drive's geometry and reference sectors at specific cylinder/head locations, to optimize sequential access and minimize seeks. Sure, they're laid out sequentially, so you can just assign things sequentially and expect access to be "mostly" continuous, but if you don't know where the cylinder boundaries are, you'll occasionally get unlucky and have something spanning two cylinders and causing a lot of unnecessary seeks. Knowing a bit about your access patterns, you could have avoided this if you'd known where the boundaries were. You might even want to get really scary and try to make the locations of things on the disk correspond to the time you expect to need them, so they'll always be just passing under the head when needed.

Of course, this mainly matters for things like high-end databases, but it might conceivably be worthwhile for other high-end applications like media streaming, video editing, or 3D rendering, or for low-level system things like swap-storage management or filesystem layout, where nobody else would have to worry about it but the benefit would apply across the board.

David Gould

Re:Enough!

[red gnu]

The problem is that sometimes, for people who need to do seriously high-performance I/O, you want to be able to know the drive's geometry and reference sectors at specific cylinder/head locations, to optimize sequential access and minimize seeks.

It's a seductive idea. I've even written that code back in the olden days. Of course mine was nowhere near the level of Mel's scary code. But I sure wouldn't want to attempt it today.

Modern disk drives with zoned recording, megabytes of cache, and automatic bad block remapping would make any attempt at software optimization a nightmare. You could easily end up pessimizing by abusing the cache on the controller or accessing sectors that the drive controller says are contiguous but which in reality have been transparently remapped to Lower Slobbovia. I don't think there is any way to get guaranteed accurate geometry any more. I am afraid you just have to take what the drive is willing to give you and hope for the best.

Re:Enough!

[Ben Hutchings]

The old CMOS configuration format used something like 1 byte for number of heads, 10 bits for number of cylinders (1-based), and 6 bits for number of sectors per track. Hence you can specify up to 255 heads, 1024 cylinders, and 63 sectors/track. I think the same format is used for the parameters of BIOS calls for reading and writing disk sectors, which are used by DOS and by the first stages of boot loaders. This results in a limit of about 8 GB.

The IDE C/H/S addressing mode allows something like 4 bits for head number, 10 bits for cylinder number, and 14 bits for sector number. If the BIOS uses this mode and doesn't invent a new geometry for use in BIOS calls then it can only work with drives that claim geometries of up to 16 heads, 63 cylinders, 1024 sectors. This results in a limit of about 504 MiB or 528 MB in older BIOSes.

If the drive had to tell the truth about its geometry then the limits would be even smaller.

Ancient Lore

[selectspec]

Revamping the ATA spec is like dusting off the plans for the pyramids for revision. ATA, and even SCSI are showing their age in more ways than one. We should be investing in Infiniband, RapidIO, etc.

Re:Ancient Lore

[mz001b]

What about serial ATA -- we keep hearing about this. There is a lot of information at the serial ATA homepage.

Re:A better solution to this problem.

[Greg Lindahl]

Well, actually, I was thinking about VM policy
issues, but yeah, using the BIOS is a sure way
to shoot yoursel fin the foot.

Backward compatibility

[Rosco P. Coltrane]

The next step of course, once the address bus is extended, is to make sure old hard drives can still be used with the new super-duper bus.

To achieve this, I propose the creation of the "GATE-A29" to allow older software that wrap around the addressing space to access the first sector of the hard disk to continue to function properly. This gate could be controlled with one of the keyboard controller's free lines (to save one cent), and could be turned on and off from the BIOS. Also, there should be a new INT21h function to control the "GATE-A29".

What a perfect way to extend the PC-AT architecture in the totally unencumbered and elegant fashion it has evolved so far !

[Seriously people, just buy SCSI drives, they already do the work properly]

Re:Backward compatibility

[dillon_rinker]

Firewire?

Re:A better solution to this problem.

[e_n_d_o]

I'm not trying to flame here, I just want to learn more about this.

I have not seen an ATA-based system perform this way. I find my 333MHz 20MBit (read: old!) SCSI system at work is much more pleasant to use than the 750MHz boxes with ATA66 setups (setup by Dell). All of these systems are running RH7.1.

Examples of the situation that will "bog" or rather "cripple" the faster ATA boxes but not the SCSI one include:

- Starting VMware and booting up the windows virtual machine
- Running updatedb (not really that bad though)
- Installing a couple hundred megs of RPMs.
- Installing Oracle 8i. (~500MB, uncompressing to 1.4GB)

Is there anything I can do to make the newer ATA boxes perform as well as the SCSI one? I'm getting a new computer at work soon to replace the 333, and it probably won't have SCSI, so I'm very interested to learn more.
I do know that Linux is recognizing the drives as ATA and not "reverting to PIO mode" which I've heard is the obvious solution to this type of complaint.
--

minor correction

[e_n_d_o]

Ahem, ah, yeah, that should be "20MByte" not "20MBit" SCSI system.

I don't think a "20MBit" SCSI system would stand much of a chance at competing with anything except my TI99/4A.
--

Re:A better solution to this problem.

[Greg Lindahl]

Well, you didn't say if you had DMA enabled for the ATA drives or not. It doesn't come that way out of the box, and I have no idea if Dell does the right thing or not. The program you use to investigate this is "hdparm", and you should be able to find a HOWTO which discusses it.

However, DMA mode is only the half of it. The amount of memory you have and the ability of your OS to properly manage it is the other half of it.

What about SerialATA?

[YuppieScum]

SerialATA was supposed to be hitting in the same time frame as this. Why are they dicking with 48bit just to make the hardware implimentation cheaper?

Also, has anyone checked to see if CPRM is being "stealthed" into the spec?

Re:What about SerialATA?

[YuppieScum]

...remember that widening the address space on a parallel bus will increase costs; more wires, more costs.

That was my point(granted it was implicit rather than explicit). They're dicking around with half-arsed compromises like 48bit instead of doing a real job and using 64bit or 128bit.

Serial ATA is designed to be hardware-compatible with current ATA.

Er, no. SerialATA is designed to use the same command protocols, and drive & controller subsystem will remain the same (as happens for IDE and SCSI drives) but the interface hardware changes on both the drive and the host. There will almost certainly be adaptor boards (like the SCSI SCA-U/SCSI2 boards) to make a parallel ATA wire-compatible with SerialATA. Everything else just becomes a software issue...

What about copy protection?

[astrashe]

Are they going to try to bundle the copy protection stuff with this upgrade? Or are the two issues completely disconnected?

It's easy to say that we'll stick with the uncrippled technology we already have. But as it ages and becomes obsolete (ie., can't handle normal sized disks), we'll be pushed into the next generation whether we like it or not. If that next generation includes copy protection, we'll have to live with it.

Re:What's the point?

[bugg]

The drive interface should last longer than the current technology in storage- should holographic storage hit the market en mass, you can bet there'd be drives that will use this new standard, forinstance.

New unit of measure...

[Polo]

I propose a new unit of measure:

How about the Bogo-Gig

For instance, 137 BG Bogo-Gig (base-10 or marketing-style), which translates to 128 GB (base-2, fair and actual non-marketing gigabytes)

Any ideas on better units for monitor sizes?

Maybe ideas for MTBF (Marketing Time Between Failures?) I was told that hard-drive manufacturers actually count on several returns per drive. It's definitely not 100,000 hours like they like to say.

Improving IDE performance in Linux

[Anonymous Coward]

I use the command "/sbin/hdparm -d1 -c3 -m16 -u1 /dev/hda" (repeated for each hard drive) to improve my drive's performance.

-d1: Use DMA
-c3: 32-bit IO
-m16: Transfer 16 sectors at a time
-u1: Unmask interrupts

According to the hdparm man page, the -u1 option will greatly increase system responsiveness. The other options mainly improve throughput. Many people also use the "-X66" flag to select UltraDMA mode2 transfers, although my BIOS seems to do that automatically.

To test your IDE transfer rate (do this before and after tuning), use "hdparm -tT /dev/hda". It is recommended you test your IDE settings on a read-only filesystem before you start using them regularly - usually the commands don't cause problems, but they can cause major data corruption with a few buggy chipsets (having a recent kernel might help).

You may also be able to recompile your kernel, having it use IDE drivers specific to your chipset, rather than the generic IDE drivers. Kernel 2.4 is probably needed, and you should know what kind of IDE chipset you have (check your motherboard manual). Go to "ATA/IDE/MFM/RLL support" in the kernel config menu, and make sure it is set to "Y". Then go to "IDE, ATA, and ATAPI block devices", make sure the following options are set to "Y":

• Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
• Include IDE/ATA-2 DISK support
• Generic PCI IDE support
• Generic PCI bus-master DMA support
• Use PCI DMA by default when available
• (your chipset) chipset support

Then save the config, compile, and install the kernel. You may still need to use the hdparm commands after doing this, just put them in a startup script.

gigabytes

[csbruce]

128GB (gigabytes of 2^30 bytes), which is 137GB (gigabytes of 10^9 bytes)

Calling both of these "gigabytes" is confusing. The second figure should be referred to as "metric gigabytes"!

Re:gigabytes

[unitron]

Yeah, there was a story on Slashdot about it a while back.

Try googling for "kibibyte" or even for "kibble byte".

It might even be an actual standard by now but everybody just feels entirely too silly saying them.

Re:gigabytes

[Fesh]

You know, I read that as "Kibobyte", and was really apprehensive of what a google search for that would turn up...

--Fesh

Re:gigabytes

[csbruce]

"kibobyte," "mebabyte," "gibabyte"

It might sound slightly less ridiculous to use Homer Simpson-esque words "kilomabyte", "megamabyte", "gigamabyte"...

"Saxamaphone"...

Re:gigabytes

[csbruce]

"ma" == "'metric' alternate"

Re:gigabytes

[Skapare]

Or maybe... "gigabytes for dummies"

Many eggs in 1 basket

[Gothmolly]

Drives spinning at 7200 rpm will still kick data out at the same speed, and will still be as prone to failure, regardless of capacity. For performance and redundancy (I can't imagine that nothing in your 128GB dataset is not valuable), you need to go multi-spindle, i.e. RAID. Case in point:
Local screwdriver shop has 40GB deskstars for $120. They have a 75 GB for $240. The obvious solution = buy 2x40 and stripe them. Same $$, more capacity, and 2x the speed.

Re:Many eggs in 1 basket

[jandrese]

And double the failure rate!

Yay data loss! I just wish tape drive manufacturers would get their heads (and prices) out of the clouds so I could get a cost effective backup solution.

Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.

Re:Many eggs in 1 basket

[psergiu]

1) Mirroring (what's an extra 120usd if you want to be SURE that you don't lose your 40Gb of data)
2) RAID5 (unfortunatelly i haven't seen ATA controlers doing this in hardware, so it's either SCSI or software raid)
3) Click on my .sig to get THE BEST tape deal ever. Yes i have one. Yes it works a-ok :)

--

Re:Whitepaper hints at 64-bit addressing

[sconeu]

Actually, that's only 8.0 zebibytes, which is the SI binary prefix for 2**70.

9.4 Zettabytes is correct. Zetta is the decimal prefix.

Re:*Yawn*

[sconeu]

SCSI-3 FCP has a 10Km cable length. Is that long enough for you?

SCSI-3 divorced the transport and access protocols. Yes, parallel SCSI has limitations, but you can run SCSI over Fibre Channel (SCSI-FCP) and even IP (iSCSI).

Nice try.

Re:Not to be pedantic, but ...

[unitron]

Wouldn't anything that divides a byte by powers of ten be an imaginary concept anyway? You can divide it into 8 bits, but smaller than that isn't it like discussing the "integer-ness" of pi?

Re:A better solution to this problem.

[Greg Lindahl]

So you have no idea if it's enabling ATA DMA or not... especially the bit that allows faster interrupts? You know, the Linux hdparm -u1 flag?

What? No copy prevention mechanism?

[Pig Hogger]

What? No copy prevention mechanism?

The MPAA and the RIAA will surely kill this technology!!!!

--
Knowledge is, in every country, the surest basis of public happiness.

So what?

[YuppieScum]

So what if SerialATA won't be on an Intel chipset until 2003? FireWire will never be on an Intel chipset (as they want USB2.0 - to which they hold the patents - to become the standard) but you can buy a 4-port FireWire PCI card for £25.

Remember ATA66? Intel was the LAST vendor to adopt that standard into their chipsets - Via, ALi et al all had solutions in the marketplace while Intels BX was their champion and CaminoGate was giving us all a jolly good laugh.

Remember too PC133 memory. Other chipset vendors have been supporting this for ages, but Intel have only just "gotten off the dime".

You should also give the drive makers more credit. They will realise that SerialATA is a change of maybe 15% to the drives controller board - just a change to the physical interconnect and the silicon that drives it. They're already doing this to produce both SCSI and ATA drives, so rolling out another is not that big a deal.

Striping is not RAID!

[RedBear]

For performance and REDUNDANCY (I can't imagine that nothing in your 128GB dataset is not valuable), you need to go multi-spindle, i.e. RAID. Case in point: Local screwdriver shop has 40GB deskstars for $120. They have a 75 GB for $240. The obvious solution = buy 2x40 and stripe them. Same $$, more capacity, and 2x the speed.(emphasis added)

To save people needless grief from following this advice, I feel that something should be explained.

There is a very good reason why striping is called RAID Level 0 (that's a zero), which is because it's not redundant! By utilizing RAID-0, you double the probability that one of the two hard drives will fail, and since 50% of all the data is on the other drive, even the drive that doesn't fail is basically unrecoverable! Sure, it doubles read speed, but even hardware implementations will have slightly slower write speed unless both drives are absolutely identical in geometry, access speed and spindle speed. RAID-0 is essentially useless for anything where reliability is concerned. There are numerous RAID tutorials that explain the differences. Just check Google, or see this quick explanation of RAID levels.

(Moderators, I'm expecting at least one mod point for this short but informative post which includes a link to an informative web page. If I do not get at least one mod point, I will go postal and kill my boss. Urm, I'm self-employed, nevermind.)

--RedBear

=============================================

s/the/the next/

[The Man]

The entire history of this interface consists of hack after hack after hack to get around this or that "barrier." First it was 540MB, then it was 8GB (with 2GB thrown in for people using crappy OSs), then 30-something, and now 147. But I can put a state of the art 180GB SCSI disk in a 14 year old sparcstation 1 and it will work just fine - all the disk will be addressable (and even bootable!) with no third-party drivers, no upgrades, no special cables, just the standard equipment and software that's been in use from day one.

There have been a lot of improvements to ATA since it first appeared. But when I see so many changes and improvements year after year just to approach the same level of performance (and not really even try for the same flexibility) as SCSI has had since day 1, I can only conclude that ATA was, and presumably still is, misdesigned from the start. That's why I don't use it, and why you shouldn't either. Use SCSI, or 1394, or FC, or one of the hot new technologies that you can't buy yet. It's long past time for ATA to die. They blew it from the start and have never really recovered.

Of course, in that regard, ATA and the peecee are a match made in hell. Neither one has ever let the cost of competent design work raise the price by even 1 dollar. You might say you get what you pay for, but if you're buying this stuff you must be paying for rape.

NIST defined prefixes for binary multiples

[QBasic_Dude]

Realizing that G=(10^3)^3=1,000,000,000 bytes, the NIST (a governmental body that sets standards) decided to formalize binary multiple prefixes, which of course are based on powers of 2 rather than powers of ten. They defined Gi (gibi) to be (2^10)^3=1,073,741,824, which is quite different from 1,000,000,000. In this article the reader confuses gibi with giga. Please use GiB for multiples of 1,073,741,824 bytes, and GB for multiples of 1,000,000,000 - this will help avoid confusion, as well as keep drive manufactures honest.

Still plenty of size limits to come

[pjrc]

It's good that ATA/ATAPI-6 will have a spec for 48 bit LBA, though it probably should have been done much earlier. The fifo approach is interesting (keeping all control within the original 8 bit ISA...)

But this won't be the end of "storage barriers". As a quick example, Linux 2.4.0 had a maximum size for any volume (even LVM & RAID) of only 1 TB last time I checked. Maxtor's white paper mentioned 2 TB limits in nearly all OS's due to use a 32 bit integer to store the sector address.

Microsoft undoubtedly has many similar implementation limits, even if the raw format of FAT32 and NTFS can handle more. If past history is any indication, PC bios code will also consistantly have problems with "next years" drives, simply due to bugs and short sighted coding, even though there's no "real reason" for it.

Will the real Gigabyte please stand up?

[The Monster]

Actually, the metric definition of Giga = 10^9 has been around a lot longer than the binary variation. Somewhere in the dim mists of computer history, someone noticed that 2^10 ~ 10^3, and started talking about "kilobytes". If anything, we should call these "binary kilobytes", "binary gigabytes", etc.

Re:*Yawn*

[Sloppy]

While this is true, ATA is far cheaper than SCSI and nearly equivalent in capabilities you need.

Not if everyone switches to it and it becomes the mainstream. The cost difference is almost completely due to economy of scale.

Probably the real reason that SCSI isn't mainstream, is that if it were, it would kill the differentiation betweenn the low-end and high-end markets, and then manufacturers wouldn't be able to get away with charging extra for SCSI. There is strong incentive for there to be more than one standard, so some form of IDE will always have its niche.

---

Re:*Yawn*

[Ben Hutchings]

The keyboard controller is not involved in memory access; it's only used to enable or disable one of the address lines. If this is enabled while the processor runs in real mode, another 64 KB of memory beyond the 1 MB mark is accessible. For total compatibility with real-mode software written for the 8086 it must be disabled. If it wasn't for the continued use of DOS while memory got much cheaper, no-one would have had to care about it, but some bright sparks decided that it would be useful to get that extra 64 KB while running DOS.

Re:*Yawn*

[Ben Hutchings]

I agree with you, accept that you are incorrect in saying "ATA only allows for two buses" which is incorrect. There are only two well-known sets of I/O addresses for ATA interfaces, but it's possible to have many more. There are 2 on my motherboard and another on my sound card (yes it really is an ATA interface, not a proprietary CD-ROM interface). I think Linux allows for up to 8 or 10 ATA interfaces.