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.

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.

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.

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?

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.

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"!

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.