Consortium Roadmap Shows 100TB Hard Drives Possible By 2025

Lucas123 writes An industry consortium made up by leading hard disk drive manufacturers shows they expect the areal density of platters to reach 10 terabits per square inch by 2025, which is more than 10 times what it is today. At that density, hard disk drives could conceivably hold up to 100TB of data. Key to achieving greater bit density is Heat-Assisted Magnetic Recording (HAMR) and Bit Patterned Media Recording (BPMR). While both HAMR and BPMR will increase density, the combination of both technologies in 2021 will drive it to the 10Tbpsi level, according to the Advanced Storage Technology Consortium (ASTC).

Comments

But what about

[Anonymous Coward]

http://hardware.slashdot.org/story/14/11/25/2027220/how-intel-and-micron-may-finally-kill-the-hard-disk-drive

Re:But what about

[houstonbofh]

Doesn't matter. It is ten years out. This prediction won't even be on Archive.org anymore by that time...

Re:But what about

[MrL0G1C]

Flash memory gets less reliable as the density increases so it doesn't look like we'll be seeing 100TB flash drives with SLC/MLC technology.

Re:But what about

[nospam007]

"Doesn't matter. It is ten years out. This prediction won't even be on Archive.org anymore by that time..."

Did the predicter claim his right of his bad predictions to be forgotten?

How about transfer rate and reliability?

[mlts]

MTBF and transfer rate numbers are boring... but those can be just as important, if not more, than the drive's capacity.

With high capacity tier 3 drives, one reason that RAID 6 (or a RAID 50 setup with tiers/groups of disks) is used is because it can take days to rebuild a blown drive. If drives continue to have larger capacities, but I/O stays the same, then we will need to add more parity drives to RAID arrays to support multiple drive failures and still keep the data accessible, better algorithms that run in the background to detect (and fix) bit rot, and bigger/smarter caches.

Maybe this is just me, but I'd rather see drives with double the MTBF than double the capacity. I can always add more drives and arrays. A failed disk will cost time no matter what, even if it is just walking to the server room, pulling it out and replacing it with a spare. For non-enterprise customers, a failed drive can be catastrophic since not many users have RAID arrays for protection.

Re:How about transfer rate and reliability?

[rrohbeck]

WTF? HDDs have seek times in the milliseconds while total access time for SSDs is in the microseconds.

Re:How about transfer rate and reliability?

[Zontar The Mindless]

Torrents, my good man. Torrents.

Re:How about transfer rate and reliability?

[rrohbeck]

I have several VMs on my system that each need at least a half TB to be useful (better a full TB.) A local cache of our SVN repo is again a couple 100 GB. Next, backups of my other systems, each a couple 100 GB at least. Next, a mirror of my server at work - nearly another TB or so. And a couple movie downloads that I haven't watched yet. Voila, over 5TB.

Re:How about transfer rate and reliability?

[Anonymous Coward]

NO. 100TB / 10KB clusters = 10 billion clusters on the SSD. Since most SSDs use SAMR3 addressing we only require 34 bits in the cluster address, At 17 bits average address resolution we have an average of 1.7ms for address bridge resolution. Once the cluster location has been ascertained we may naturally access the cluster in 10us.

It is therefore determined that an average access will require 1.701ms.

You are welcome for the correction.

Re:How about transfer rate and reliability?

[rrohbeck]

You forgot the time to charge the flux capacitors.

Re:How about transfer rate and reliability?

[Anonymous Coward]

I just downloaded a siterip of everythingbutt at 357GB. Also eyeing a 350GB Japanese Bukkake torrent. Those are just niche btw, theres 1TB+ mainstream porn torrents out there. 4k/8k will really be the death of us.

Anyway, if lesbian rimming isn't a good enough reason for you, Idk what is.

Re:How about transfer rate and reliability?

[Anonymous Coward]

It's called a joke. Look that up too.

Re:How about transfer rate and reliability?

[fnj]

As long as only a single head is active at a time, reading a single track at a time, transfer rate is proportional to LINEAR density, not AREAL density.

Re:How about transfer rate and reliability?

[Anonymous Coward]

And there is your mistake.

The OP is assuming full cluster resolution by the bridges. But we do not have a NOR per cluster so we only need enough bridges for NOR selection. if the 100TB has 10 NORs then we only need 4 bridges to uniquely identify the NOR.

100us access timer per electromechanical bridge * (( 4 total bridges required to cluster resolution / 2 for average) = 2) = 0.2ms + 10us for cluster access = 0.201ms.

Much better, much faster the HDD, and no Star Trek references.

Re:How about transfer rate and reliability?

[drkim]

100 Terabytes.

Even I would have a hard time finding enough porn to fill that.

Ha, ha, ha, ha, ha, ha, ha. Amateur.

No, seriously, check out 'Amateur'.

Re:How about transfer rate and reliability?

[Neil Boekend]

That doesn't work linearly. It's the square root of 10: 3.16

Ten times the density means 3.16 times the amount of tracks beside each other and 3.16 times the amount of bits per track.
If the head still reads only one track that means the amount of bits it can read in a given time is 3.16 times as high.
Not 10.

Re:How about transfer rate and reliability?

[Anonymous Coward]

Regarding MTBF, did you overlook the new recording technology? They are using a HAMR. The platter will consistently break on first write.

Re:How about transfer rate and reliability?

[fustakrakich]

...I'd rather see drives with double the MTBF than double the capacity.

That's not the way the market sees it. Increased reliability can only hurt sales. Our economy system requires perpetual growth, or it will collapse. Planned obsolescence is a very old method of keeping the growth alive. There is no reason that a computer and all its components can't last 20-25 years like our old TVs and refrigerators did.

Limitless?

[hcs_$reboot]

In a few more years, everybody will have enough data space in a laptop to store the whole humanity data (as long as it's not recursive). The Internet in a cache...

heat and patterned-media

[markhahn]

interesting that these density improvements could both be applied to tape as well.

yeah, "tape yuck", but it makes a certain amount of sense for cool data. which we have lots of, always increasing. tape seeks are a minute or so, and if density is competitive, tape has a good chance to beat disks on price. certainly on power. the real problem is that the tape industry seems to be sort of demographically challenged...

trillions of bits, why one head per platter?

[raymorris]

Somewhat off topic, but while we're talking about drives:

We put millions of transistors on a chip. Millions of photodetectors (pixels) in your phone's camera, a million pixels on it's display. Yet our hard drives have ONE sensor that swings back and forth on a mechanical arm?!?! Why the heck isn't the read/write head a strip, with a few thousand "pixels", so it can read any sector as the platter spins beneath it, without swinging the heads back and forth? That would eliminate seek time.

  If needed, you could move the strip back and forth a thousandth of an inch to align a head with one of it's four tracks. That'd be a lot quicker that moving the head a full inch as they do now.

So presumably there is some good reason that can't be done. Still, an additional arm exactly like the existing one, but on the opposite side of the platter, would cut rotational latency in half and increase throughout up to 100%. Seems like an easy win.

Re:trillions of bits, why one head per platter?

[Anonymous Coward]

Before hard disk drives, they had magnetic drums. It was a large drum that spun at a constant speed and had a separate head per track. You could read from any track, but only once the data you wanted to read rotated to be under the head for that track. Once upon a time computers used drums for main memory and core for cache.

Your idea for an arm with a head for every track is essentially a more modern drum. That and the two-armed HD are both ideas that are likely more expensive to be worth it. The head mechanism is the expensive part of the drive, so having two of them is almost as expensive as having two whole drives, so why not just have two drives?

dom

Re:trillions of bits, why one head per platter?

[amalcolm]

Most disk have multiple platters, so already have multiple heads simultaneously reading multiple tracks. Replicating the actuator (motor+magnet + electronics) would be the expensive bit.

Re:trillions of bits, why one head per platter?

[drinkypoo]

Alignment isn't an issue - there's no alignment on a modern drive. Instead, at the factory, they write a set of servo tracks all over the platters which do the aligning for you - basically the head seeks to approximately the right position and starts reading, and the servo track tells it where it actually is, so feedback gets the head to the right track.

Sigh. Alignment is an issue, because each platter has its own alignment. That means that when you're reading/writing one platter, you're not aligned for the other platters. That's why you can't have multiple heads on one armature (which has multiple arms, all fixed together) and read/write multiple platters at once.

the bigger reason why two actuators didn't work is far simpler - think multiprocess programming. Both actuators could read or write data to the platters (of which there was one set) and if you screwed up the order of the accesses, you could easily write the wrong thing

You're being ridiculous. That's true no matter how many actuators you have — if you screw up, you write the wrong thing. Even if you only have one actuator, if you write the data to the wrong sectors, you're gonna have a bad time. But both actuators have the same job: write some data to someplace. The two don't have the job to write the same data. If the drive gets a command to write data to a sector to which it already has cached data waiting to write, then hopefully it just throws away the first command anyway. This is something we would hope any drive with queuing would do whether it has 1 actuator or a dozen.

think you do a read then a write of a sector - and the sector happens to be under the actuator doing the write

HDD sectors are either 512 bytes or 4kb. In the former case they are often smaller than filesystem blocks and there is no need to read them before writing. You just run right over them. In the latter case, they are typically the same size as filesystem blocks (we use bigger blocks on larger filesystems, and we use 4k blocks on multi-TB drives) and again, there is no need to read them before wrtiting. You only have to find them, which means waiting the seek and then for some fraction of the time it takes the spindle to go around once. Then you can write. This is true no matter how many armatures are reading/writing the same disk.

Who would need that ?

[bobjr94]

The average new computer being sold today sits on a desk in an office or is a facebook machine at home. It will have in it 500GB to 1TB of storage on average ? Then whats the actual usage, 20% or less ? I have people asking me all the time, my computer is slow do I have too many pictures on it ? I look at their drive, 482GB capacity, 404GB free.

Sure there are some users who have hundreds of movies stored on their computer and businesses and datacenters who would love a drive like that but by number of computers, thats a small percentage. A majority of computers would do much better with just a SSD 1/4 the size of the HDD they currently have. A faster system overall, bootup times cut by 60%, 20-30 minutes more battery life in laptops....