Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Hardware

Breaking the ATA Addressing Barrier 145

Posted by michael from the 128-petabytes-should-be-enough-for-anyone dept.
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."
This discussion has been archived. No new comments can be posted.

Breaking the ATA Addressing Barrier More

Breaking the ATA Addressing Barrier

Comments Filter:
  • Every lame PC "standard" has continuous artificial limitations like this. Remember the 8086's memory addressing? Go with SCSI on a 64bit processor and you won't have to deal with this crap.

  • Human Consciousness (Score:3)

    by edashofy ( 265252 ) on Saturday June 30, 2001 @01:29PM (#117693)
    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 (Score:4)

    by UnknownSoldier ( 67820 ) on Saturday June 30, 2001 @01:31PM (#117694)
    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:Human Consciousness (Score:1)

    by Anonymous Coward
    Unless you've got multiple personalities. :)
  • SCSI!

    How much longer are we going to be stuck with I/O interfaces that bog the CPU (and cripple the user inteface) during heavy disc access?

    Apparently only about 1% of us actually want to use our computer to do more than one thing at a time.
    --
  • I use SCSI [about.com] HD's. Seriously...how much of an issue will this be? Isn't USB 2.0 supposed to replaced ATA ;) Or whatever happened to that newfangled serial interface Intel was working on? The one that was going to be faster than 1394 and rid my PC case of ugly IDE/Floppy cables.

  • Go with SCSI on a 64bit processor and you won't have to deal with this crap.....

    Sounds lovely doesn't it?

    but then you'd have to pay a whole lot more for lovely SCSI hardware, which may not be an option for many of us (especially people in other not so fortunate countries)

    and you'd have to recompile many applications to run on 64 bit, not to mention buying the lovely 64 bit stuff Intel and AMD can't see to agree on, which might I add is pricey, which may not be an option for many of us (especially people in other not so fortunate countries)

    doing all of that? ... or a simple FLASH of the BIOS?

    Sunny Dubey

  • 48 bits is a lot (Score:3)

    by delmoi ( 26744 ) on Saturday June 30, 2001 @01:41PM (#117699) Homepage
    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. (Score:4)

    by Greg Lindahl ( 37568 ) on Saturday June 30, 2001 @01:42PM (#117700) Homepage

    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? (Score:4)

    by cperciva ( 102828 ) on Saturday June 30, 2001 @01:42PM (#117701) Homepage
    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! (Score:5)

    by Waffle Iron ( 339739 ) on Saturday June 30, 2001 @01:42PM (#117702)
    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.

  • 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.
  • Sometime last year, IEEE proposed new naming standards - gigabyte, megabyte etc would mean 10^.... , while the 2^... variants would become 'mebibyte, gibibyte, tebibyte...

    I may have it backwards, and i don't know if it ever was approved, but it sure does sound funny. can you imagine buying a 10 gibibyte hard drive?

    --buddy
  • Yeah, whatever do the math. A limit that lasts for hundreds of years is fine by me.
  • > Or whatever happened to that newfangled serial interface Intel was working on?

    You mean Serial ATA [serialata.org]? It should be on the market Q4/01-Q4/02 but since it only deals with the physical/transport layers, it should work in addition to this proposal.
  • It would be difficult for me to accept this as a solution to the upcoming limits of ATA hard drives. what kind of transfer rate can you get off an ATA drive! If I'm going to need a 100TB hard drive it isn't going to be from my mp3 collection. Its going to be massive data files for rendering and databases. I know this is a little offtopic but shouldn't ReadWrite mass storage move away from simple linear devices before we have 1TB capacity?(Not to the certain loss of life span on a mechanical drive spinning at 50K rpms)
  • What's the point of setting those standards if it's physically impossible for bits at that density to maintain cohesion?

  • Ancient Lore (Score:4)

    by selectspec ( 74651 ) on Saturday June 30, 2001 @01:56PM (#117709)
    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.
  • Not if you want to make a backup of the entire world's population's brains :)
  • I'd like to know, why, exactly, does my Win2k box get horribly bogged down when reading and writing the Floppy? Does this happen with Linux too? I can't do a damn thing when formatting a 1.44 disk, and for the life of me, I can't understand why manipuliting such a small about of data is so demanding.

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

  • The new ATA bus will have 42 bits (Score:1)

    by Anonymous Coward
    6 bits will be taken up by Big Brother's "digital rights management" software.
  • I can't speak for Win2k (my win2k box doesn't have a floppy), but my WinNT box at work doesn't get bogged down when reading or writing to a floppy. Neither do either of my Linux boxes.

    On the other hand, my Win9x machine used to all but die when I was formatting a floppy. My guess is Linux and NT have better I/O handling so they have no real problem with reading and writing 1.44mb of data.
  • 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]

  • Would you pay $300 for a 40GB Infiniband HD or $100 for a 40GB IDE HD?
  • Whereas everything else you read on Slashdot is accepted as fact?
  • 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.
    --

  • Don't you know that creating 64-bit addressing is difficult. The design should fit for today's need.

    Let's say that we have the 64-bit addressing. Thus, every single transfer (either read or write) has to send this 64-bit signal in which some of those are padded with zeroes (i.e. unused). Don't you imagine how much power it wastes to transfer those zeroes? Moreover, 144 PB should be enough for 20 years [maxtor.com]. Come on! Be realistic. By 20 years, mankind would have come with different solution.

  • Yeah. That's it. I thought it was a bit more revolutionary than evolutionary. That's hardly any better than 1394 will be.

  • 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.
    --
  • One of OS/2's claims to fame in the 2.x days was that it, unlike Windows 3.1, could format a floppy without bring everything else going on to its knees.

  • 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.

  • Re:Ancient Lore (Score:1)

    by Anonymous Coward
    Infinband storage protocol (SRP, aka SCSI Remote-DMA protocol) is just a way to move SCSI-3 command packets across a different physical interface. If you're tired of SCSI, you're going to have to find something other than Infiniband. -- Chris Caudle (RAID design engineer in my other life)
  • Cost. Design it for 64-bits now and all the circuitry has to be designed for 64 bits, even though processors can't address that much yet. Now when 64 bit processors become available and can address that much you'll have to buy a new motherboard anyway (or live with only 32-bit addressable of memory space) so it'll probably come with an integrated ATA card. Might as well wait to design a 64-bit ATA card until then. Over designing a product is a waste of money.

  • Re:Argh, can't they get it right ONCE (Score:5)

    by Anonymous Coward on Saturday June 30, 2001 @02:21PM (#117726)

    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 [ciar.org]. Collection is ongoing, and I'll refresh the web site from the master records sometime too.)

    -- Guges --

  • Apple may be spurred into taking over future development...

    Slashdot did not post your article because this is not guarenteed to happen. If Apple were to take over development of powerPC processors then I'm sure the article would be posted. As of now it is only speculation.

    So please, stop posting this...

  • What about serial ATA -- we keep hearing about this. There is a lot of information at the serial ATA [serialata.org] homepage.

  • What about SerialATA? (Score:3)

    by YuppieScum ( 1096 ) on Saturday June 30, 2001 @02:33PM (#117729) Journal
    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?
  • The difference between "Science" and "Science Fiction" is primarily that "Science Fiction" hasn't happened... yet.
  • I>Taco, Homos, and Rob REJECTED the informative article I wrote, just like they rejected ALL the informative articles I've ever written

    wah, wah, wah, none of my articles ever get posted, wah, wah, wah, I post off-topic and it gets moderated as off-topic

  • What about copy protection? (Score:3)

    by astrashe ( 7452 ) on Saturday June 30, 2001 @02:36PM (#117732) Journal
    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.
  • 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.
  • You are an idiot. Did you read the article?? If it is truly ATA you are speaking of, then you are dead wrong, because that is exactly what it was talking about. Thus you are either a blatant liar, or it is not ATA. But good job of trying to tout the Macintosh, and then ending up making its users seem like idiots. bravo. Macs suck.

  • New unit of measure... (Score:3)

    by Polo ( 30659 ) on Saturday June 30, 2001 @02:46PM (#117735) Homepage
    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.
  • There have been studies to show that the brain is NOT lossy, but can't be recalled consciously. I don't have a link for you, sorry.
  • The whole idea of breaking data up into chunks addressable by an integral range of numbers limited by the bus size is in dire need of change!

    Only problem is.. where do we go from here?

  • Improving IDE performance in Linux (Score:4)

    by Anonymous Coward on Saturday June 30, 2001 @03:13PM (#117738)
    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.

  • If you want your post to be scored 1+, simply don't post AC. As for the rest of your whine, there's only so many stories that get posted here, and if you have to cut, hey, why not cut a fairly speculative story? It's not like it won't get posted here if and when it really happens. And yes, I've had a shitload of submissions rejected as well.

    Oh, and just for the record: Linus is Finnish :-)

  • Re:Enough! (Score:1)

    by Anonymous Coward
    LBA already got rid of C/H/S addressing, providing a flat 28-bit address space. Sectors are referenced by a single number, cylinders and heads are no longer used. The new standard will also have a flat address space, 48 bits this time.

    Most of the problems with compatibility have been BIOS problems, and operating systems that bypass the BIOS do not have these problems. Linux does not use the BIOS (although LILO does, so you might need a boot partition below 528MB), and I don't think WinNT and *BSD do either. Win9x does use the BIOS, and because so many people use it, a lot of people have had problems with large hard drives. These problems are not the fault of the ATA standard.

  • Would you pay $24K for a Pontiac or $8K for a Yugo?

    Higher quality (reliability, performance, etc) means higher cost.

  • File and partion sizes are measured in 'real' kilo/mega/giga bytes, but the medium in which they are stored is measured in marketing gigabytes. You can store only 128 one-gigabyte files on a 144GB HD.

    Not very logical IMHO (and I think the thousands of newbies asking where the 2 gigs from their new 30 gig HD went will agree)

    --

  • gigabytes (Score:3)

    by csbruce ( 39509 ) on Saturday June 30, 2001 @03:49PM (#117743)
    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"!
  • What, you can't remember the link?

    *rimshot*

  • I believe that would be a RAID.

    Your welcome.
  • I doubt being able to use the same hard drive standard between 2030 and 2056

    Considering that 2001 adapters are register-compatible with those from 1984, I wouldn't be shocked if you could.
  • I'll concur -- My PII-400/100 with 40Mbit SCSI is far more responsive and lighter on the CPU than my work PIII-733/133 with ATA-66. Both have 256MB, W2K (which should be enabling the ATA magic just fine)

    Both machines are plenty fast for what I need, it's just a perceptual smoothness that's present on the SCSI machine and absent on the IDE one. I know the benchmarks make it look about equal, but if you've got the dough, SCSI is a worthwhile upgrade in my book, over say an incrementally faster CPU.
  • Actually, your /boot partition doesn't have to be below 528MB, or even 8GB anymore.

    I don't remember since when, but LILO now supports linear address mode, and my linux bootpart happens to live at 10GB just fine.

  • I don't have this problem on W2K. Reading, writing and formatting a floppy work like a charm and don't bog my machine down. I think the problem is either your floppy controller or something's not right in your OS.
  • 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.
  • It's 10^9 if you're selling, and 2^30 if you're buying ;-)
  • Even the in the small article above, it mentioned that the extension is only available in LBA mode. Please read, then use the exclamation point. Right, and my DRAM should stop using ROWS and COLUMNS. Why can't all my memory just get along?
  • A petabyte should be PB. Peta- is not p. Internation System [jraxis.com] (SI) prefixes are case-sensitive Peta- is P, and pico- (which is very, very small, 10^-12), is p.
  • Isn't a "pB" a *pico*byte? A "Petabyte" would be a PB, no? Same way that a mm is a millimeter, and a Mm is a megameter. It's case-sensitive.

    Personally, I don't want any picobyte-capacity hard drives. How about you?
  • I remember seeing at one point that someone had an idea to rename all the 1,024-based prefixes to something like kibobyte, mebabyte, gibabyte and so on to differentiate them from their 1,000-based metric counterparts. I think he had written an actual proposal out and submitted it to one of the computer standards organisations. Of course, now I can't find it, and most of what Google is bringing up look like peoples typos [google.com].

    If anyone knows what Im talking about...

  • I beat you to it [slashdot.org] by four minutes. ;)
  • Actually, that's only 8.0 zebibytes, which is the SI binary prefix [alcyone.com] for 2**70.

    9.4 Zettabytes is correct. Zetta is the decimal prefix.
  • 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.

  • 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.
  • "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."

    Well, you make some wrong assumptions here, a 32-bit OS can do 64 bit arithmetics quite well.
    (many do so for file accesses e.g.).
  • 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:Argh, can't they get it right ONCE (Score:3)

    by istartedi ( 132515 ) on Saturday June 30, 2001 @05:49PM (#117762) Journal

    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.

  • If that next generation includes copy protection, we'll have to live with it.

    ... Or abstract the preferred file system somewhat more than we do now unless market forces (read BOFHs who don't want to hand-install WindowsNG/OfficeNG on each of 3,000 machines) force rights management crap to become stillborn (likely).
  • 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.

  • Drives spinning at 7200 rpm will still kick data out at the same speed,

    No. Larger size in the same form factor == higher density. Assuming the platter spins at a constant linear velocity, and constant data density on disk, higher density means more bits per inch of circumference to read off and transfer. Of course there are ways to get around this by magicing with non-sequential sectors etc. but you want faster transfers on larger disks anyway, or have fun waiting for large (#/size) disk ops to finish.

    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.

    Most RAID(-like) striping schemes double the READ speed (two apertures seeking one piece of data) but reduce the write speed (two apertures writing the same piece of data and/or redundancy structures on to two disks) plus there's I/O overhead. Plus you have to get added/expensive goodlier controller(s) for decent performance.
  • 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?
  • You know, I read that as "Kibobyte", and was really apprehensive of what a google search for that would turn up...


    --Fesh

  • Most RAID(-like) striping schemes double the READ speed (two apertures seeking one piece of data) but reduce the write speed (two apertures writing the same piece of data and/or redundancy structures on to two disks) plus there's I/O overhead. Plus you have to get added/expensive goodlier controller(s) for decent performance. Ummm... I think you're thinking mirroring (same data on two drives). Striping is basically alternate writing between the two disks. No pure striping scheme writes the same data to more than one drive. Of course, this implements no redundancy, but such is the price of performance. On the controller topic, even software-based RAID such as FreeBSD's vinum have usually similar, and sometimes better, performance compared to hardware. Of course, this is only for simple schemes such as RAID 0 and 1. For something like RAID 5 (distributed parity), hardware is always faster.
  • Urgh... USENIX for a week has fried my brain. Must... close... tags...

  • 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 [tuxedo.org] 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

  • serialATA not for some time (Score:1)

    by Anonymous Coward
    Serial ATA is not planned to be included on an Intel chipset until some time in 2003. It's unlikely manufacturers will produce SATA discs before then, or even for some time afterwards.

  • Serial ATA is designed to be hardware-compatible with current ATA. One can assume that the spec will account for 48-bit addressing. In the meantime, remember that widening the address space on a parallel bus will increase costs; more wires, more costs.

    New, huge drives can be built with nary a concern over the serial or parallel-ness of the interface.


  • 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?

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

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

  • 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 [tuxedo.org] 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 [lil-abner.com]. 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.

  • 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 :)

    --
  • "kibobyte," "mebabyte," "gibabyte"

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

    "Saxamaphone"...
  • "ma" == "'metric' alternate"
  • ...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...

  • So what? (Score:3)

    by YuppieScum ( 1096 ) on Sunday July 01, 2001 @01:38AM (#117788) Journal
    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.

  • Or maybe... "gigabytes for dummies"

  • 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 [astrumsoftware.com].

    (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

    =============================================
  • 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.

  • 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 [nist.gov], 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.
  • 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.

  • 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.

  • 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.


    ---

  • 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.

  • 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.
  • 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.

Slashdot Top Deals

"The medium is the massage." -- Crazy Nigel

Close