Seagate Announces 750GB Hard Drives

Hack Jandy writes "Seagate documents have leaked out the two 750GB 7200.10 Barracuda hard drives. The drives are the first desktop hard drives to use perpendicular recording, feature a 16MB cache and 7200RPM spindle."

On Seagate's product page:

[amcnabb]

Check out the Seagate Barracuda [seagate.com] for more info.

Re:EVERY NERD DANCE

[Anonymous Coward]

You don't even post a link [hitachigst.com] to it.

Re:Great for backups

[Anonymous Coward]

Digital cameras have already exceeded 12 megapixels. They are primarily for photographing images that will be used in large signs and posters. People like you and I will likely never need one.

Re:As usual wait for the real reviews

[iluvcapra]

TFA says that the average seek time will be 4.16 ms. Seek time is the time it takes for the arm carrying the head to swing from track x to track y on average. Rotational latency is the time it takes for a particular sector on that track to find its way around to where the head is waiting for it. Both, along with transfer latency make up the total latency.

Re:But what about...

[tomstdenis]

Will Linux support it... hehehe that's cute.

I have friends who have multi-TB raids at their homes using a mix of IDE/Sata/USB in one RAID ...

While hardware RAID support in Linux is a bit hit or miss the software kernel support works properly and is fairly quick. Certainly the bottleneck for most setups will always be the drives themselves.

Tom

Re:But what about...

[onx]

Yes, it should considering that according to Wikipedia http://en.wikipedia.org/wiki/NTFS [wikipedia.org] [wikipedia.org] states that the maximum volume size for an NTFS volume is 16EiB. One exibyte is 1,152,921,504,606,846,976 bytes, so 16 exibytes = 18,446,744,073,709,551,616 bytes. Since a 750GB hard drive should hold approximately 750,170,112,000 bytes, an NTFS volume should be able to handle 24,590,081 of those 750GB hard drives in a RAID array. Now assuming a RAID array can handle that many of these drives, and that this new 750GB hard drive merely takes the price spot of Seagate's current finest offering of a 500GB hard drive (priced on newegg as $295 each) http://www.newegg.com/Product/Product.asp?Item=N82 [newegg.com] E16822148108 [newegg.com] rather than debuting at a higher price point, which it probably will, that many hard drives would cost about $6,147,520,250 before tax, and not including any of the massive discounts one might expect to recieve for such a massive purchase. On top of that, at a sales tax rate of 7.75%, the tax on those drives would cost you $476,432,819.38. So I don't know about you, but I doubt this is going to be a problem for either XP or Vista for a long, long time (assuming you use NTFS partitions).

Re:Great for backups

[tomstdenis]

That's right up there with the Monster cable displays...

Yeah cuz you need 2000dB of S/N to listen to a movie soundtrack... Oh but come on, 30$ per foot of copper is worth it!

Some people are just highly stupid.

At best I can see the drive for 20-bits [and 24 just because it's a nicer multiple of 8] but 32-bits would imply 192 dB of dynamic range which is FAR FAR FAR beyond the average hearing range. Given that the "noise polution" in the average house sits at a constant 30dB or so ... the finer range isn't noticeable even with the best ears.

Just like pixels the human eye fuzzes out around 10 to 12-bits per channel [depending on the eye and channel, for instance most people are more sensitive to green than red or blue]. Just like the audio case there are masking effects with light. After 12-bits or so of range it's just academic.

Tom

Re:Format this Red Hat!

[nairb774]

A quick look to Wikipedia says...32TiB for the largest volume size. If you are using a partitioning tool - that might be your limitation but it is definatly not in the file system. http://en.wikipedia.org/wiki/Ext3 [wikipedia.org]

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Wow!

[Anonymous Coward]

First, the amount of space an N character 7-bit ASCII text file will consume depends on how it is stored. This is true in terms of filesystem level compression as well as hardware level compression. Typical American English text is quite redundant.

Second, MP3 size varies with bitrate and song length. I have MP3 files that easily consume 30MiB. Third, as storage capacity increases higher-bitrate codecs (Musepack, or lossless codecs like FLAC) become more attractive in the mainstream. 5.1 channel audio, higher sampling rates, and larger samples sizes also become more attractive with increases in optical and magnetic storage capacity.

Third, Moore's "Law" deals exclusively with the observation of exponential growth in circuit complexity every 18 months. It has absolutely nothing to do with magnetic storage capacity.

Finally, video will always serve as a serious space sink for computer storage. Uncompressed, high-resolution, progressive video content will bitchslap current storage capacities. Increased capacities will simply make more things possible in the mainstream, and permits higher-quality media.

But yes, we can all see from your comment history that you're an asshat troll. Good work, sir.

Re:Great for backups

[John Courtland]

Sorry to burst your bubble, but pictures already go to almost 40 Megapixels. Kodak just made a CCD that is like 39MP, Hasselblad uses it for one of their 30 thousand dollar camera backs. Here's a link to one [calumetphoto.com]

Re:Wow!

[Brain_Recall]

They don't even use servo's anymore (though, servo's and stepper-motors are the same thing). Current hard drive technology (well, for the past 10 years or so) use voice-coils, much in the same way a speaker is moved. Servo drives often required a low-level format to recalibrate the tracks to the current position of the heads, since time/heat could position themselves outside the track boundry. The voice-coil system can do this all on the fly. (And yes, the clicking heard by today's drive is from the heads moving fast enough like a speaker to produce sounds).

"Conventional Giga " and "Standard Giga SI prefix"

[this great guy]

While your post remind people that different definitions of GB are used, you are actually adding to the existing confusion. Because what you call a "real GB" is not real at all. You should rather call it "conventional GB", as in "conventional Giga prefix used in computing, ie 2**30". The real Giga is the Giga prefix as defined by SI, ie 10**9. Disk manufacturers are just using the standard Giga SI prefix instead of the "conventional Giga prefix". Other people are doing it in the computing industry. Bandwidth and throughput are also typically referred to using standard SI prefixes (e.g. an MP3 file at 128 Kbit/s is 128000 bit/s NOT 128*1024 bit/s).

Re:But what about...

[arkhan_jg]

I'm running 3x 400GB SATA's in a software RAID5 on a linux server no problem. The key problem you may be thinking of was the LBA48 support. Older IDE drive controllers only supported LBA32, so they would only see 137GB of larger drives. Often a BIOS upgrade fixes that, and ups support to LBA48. Newer SATA spec doesn't require LBA48, but I'm not aware of one that doesn't, though there's probably the odd one. There'd very likely be a BIOS or flash upgrade for the controller to add 48-bit addressing. LBA48 tops out at about 2000GB per drive on 32-bit processors IIRC.

error in the article.

[rew]

The author of the article mis-interpreted Seagate's latency figure. Seagate means: "Average rotational latency". This can be calculated from: 60 seconds/minute / 7200 RPM / 2 = 0.00416 s = 4.16ms.

Oficially you should add in the controller overhead, and most likely the time to read a sector (it's unlikely they pass-through the sector: in theory you can start to send the sector to the host before you've read it completely, but this complicates things as when the CRC doesn't match, you have to cancel the data sent to the host!), but if you do the math, these are negligable compared to the 4.16 ms.

I don't expect anything "special" to happen in the "seek times" area. They will be within 10% from the slightly older drives. Either up to 10% better because they did find a way to improve seek times a bit. Or up to 10% worse because the higher density requires a longer settling time, but this is less likely than a small improvement.

Re:Why are we still moving heads back and forth?

[Detritus]

Even if you could fabricate the head assembly, you still have a major problem. Modern track densities require closed-loop head positioning. If you could shrink yourself to the size of the head gap, you would see the head constantly moving laterally to keep itself positioned over the track. At this scale, the platter is no longer an ideal rigid disk.

Re:Backup problem...

[donaldm]

Only a few PC owners seem to think about backups and then only after loosing their data. Even with a 1PB (not a typo) disk there will be people who won't backup. Now in business if you don't backup they have a very good chance of going bankrupt if they have a hard disk failure. It must be rembered that even mirrored or SAN disks can and do fail.

For home use a huge disk is mainly used for pawn, movies, games ....etc, so disk performance is not normally an issue, however when you are running a database you need to use RAID or a SAN to increase the speed of the (now virtual) disk. So 10 x 72GB disks in a raid array will outperform 1 x 720GB disk.

Backing up a business system is expensive and time consuming so currently tapes (eg: super DLT's .... etc) are used and even then tapes can fail for a variety of reasons. What is really needed is a replacement for tape and currently only the Holographic Versatile Disk (HVD) has the potential to do this with 300GB/disks to be available this year. Forget about CD, DVD, HD-DVD and Bluray these technologies have their own niche and will most likely work well within it.

Even with the potential of 1.6TB/disk (40MB/sec write) for HVD the increase in storage will still cause issues in the future until people learn to tidy up their messes and that I don't see happening anytime soon. The larger the available storage the more it will be filled up with what is most likely junk, although my idea of junk (or goodness) will most likely differ from others.

Re:Format this Red Hat!

[Alioth]

Eh? What are you wittering on about?

[alioth@ZenIV ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 8.2G 1.3G 6.5G 17% /
/dev/sda1 494M 52M 418M 11% /boot
none 1014M 0 1014M 0% /dev/shm
/dev/sda5 4.1G 57M 3.8G 2% /tmp
/dev/sda2 9.2G 3.8G 5.0G 43% /usr
/dev/sda7 9.8G 2.4G 7.0G 25% /var
/dev/md0 461G 182G 256G 42% /home
/dev/md1 1.1T 547G 499G 53% /archive
 
[alioth@ZenIV ~]$ grep md1 /etc/mtab
/dev/md1 /archive ext3 rw,noatime 0 0

See that there at the bottom? 1.1T. This is larger than 750GB. It is formatted ext3. The machine is running RedHat.

Mod parent up!

[pointbeing]

The higher your data density, the higher your transfer rate will be even if the RPM rate stays constant.

Outstanding.

Doesn't have anything really to do with latency, but I've seen several comments from folks who worship at the altar of rotational speed when the true factors that determine a hard drive's speed are aa combination of rotational speed, track-to-track latency and data density. You can spin an old 10mb drive at 200,000 rpm and it still won't transfer data faster than a modern hard drive.

As sector density increases so does data throughput for a given rotational speed. If all other things are equal when you double the sector per track density you *almost* double the drive's throughput. I say almost because in order to double throughput you'd have to cut seek times in half as well.

But - fast drives have dense platters, not just fast spindles.

3Com has good HW support in Linux

[spun]

Los Alamos National Labs uses 3Com SATA raid cards in their scientific compute clusters. The 9500 series is excellent, and very well supported in Linux. I've built several multi-terrabyte cluster heads for them. Sixteen 250GB drives in one 3U case, on two 8 channel SATA raid cards doing raid 5.

Yes, I did wear ear protection while configuring and testing the things.