3TB Hard Drive Round Up

MojoKid writes "When 3TB hard drives first arrived compatible motherboards with newer UEFI setup utilities weren't quite ready for prime time. However, with the latest Intel and AMD chipsets hitting the market, UEFI has become commonplace and compatibility with 3TB drives is no longer an issue... A detailed look at four of the latest 3TB drives to hit the market from Hitachi, Seagate, and Western Digital shows ... there are some distinct differences between them. Performance-wise, Seagate's Barracuda XT 3TB drive seems to be the current leader but other, slightly less expensive drives, come close."

Comments

750,000 hours MTBF.

[Kenja]

Seems the trend that as capacity increased so does failure rate. For comparison the older 1TB Seagates claim 1,200,000 hours.

Re:750,000 hours MTBF.

[Hatta]

If you bought 3 1TB seagate, you'd be 3x as likely to suffer a failure. So that's really more like a 400,000 hour MTBF for 3TB worth of space.

Re:750,000 hours MTBF.

[Anonymous Coward]

"Seems the trend that as capacity increased so does failure rate. For comparison the older 1TB Seagates claim 1,200,000 hours."

Same problem happens with flash as bits of data get smaller reliability becomes an issue.

Re:750,000 hours MTBF.

[Kenja]

But I would have bought four and put them in a DROBO style array. So no data loss.

Re:750,000 hours MTBF.

[Anonymous Coward]

(750 000 / 24) / 365.25 = 85.5578371 years

Whats the problem?

By then there'll be 1YB drives to back everything up on ;p

Re:750,000 hours MTBF.

[DigiShaman]

Unless you're using a Drobo to store backups, keeping your only source of data on a Drobo is not a backup. To be clear, RAID is *NOT* a backup. It's redundancy. There is a difference.

Re:750,000 hours MTBF.

[Anonymous Coward]

80 years ago there were 10^0 bytes stored.
Now there are 10^12
in 80 years time there will be 10^24.

This is exactly how this stuff works.

Re:750,000 hours MTBF.

[Anonymous Coward]

a backup is redundant information

Re:750,000 hours MTBF.

[Pino Grigio]

I've got 3 1TB Barracudas. Actually I can't remember the last time I had an HD failure, although I have noticed that heavy loading (through bit torrent, for example) does make them start to emit strange clunking noises after a while! But overall I would consider them a trusted brand because I've never had one fail, personally.

Re:750,000 hours MTBF.

[SimonTheSoundMan]

I break in to your house and steal your Drobo, then what?

Re:750,000 hours MTBF.

[Anonymous Coward]

(a->b) --/-> (b->a)

Re:750,000 hours MTBF.

[jareth-0205]

Unless you're using a Drobo to store backups, keeping your only source of data on a Drobo is not a backup. To be clear, RAID is *NOT* a backup. It's redundancy. There is a difference.

Not sure why you've changed the subject to bang on about backups... he was talking about protecting from hardware failures. Which is exactly what RAID does.

Re:750,000 hours MTBF.

[Anonymous Coward]

You really think your hard drive will last 750,000 hours without failing?

Re:750,000 hours MTBF.

[SimonTheSoundMan]

Total lie. Most HDD's will fail around 3 years, so ~26,000 hours.

Re:750,000 hours MTBF.

[TheRaven64]

Then he is in exactly the same situation as if you broke into his house and stole his 3TB disk, which is completely orthogonal to the MTBF.

Re:750,000 hours MTBF.

[Anonymous Coward]

My Drobo has gps anti-theft tracking. Your iphone has tracking. Steve Jobs locates you. You go to jail.

Re:750,000 hours MTBF.

[Anonymous Coward]

you get shot?

Re:750,000 hours MTBF.

[hesaigo999ca]

>Total lie
My hdd still running since 1997 would prove you wrong....although I do not have much on it as it is a small hdd (250gb),
it would still outlast any of the devices today......

Re:750,000 hours MTBF.

[Anonymous Coward]

I've got 1 1TB Barracuda. My last failure is NOW. I'm currently waiting for the RMA replacement so that I can hopefully rescue some of the data before the drive fails entirely.
I dont particularly trust any hard drive brand, so I still buy based on price per gig.

Re:750,000 hours MTBF.

[Mitchell314]

If you don't use it during that time, it will* :D

*(Though I do remember somebody saying that extreme amounts of time between use will actually cause harm to the disk the next time it's used)

Re:750,000 hours MTBF.

[ColdWetDog]

I've got 3 1TB Barracudas. Actually I can't remember the last time I had an HD failure, although I have noticed that heavy loading (through bit torrent, for example) does make them start to emit strange clunking noises after a while! But overall I would consider them a trusted brand because I've never had one fail, personally.

Those 'strange clunking noises' are actually hardware viruses chewing on the shell of the drive and trying to get out. Best to spray some Clorox mixed with WD-40 all over everything and let it sit for a while. That should quiet things down a bit.

Re:750,000 hours MTBF.

[trum4n]

RAID protects against hardware failures. It cannot protect you from idiocy. Backups can. I use RAID, it's faster. I don't worry about it.

Re:750,000 hours MTBF.

[certain death]

Wait...you have a 250 gb drive from 1997? I think there may be a typo in that comment...I thought the preview button was mandatory now!!

Re:750,000 hours MTBF.

[jovius]

I actually did quite thorough review of NAS/Backup boxes for home use and in the end decided to build one myself. Now I have a 4TB Ubuntu box with plenty of room to expand and connectivity and what's most important: total control of the system. The passively cooled mini-itx board and the case supports 6 sata III drives besides having eSata and USB 3.0, the OS launches from a small SSD. Raid is something that many people automatically implement even though it's not always necessary or convenient. I simply rsync the drives to mirror them. I'm not a filesystem guru, but ended up to have ZFS, which apparently has many great features. The file system loves memory though, I've seen it taking 6 gigabytes easily from time to time.

Re:750,000 hours MTBF.

[Anonymous Coward]

That's why instead of buying Caviars or F3s you instead buy enterprise drives: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&Description=western+digital+re4

Re:750,000 hours MTBF.

[Pino Grigio]

I'm very careful about things like that CWD :p.

Re:750,000 hours MTBF.

[wagnerrp]

You're using ZFS... with Ubuntu?

Re:750,000 hours MTBF.

[b0bby]

Just keep your receipt; Seagate is giving you a 5 year warranty on the 3TB drives.

I have lots of hard drives here which are 4+ years old, I have only had one fail in the past year. I'm sure the oldest drive that's still working here is 8+ years old, and there were lots more that just got cycled out.

Re:750,000 hours MTBF.

[Hatta]

You're using ZFS and manually managing backups with rsync? That's ass backwards.

Re:750,000 hours MTBF.

[jovius]

I first tried FreeNAS before installing Ubuntu, and ZFS was a natural choice (for the 2TB drives). I didn't want to use the SSD as a cache for ZFS so decided to install Ubuntu on it rather than having an unused HD. The SSD has the default Linux filesystem. I found a great ZFS driver, which doubled the disk to disk transfer rate from fuse-ZFS.

Re:750,000 hours MTBF.

[Waffle Iron]

(750 000 / 24) / 365.25 = 85.5578371 years

Whats the problem?

The problem is that HDD manufacturers don't tell you that all their MTBF ratings are actually specified in "dog hours".

Re:750,000 hours MTBF.

[Anonymous Coward]

I got a 5 year warranty on my Seagate 1.5TB drive, and I'm on my third replacement now, two years in. I don't really care if they'll replace it with an empty drive after jumping through their RMA hoops and shipping them the broken drive at my own expense. I want the damn thing to work in the first place. Is that too much to ask for?

Re:750,000 hours MTBF.

[Bryan3000000]

Pony up. I need to transition off of fuse-ZFS. Is it ZFS on Linux? I've been waiting forever for it to exit beta, but mostly just not having time to experiment.

Re:750,000 hours MTBF.

[jovius]

Yes it is (http://zfsonlinux.org/). I installed it from Darik Horn's PPA as instructed in the FAQ. I don't know how fast the disks should optimally be (100 MB/s reads from single disk, WD Caviar Green), but disk to disk rate peaks and goes a bit above 60 MB/s compared to 30 MB/s before. Average is somewhere a bit above 40 MB/s.

Re:750,000 hours MTBF.

[Anonymous Coward]

Why do you think rsync has to be implemented manually? A system with Rsync with hard links with cron is simple , easy and very effective. You can even use it to create backups the other machines on your network (Windows/Linux etc) on a schedule.

Re:750,000 hours MTBF.

[Anonymous Coward]

Hardly. I have at least 6 drives from the mid/late 90's, some that have over 7 *spinning years* on them, and all are going strong here in 2011.

Stop treating your drives like crap, and maybe you'll have better luck. I'm not saying drives don't die, just that it isn't nearly as grim as you say.

Re:750,000 hours MTBF.

[UnknowingFool]

Anecdotally I never had a recent Seagate that outlasted a WD or Hitachi drive. In my experience they were good HDDs until they bought out Maxtor then their quality went down.

Re:750,000 hours MTBF.

[jedidiah]

I keep on top of the SMART status of my drives and don't wait for them to implode before taking them off line.

While I haven't had any "failures" as such with my 1.5TB and larger Seagates, I have pre-emptively removed a few from active use before they could be a bother.

Re:750,000 hours MTBF.

[jedidiah]

The Seagate drive from my first PC lasted 7 years before I discarded.

Re:750,000 hours MTBF.

[jedidiah]

...or you could just buy twice as many drives and still spend less.

Re:750,000 hours MTBF.

[Anonymous Coward]

>Total lie
My hdd still running since 1997 would prove you wrong....although I do not have much on it as it is a small hdd (250gb),

I wonder if the time machine you used to get that 250gb disk in 1997 is still running too?

Re:750,000 hours MTBF.

[uncqual]

heavy loading (through bit torrent, for example)

It must be nice to have an OC-48 coming into your basement to drive those three drives to a "heavy load" condition via bit torrent.

Re:750,000 hours MTBF.

[jovius]

I understand ZFS is mostly for RAID's then? Most probably I'm not doing things as they should be done, but I like ZFS and originally thought of using FreeNAS, which recommends ZFS anyway. I'll probably check back to it when the new version matures a bit. I'm not after meticulous performance tweaking though. It's just great to have a back-up system rather than a single back-up drive (most of my data is practically triple secured).

Re:750,000 hours MTBF.

[dgatwood]

Not very well, though. From the folks I've worked with who have dealt with lots of RAID arrays, when one drive fails, it is more often than not caused by a design flaw rather than a manufacturing flaw, and since the drives read and write in lock step, odds are remarkably good that the next drive in the array will die before you finish rebuilding the RAID set. This tends to occur whether you're talking about a mechanical flaw (e.g. after n seeks, the head arm suffers metal fatigue) or an electronics flaw (e.g. after n hours of operations, the electrolytic capacitors have degraded to the point that they no longer filter power adequately, and the head preamp then releases its magic smoke).

This phenomenon also tends to occur when external causes result in the damage, e.g. the entire lot of hard drives was dropped during shipping and weakened some component, the RAID array was writing during an earthquake, the RAID array was writing during a momentary power sag, the RAID array was hit by lightning, etc.

Basically, the hard drive manufacturers have done a great job of nearly eliminating variation between one unit and another, so the only real opportunity for significant variations in life expectancy should be whatever happens to the drive between when it leaves the manufacturer's hands and when you stick it into the array.

For this reason, a good RAID array should contain no more than one of any single drive model by any single manufacturer, should under no circumstances contain multiple drives from the same manufacturing lot, and should be composed entirely of working pulls from randomly selected workstations that were installed at significantly different times, thus ensuring wildly different service hours on each drive in the array.

Unfortunately, almost nobody does this, and thus, the vast majority of RAID arrays are absolutely not a good substitute for having offline backup hardware, whether that is a pile of tapes, DVDs, BRDs, a clone of your RAID array that you only power up during the nightly backups, or whatever.

Re:750,000 hours MTBF.

[orange47]

.. 'or' it could be thermal recalibration: http://stason.org/TULARC/pc/pc_hardware_faq/3_14_What_is_Thermal_Recalibration.html
hard drives do get hotter with a lot of writing/reading. iirc, I noticed a difference of at least 5deg C.

Re:750,000 hours MTBF.

[hairyfeet]

Uhhh...why not just split the difference and save a ton o' cash? I bought a 1Tb EcoDrive for my OS a couple of months back, on sale for $39, and a 2Tb EcoDrive a couple of weeks ago, again on sale for $59. Last I checked those 3Tb drives were still pretty high and this lets me switch out the OS drive for another 2Tb down the road although frankly I think I may have hit my limit on usefulness. Even with every game I even slightly like I still have 1400Gb free on the 2Tb, and with a dual boot XP and Win 7 PLUS another partition for video editing my 3 partitions on the 1Tb have nearly 75% free each.

So I can see needing a 3Tb if you are doing a ton of video editing but for most folks I'd say the sweet spot is 2Tb or even 1Tb drives, especially if you catch them on sale. BTW if anyone is thinking about snatching a Samsung EcoDrive before they are all gone THEY ROCK HARD. you'd think by replacing a 7200RPM for a 5400RPM I'd take a speed hit but the fat cache on the EcoDrive (32Mb VS 8Mb for my Seagate 400Gb) jumped my benches from 92Mbps to nearly 120Mpbs. It is also quiet as a churchmouse and max temp is barely 85f, compared to nearly 120f on the Seagate. Well worth the money IMHO, truly sweet drives!

Re:750,000 hours MTBF.

[billcopc]

Even the 750k MTBF feels bogus. In my experience actual failure rate is just a hair under 3%, which works out to about 300k MTBF. Maybe they're quoting the MTBF of a drive still in its anti-static bag, sitting in the spares drawer :)

Try shoving 36 3TB drives in one of these: http://www.supermicro.com/products/chassis/4U/847/SC847E26-R1400LP.cfm and you'll appreciate MTBF in a whole new light. My approach is simple: I take the number of drives, times 3% annual failure, times the number of years I want to keep that box in operation. The result is how many spares I'll need. For the 36-drive box, I use 32 drives for the RAID + hot spares, and leave the remaining 4 as spun-down spares. That ensures at least 5 years of hassle-free operation. Add JBODs to the mix and you get an even smoother curve, as a 100-drive array is more deterministic in its failures due to the larger sample size.

For a single drive, well, failure rate becomes a lottery. MTBF won't help you here. If you buy a 3TB drive for your desktop, you should also get a 3TB external drive to back it up, and sync them regularly. Always assume one of them will die at the time you need it the most, and be prepared to deal with it gracefully. The odds of both failing at the same time are pretty slim, certainly slim enough for most residential users.

Re:750,000 hours MTBF.

[Hatta]

Yes, ZFS is so RAID centric that it has it's own designation RAID-Z.

Re:750,000 hours MTBF.

[Anonymous Coward]

Most HDD's will fail around 3 years, so ~26,000 hours.

Correction:
Most HDD's will die after around 2000 start-stop cycles, regardless of age.

Re:750,000 hours MTBF.

[wagnerrp]

Interesting. I hadn't realized any of the native implementations had progressed so far, and trying to run something like ZFS through FUSE just seems disastrous. I'll have to look into this. Right now, I've got several Gentoo systems booting off iSCSI JFS disks, served from cloned ZFS volumes on a FreeBSD server. It would be useful if the images were formatted with a filesystem the server could actually read.

Re:750,000 hours MTBF.

[Pino Grigio]

I told you my experience, then you have to go and be a dick about it with a comment such as the above.

Re:750,000 hours MTBF.

[Bryan3000000]

That is an improvement. I tend to attribute the slowdown compared to the 100MB/s to filesystem overhead. Particularly in my case b/c I'm generally writing over gigabit from OS X via a netatalk AFP share. But even as-is, I tend to get above 30MB/s to a single-disk ZFS pool on ZFSfuse. I would love to see that jump to 50-60MB/s, which I would have to consider best-case reading/writing over a single gigabit link from OS X from a single laptop HD.

I have seriously considered switching from Ubuntu to Fedora however, largely b/c of systemd and experimenting with their virtualization and cloud technologies. Perhaps virtualizing Nexenta community edition to see how it would perform.

Re:750,000 hours MTBF.

[Ex-MislTech]

First off as someone who has a Seagate manufacturing facility close by
you do not want to buy their drives. I'd buy Western Digital or some
company that doesn't use temp workers for their consumer drives.

Re:750,000 hours MTBF.

[Anonymous Coward]

What - he was a "dick" because he told you that you were wrong? You WERE wrong - no torrent is going to give your hard drive heavy loading, so you're spreading FUD, therefore he corrected you. And the reason you wrote something which is clearly incorrect is precisely because you're the sort of paranoid idiot who can't admit they're wrong, and therefore holds onto incorrect information, and spreads it around, and then gets all upset when somebody simply points out where you are wrong...

IDIOT.

Re:750,000 hours MTBF.

[Fjandr]

The redundant information is to protect against loss of your working set. It is operational data when on a RAID array.

A backup is a copy of data that is not a working set. Ergo, RAID is not a backup.

Re:750,000 hours MTBF.

[Pharmboy]

and since the drives read and write in lock step, odds are remarkably good that the next drive in the array will die before you finish rebuilding the RAID set.

Utter nonsense. If one drive failing caused the next to fail, then millions would not be using RAID as the defacto method of redundancy. I've had many, many RAID setups for many years (ie: every server and workstation for almost 20 years), and had the occasional drive failure. I've never had two drives fail in the same array. Ever. And that was with both hardware and software RAID setups. Drives fail due to manufacturing flaws, even minor ones that don't show up for a long time. You overstate the ability of manufacturers to create multiple products exactly the same. They may be built to the same minimum STANDARD, but that isn't the same as being IDENTICAL.

a good RAID array should contain no more than one of any single drive model by any single manufacturer

Sorry, but this is bullocks and if someone told you this, they were pulling your leg. This guarantees nothing, except that your array will likely perform like crap because they will all have different latency, as well as sustained and burst throughput. This would be most noticeable in a software RAID, and slow the whole system down. The entire purpose of a RAID is to use identical drives in size, performance and specifications so the entire array, regardless of RAID type, will seamlessly act like a single drive, while using the least amount of overhead.

Try a different subject matter, you are seriously missing some information about this one.

Re:750,000 hours MTBF.

[Pino Grigio]

That's interesting. Thanks for the info.

Re:750,000 hours MTBF.

[Anonymous Coward]

Seagate drives are f**king shit. nothing more, nothing less. Unreliable paperweights and I still wouldnt trust them.

Re:750,000 hours MTBF.

[Curate]

Could you expand on why you object to Seagate's use of temp workers? Is it for philosophical reasons, or do you think it impacts quality?

Re:750,000 hours MTBF.

[jovius]

The FreeNAS people recommend at least 6 Gigabytes of memory for a system of my size, and when I do a large copy (about 100 GB OSX Image) it actually takes that much and reaches the top speed. The CPU cores hit 100% (the board Asus E35M1-I Deluxe, with AMD Fusion). If you have a large setup the extra memory will likely contribute to the transfer rate. I checked out the other NAS OS's but I like Ubuntu for the versatility. It's probably possible to have yet another performance boost by having a more optimized OS, but I'm no really after that.

Re:750,000 hours MTBF.

[ifrag]

Huh... how fast is your network?

That 6 GB figure for RAM seems a bit excessive (although with cheap RAM prices, probably no big deal). I'm running a 4x1TB ZFS on OpenSolaris and it hits Gigabit Ethernet speed with 2 GB RAM (not actually sure it's even using all that).

Re:750,000 hours MTBF.

[repetty]

I don't give anyone my failed HD's... it's a privacy thing.

MTBF are fictitious figures. They mean nothing.

Hard drive warranties are irrelevant. They mean nothing.

Warranties do not imply quality. Seems like they might but... they don't.

My Seagates fail faithfully after around 30,000 hours. I track 'em so I know.

WD's fail... Hitachi's fail... they all fail if you use them long enough.

Working 8-year old hard drives can be the basis for an amusing anecdote, one of those "ain't that the dangest thing" sort of stories.

The company that made your 8-year old hard drive is no longer in business, even if their name is. They've changed. Their employees and policies have changed. Their strategic alliances have changed. Technology has changed.

You can share that story about the 8-year old hard drive with your grandkids one day, though.

Re:750,000 hours MTBF.

[jovius]

I was benchmarking internal disk to disk transfers, and the system really took a bit over 6 Gigabytes. The memory usage pattern was somewhat of interest, as it ramped up for some time until releasing, and the cycle was restarted. The default of ZFS seems to be that all of the system memory is used except 1GB: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Memory_and_Dynamic_Reconfiguration_Recommendations

From Freenas Hardware reqs: "The best way to get the most out of your FreeNAS hardware is to install as much RAM as possible. If your RAM is limited, consider using UFS until you can afford better hardware. ZFS typically requires a minimum of 6 GB of RAM in order to provide good performance; in practical terms (what you can actually install), this means that the minimum is really 8 GB. The more RAM, the better the performance, and the Forums provide anecdotal evidence from users on how much performance is gained by adding more RAM. For systems with large disk capacity (greater than 6 TB), a general rule of thumb is 1GB of RAM for every 1TB of storage. "

Re:750,000 hours MTBF.

[Anonymous Coward]

You may have more heat, vibration, or load than the "mean" case they use for MTBF.

Re:750,000 hours MTBF.

[silas_moeckel]

I hope you do not want any performance. Mixing drives even firmwares can send your iops through the floor. For a bulk storage that's reliable this is fine don't try and get any performance out of it.

Re:750,000 hours MTBF.

[rcw-home]

For a single drive, well, failure rate becomes a lottery.

You misspelled "single manufacturing batch of drives".

Re:750,000 hours MTBF.

[Anonymous Coward]

you don't need the receipt I believe, Seagate (or was it some other drive manufacturer) has a system where you can check how old your disk is using the serial number, works like a charm.

Re:750,000 hours MTBF.

[jovius]

Important note was left out from the FreenNAS Hardware reqs:

NOTE: by default, ZFS disables pre-fetching (caching) for systems containing less than 4 GB of usable RAM. Not using pre-fetching can really slow down performance. 4 GB of usable RAM is not the same thing as 4 GB of installed RAM as the operating system resides in RAM. This means that the practical pre-fetching threshhold is 6 GB, or 8 GB of installed RAM. You can still use ZFS with less RAM, but performance will be affected.

Re:750,000 hours MTBF.

[Anonymous Coward]

Total lie there were no 250Gb HD in 1997.

Re:750,000 hours MTBF.

[billcopc]

The problem is that a hard drive "batch" isn't really a batch at all, it's an entire production run from any particular facility. Typically, once you break into a new "batch", the drives have other differences like a cost-reduced controller or different platter density, that makes it unsuitable for integration with the existing array.

The most defining indicator I've seen for hard drives is simply its inception date. If you take a bunch of drives, start pounding them in a RAID simultaneously, they are a little more likely to fail in groups, e.g. if you hit a common defect that triggers after n power-on hours. If you mix new and nearly-new drives in an array, that's less likely to happen.

Re:750,000 hours MTBF.

[Pegasus]

I've never had two drives fail in the same array. Ever.

Wow, you must be one lucky storage admin. After having whole batches of drives fail within hours of eachother, I'm also assembling all my raids that hold even slightly important data strictly with different disks from different manufacturers. Afterall, having fast access to data is less important than having an access at all.

Re:750,000 hours MTBF.

[Anonymous Coward]

Most HDD's will fail around 3 years, so ~26,000 hours.

Correction:
Most HDD's will die after around 2000 start-stop cycles, regardless of age.

From what I've heard, ever since major operating systems adopted power savings techniques across the board, even desktop 3.5" HDDs have been engineered to withstand tens of thousands of start-stop cycles. (Laptop 2.5" HDDs always have been.)

Re:750,000 hours MTBF.

[MartinSchou]

Well, if Seagate is really using temp workers for their consumer HDDs, I suspect their read and write speeds would be horribly slow.

Not to mention possibly illegal?

Re:750,000 hours MTBF.

[dgatwood]

If one drive failing caused the next to fail

Reading comprehension FAIL. I did NOT say anything of the sort. I said that if you have ten nearly identical pieces of hardware and treat them in nearly identical ways, you'd have to be crazy to expect them to fail at significantly different times. Any claim to the contrary is an extraordinary claim that requires extraordinary proof.

The entire purpose of a RAID is to use identical drives in size, performance and specifications so the entire array, regardless of RAID type, will seamlessly act like a single drive, while using the least amount of overhead.

The entire purpose of a RAID? Hardly. The purpose of a RAID is to get better performance by increasing the number of drives that can send/receive data at the same. However, different people have different opinions about the tradeoff between reliability and performance. You clearly want that last little bit of cache performance, which is fine as long as you understand that by doing so, you essentially lose all of the hardware failure protection that RAID can provide.

As for me, I'd much prefer a mixed RAID set, with all the drive caches disabled entirely, and with a battery-backed-RAM-based cache on the RAID controller itself. That gives you basically the same benefits as the drive caches, but without most of the risks associated with the drive caches (data that never gets written out to disk due to a power failure, the inability to perform any sorts of useful RAM tests on the cache RAM, the inability to mix drives for better reliability, etc.).

Re:750,000 hours MTBF.

[dgatwood]

Yup. It's a tradeoff. Performance or robustness. If you want your RAID to provide significantly increased robustness, you have to compromise performance (and, in particular, cache performance).

You should be able to eliminate much of this difference by adding appropriate amounts of caching at the RAID controller level or in the computer itself, though latency for longer reads will suffer by some portion of one short-seek/settle period and one rotation because of the increased probability of one or more drives needing to read two or more tracks to perform the operation.

Either way, the point I was trying to make was not that everyone should build mixed RAID arrays, but rather that anyone who claims that RAID provides robustness in the event of a drive failure should understand that the things folks do to get the impressive performance are fundamentally contrary to what you'd have to do to get those robustness improvements, at least in practice.

Re:750,000 hours MTBF.

[LordLimecat]

I just dealt with a failed drive last night. The drive was a 26-year-old NEC D5124.

Hows THAT for TBF?

Re:750,000 hours MTBF.

[TrekkieGod]

For what it's worth, I've been running zfs under fuse for a while, and am extremely happy with it. It wasn't built for performance, I just wanted the snapshotting + raidz features, so I've never benchmarked it. That said, reliability has been good. I've had a drive fail on me, and rebuilding the array worked as advertised, no issues introduced from fuse.

Re:750,000 hours MTBF.

[rrohbeck]

That's the right way to do it you don't want to deal with field service.
And 3% sounds perfectly reasonable for the consumer channel remembering my hard drive days. You only get to 1 or 2% in a tightly controlled OEM environment with mature (aka obsolete) technology. That's why enterprise storage vendors are always 1 or 2 generations behind the bleeding edge. We're just now qualifying 2TB drives.

Re:750,000 hours MTBF.

[rcw-home]

the drives have other differences like a cost-reduced controller or different platter density, that makes it unsuitable for integration with the existing array.

I've mixed and matched hard drive vendors (usually intentionally) in RAID arrays for years; besides a little bit of performance, what am I missing? And if I need that little bit of performance, shouldn't I be short-stroking even more drives or using SSDs?

Re:750,000 hours MTBF.

[Anonymous Coward]

>If you buy a 3TB drive for your desktop, you should also get a 3TB external drive to back it up

Bad advice. Really out of date advice like 1960's. If you spend another 100% of your hardware cost, at least take advantage of it.

You should at least RAID them so that error detection/correction can occur at a BLOCK level not at a per file level. How do you know which is the good file if the two supposedly identical copies of the same file are different. What if BOTH of them are corrupted. ECC at the block level would at least try to piece the file together.

Given the 1/BER (Bit Error Rate typically 10^-14 range give or take) at the PHY level is the same order of magnitude as the drive size, can't be so sure if the data read back from the drive can be trusted without ECC. Drive cannot detect error all the way to the memory inside your PC...

Re:750,000 hours MTBF.

[Anonymous Coward]

RMA drives from all the manufacturers so far and none of them require receipts.

They have date code and serial numbers. It is not like Seagate makes a drive that is identical to Samsung that no one can tell them apart.

Re:750,000 hours MTBF.

[Anonymous Coward]

I read these same type of reviews on Newegg all of the time. People that claim they are a "Technical Level 5" and then post reviews and comments like yours that do not make sense.

Re:750,000 hours MTBF.

[Nethead]

You just need to run it in Landscape Mode.

Re:750,000 hours MTBF.

[dbIII]

I've never had two drives fail in the same array. Ever.

I've had some - 200GB Western Digital IDE drives in a poorly designed case in a room that should have had better cooling. Heat kills disks so the failing drive took a couple of adjacent drives with it. It was not an unexpected event, plans were already underway to get a new chassis and up to date copies of the files on those array were scattered all over the network wherever they would fit. I think I had two multiple disk failure events like that with that paticular overpriced piece of junk and over a few months the disks taken from that chassis died one by one.
That doesn't invalidate any of you points apart from pointing out that there are some instances where the failure of one drive may contribute to the failure of others as secondary damage. Cooling failures can still potentially take out entire arrays. Similtaneous failures of drives without any external cause due to a design fault is not something you'd expect to see outside of a manufacturers test lab.

Re:750,000 hours MTBF.

[CAIMLAS]

No promises, but I'm guessing this has something to do with the number of platters in the drive. A 3TB drive with 3 1TB platters is obviously going to have a lower MTBF because it has 3 times as many heads, spindles, etc. which can break or have failures.

The 1TB drive, on the other hand, has a single 1TB spindle.

Re:750,000 hours MTBF.

[dbIII]

e.g. after n seeks, the head arm suffers metal fatigue

Do you have a documented case or even rumour of this ever happening or is it just a guess thrown out to be an example?
It's a very low stress situation. There's also not much in the way of stress concentrations on the head arm and they are machined to a very smooth finish. Fatigue cracking happens when the stress concentrated at a point is higher than the ultimate tensile strength of the material - a crack opens up and relieves the stress and then when another stress event happens the crack grows. Even if the arm is made from a relatively low strength aluminium material it doesn't sound like a situation prone to fatigue unless it is a very bad design by somebody that isn't an engineer and doesn't take fatigue into account (eg. puts in sharp corners like the Liberty Ships or Constellation Airliner).

Re:750,000 hours MTBF.

[dbIII]

I don't give anyone my failed HD's... it's a privacy thing.

Good luck at getting anything meaningful out of large files that have been striped over a dozen disks.
It also depends on what they hold as to whether you care if anybody can read them or not. An acountants disk or their data area is one thing, information that is already available via goverment departments is another.

Re:750,000 hours MTBF.

[dgatwood]

Do you have a documented case or even rumour of this ever happening...

Not seeking causing it, per se, no. It's just an easy-to-explain example of the type of failure that would commonly plague either an entire product line or a long manufacturing run (e.g. if some hunk of metal in the wrong place caused some machine to stamp out a few thousand of a critical part with a thin spot).

That said, it's not too far from a documented cause of failure. IIRC, one of the major causes of Seagate drive failures about three or four years ago was the head literally breaking off of the head arm as the result of the park ramp design. As an aside, it only happened on the consumer drive models because the otherwise nearly identical server drives parked their heads on an unused track instead of using a park ramp.

Similarly, the head preamp failure is a common cause of failure, but I have no idea if it has ever been caused by electrolytic breakdown; that part was just another random example.

Other likely causes of failure are thermal breakdown of solder bumps inside silicon chips, thermally induced electrolyte breakdown in capacitors leading to premature failure... there's a long list, a fair number of which tend to happen to all drives from a particular lot after the same amount of use (where use could be defined as seeks, parks, spin-ups/spin-downs, powered-on hours, or various other metrics).

I've read a lot about drive failures over the years, mostly as a result of having had so many of them. I'm looking forward to the day when SSDs are cheap enough that I can buy a few TB for under $200. At least their failure modes are usually fixable by reflow oven.

Re:750,000 hours MTBF.

[toddestan]

The problem with raiding them is that is that now you're only really protected against hardware failure. What if a power surge takes out the computer, or virus wipes out your files, or a thief steals the computer? Now all your data is gone. If you're only going to buy two drives, you're best off getting one of them external, syncing them regularly, and storing the external away from the PC.

Of course, hard drives now are so ridiculously cheap that I just do both - buy three, raid two of them, put the third in an external enclosure.

Re:750,000 hours MTBF.

[hplus]

However, uploading different torrents to lots of peers can lead to lots of randomish reads from all over the disk. Sounds like heavy usage to me.

Re:750,000 hours MTBF.

[dbIII]

Do you have anything on that head failure that mentions whether it is a simple fracture or fatigue? The first five pages on google for "hard drive fatigue" or "hard drive metal fatigue" do not produce anything useful. I've heard of and seen fatigue in a lot of places (I used to do component failure analysis mainly in the electricity industry) but it does sound a bit odd in something like a hard drive head arm unless there was a paticularly stupid design flaw.

Re:750,000 hours MTBF.

[Anonymous Coward]

>Total lie
My hdd still running since 1997 would prove you wrong....although I do not have much on it as it is a small hdd (250gb),
it would still outlast any of the devices today......

I question this... In 1999/2000 I bought a 60GB IBM Deskstar for $250... I don't think they had 250GB drive out that early.

Re:750,000 hours MTBF.

[drsmithy]

Unfortunately, almost nobody does this, and thus, the vast majority of RAID arrays are absolutely not a good substitute for having offline backup hardware [...]

*No* RAID array is a substitute for having an offline backup, because the purpose of RAID is data availability, not data backup.

Re:750,000 hours MTBF.

[drsmithy]

The entire purpose of a RAID? Hardly. The purpose of a RAID is to get better performance by increasing the number of drives that can send/receive data at the same.

The primary purpose of RAID is data availability. Higher levels of throughput are a nice side-effect.

Re:750,000 hours MTBF.

[LostMyBeaver]

First of all, there are multiple types of RAID. There is mirroring and there is striping with parity with regards to ensuring that the R in raid is not meaningless.

Everyone knows for reasons of pure logic that having two identical mirrors are the best minimal solution. This means that you have at least one functioning copy at all times. Then you can remirror to a new set of devices when a failure in one copy occurs.

There is however a problem. Even in the best RAID enclosures, the close proximity of the drives tends to make the drives fail relative to one another. The likelihood that the two drives neighboring a failed drive (physically) being produced in consecutively in the same batch or being of the precise same design is great. Therefore, for truly important data, it is common sense to have multiple levels of redundancy.

To achieve multiple levels of redundancy, there are several options. The "best" is three or more way mirroring (with at least one pair of mirrors offsite). The next best is to implement parity and mirroring. Therefore you have two identical RAID 5s. My personal favorite which optimizes cost vs. reliability is RAID 6 (double parity) plus spare. In addition, by monitoring the number of spare sectors on the drive (all drives have spare sectors for remapping bad sectors), when the number of spare sectors drops below a certain level for a given drive, the drive would immediately mirror to a spare and an alarm would be generated for the spare the be replaced. In addition to this, using rsync or similar to mirror to an offsite location is a must.

The goal is.. NEVER EVER EVER lose redundancy. When you have one copy left, you have one point of failure.

The important thing to remember here isn't the quality of the drives involved. The important thing to remember is that all drives fail. Screw the MTBF ratings, they're utter rubbish since that's the duration of the expected life of a drive that doesn't fail. The reality on the other hand is that drives fail and you SHOULD NEVER EVER EVER trust the reliability of a drive, file-system or subsystem.

To bitch at you for your rubbish... your comment " then millions would not be using RAID as the defacto method of redundancy" is just nonsense. RAID is the defacto standard because it's relatively easy, cheap and most importantly... for the most part, there are no other alternatives. The best I've seen so far was Microsoft's attempt with their Windows Home Server files system which was removed from the latest version. It was great... it was wasteful as it required two copies of everything, but it had less points of failure than any other RAID system I've encountered. It was genius, too bad they didn't follow through with it.

Re:750,000 hours MTBF.

[silas_moeckel]

I would still not agree with you statement that a bunch of drives from various manufactures is more robust. I've seen the odd bad batch but never had a problem and I take care of several thousand drives in raid for over a decade. Cache will not cover the issues created unless your lightly loaded.

Re:750,000 hours MTBF.

[dgatwood]

You probably won't be able to find that sort of information. The people who repair dead drives tell what they saw, but they aren't metallurgists and have no good reason to do in-depth analysis of that sort. The people who have reason to do that type of analysis work for the manufacturer, and aren't going to publish their results.

That said, the head was at least ostensibly designed to travel up the head ramp, as it did so every time it parks, and the failure happened after a year or two of parking dozens of times per day whenever the drive spun down. A part that breaks suddenly on what was probably the ten-thousandth time you do something strongly suggests that the metal was getting weaker over time. It's not like we're talking about an insanely hard impact... though if it were caused by the emergency park mechanism, I could maybe see it being a simple fracture.

For folks who don't know what I mean by emergency park, many computers have drop sensors either in them or on the motherboard. Either the drive's controller detects when the device is falling or the OS does and sends a special SATA command. Either way, the drive slams the head arm over onto the park ramp as quickly as it can. I would assume that this is just moving at the drive's maximum seek speed, and thus is probably comparable to the speed of a normal park, but it might not be, in which case there could be a difference in the amount of force applied sufficient to cause a fracture without metal fatigue. I don't know enough about the mechanisms to say either way, and the answer could very well be drive-specific.

Re:750,000 hours MTBF.

[hesaigo999ca]

You are right, it is more like 2000 when I bought it.....but still lasted 12 years ....much longer then the allotted 5 years previously posted

Re:750,000 hours MTBF.

[dgatwood]

*shrugs*

Most definitions of data availability include a certain level of performance as part of the definition. If you don't need the performance boost, you don't need a RAID, unless it's RAID 0 (for increased capacity) or RAID 1 (for a slight robustness increase, assuming the bugginess of the cheap RAID controller on your motherboard doesn't completely negate that benefit).

Either way, I've said it before, and I'll say it again. Please, please put high capacity flash-based SSDs on the market, even if they cost a small fortune. The cost will drop over time; the fact that you can't buy a drive at any price with the capacity that you need, however, means that economies of scale can't fully kick in. Right now, the capacities meet only low-end users' needs. Those folks usually won't spend the money to upgrade to SSD in the first place, and thus won't drive volume up and prices down. Companies need to go ahead and bite the bullet, putting one and two terabyte laptop drives out on the market today. Not that many people will buy them, but a lot more people will be interested in choosing flash drives at a premium if that premium doesn't also come with a mandatory factor of 2-4 drop in capacity, depending on manufacturer.

Re:750,000 hours MTBF.

[Anonymous Coward]

You are right, it is more like 2000 when I bought it.....

Really? What's the make and model?

AFAIK the first 250GB drives appeared in 2002. Still a good lifetime for a drive, though.

Re:750,000 hours MTBF.

[Skal Tura]

Rather get similar drives from different stores and separate dates.

For example buy 20 drives today from 4 different shops, wait 2 weeks and buy the next 20. You will likely get different manufacturing batches that way, especially if you use both popular and not so popular stores, ie. shelf time of the drives is different.

Or always keep couple drives from older batch, ie. buy 10, only use 2 from that batch, and 2 each from 4 earlier batches :)

Most likely cause for drives to fail that close to each other is shipping mishandling, ie. the courier dropped the box from top shelf or something like that.

Re:750,000 hours MTBF.

[Skal Tura]

RAID0 also gives you increased performance, not just capacity.

Re:750,000 hours MTBF.

[Skal Tura]

Linux software RAID10 gives both of these, performance and redundancy. It offers as good performance as RAID0 but also the redundancy of RAID1. The software RAID works differently, and sensibly, versus the hardware based variants.

Soft raid first spliced the drives into tiny chunks, RAID1 them and then those are RAID0'd.
AND you can do this with only 2 drives, vs. HW based needs atleast 4.

HW based tends to give about N/2 performance even at best (cheap HP SmartArrays way less), and SW gives about N*0.9, in terms of absolute IOPS and throughput.

Also if you appreciate performance and use HP servers, only either use entry level (max 4 drives) or maybe the ultra high end. Beyond entry level they are defective by design for most part, ie. using a single SATA lane for 12 drives!?!?!? so for more than 4 drives, you need to configure the HW yourself, and make sure there is enough lanes being used.
I've tried HP 2drive, 4drive, 6drive and 12drive versions, best performance is on 4 drive, then 6 drive, 2 drive and 12drive. Yes, 12 drive was the slowest of them all.
Also never ever use HP "Enterprise" HDDs, they are one of the slowest HDDs i've seen to exist. They are some cheap consumer drives with relabeling and firmware which limits usage only to HP servers. 500Gb HDDs were atleast good for their size being Seagate Barracuda, but 1Tb, 2Tb are terribly slow. WD Blacks are multiple times faster, and handles heavy concurrency way more graciously, where as the "HP Enterprise" HDDs tend to cause whole node go down after threshold of concurrency is reached being so slow at that point SSH connections timeout etc., WD Blacks just makes resetting whatever sucking the IO throughput a bit slow process or we simply haven't reached that threshold yet despite best attempts :)

Re:750,000 hours MTBF.

[unencode200x]

Citations please.

Re:750,000 hours MTBF.

[unencode200x]

What did you replace it with?

Let me know

[Anonymous Coward]

When I can buy a 3TB SSD.

Re:Let me know

[jtownatpunk.net]

Right now if you've got the $$$. Don't expect to find it at Newegg, tho.

Why the comment on the capacity

[beelsebob]

For every drive they comment that the drives have a 2.72TB capacity reported in windows. Why is this surprising them so much? Everyone knows that Windows misreports TiB as TB. Given that all these drives are advertised as 3TB, and 3TB is equal to 2.728TiB it's hardly surprising the capacity that windows reports, is it?

Re:Why the comment on the capacity

[Anonymous Coward]

The reviewer is an idiot and thinks that formatting takes away that "extra" 0.28 TB from each drive. Common misconception among non-computer people, inexcusable in a tech reviewer.

Re:Why the comment on the capacity

[Anonymous Coward]

Yea, back when we had 1GB drives this was stupid but I guess an acceptable misunderstanding. Now it's just ridiculous. Does this guy actually think that there's 300GB worth of "formatting" on that drive.

Re:Why the comment on the capacity

[Pino Grigio]

I'm a computer person, and I thought that this was the case. Although I am a Software Developer and drives are hardware, so you can't have expected me to know this.

Re:Why the comment on the capacity

[SimonTheSoundMan]

Also do not miss the fact the drives have throughput topping 160TB per second. These drives are fast. o_O

http://hothardware.com/articleimages/Item1712/3tb_roundup_atto_read.png

Re:Why the comment on the capacity

[beelsebob]

160GB/s, but yeh, still rather off the chart ;)

Re:Why the comment on the capacity

[Anonymous Coward]

Because most people think the attempt to change the accepted definition of terabyte is retarded. Rather like Slashdot's posting interface.

This comment will not be saved until you click the Submit button below.You must wait a little bit before using this resource; please try again later.

Re:Why the comment on the capacity

[beelsebob]

The accepted definition of tera being the one in the SI unit scale that's been used for way longer than computers have existed? There's no change here, just many OSes have an age old bug. Most linux distros, and Mac OS have fixed it now, windows hasn't.

Just for reference, a quick history lesson. The bug was introduced back in the days when 1) CPUs ran at a few kilohertz (that's 1000 hertz, not 1024 hertz, just in case that wasn't clear); 2) division was not an operation available on said CPUs, so it had to be done with software and would take a few hundred cycles; 3) Most of these systems had at most a megabyte of storage; 4) said machines weighed several kilograms (that's 1000 grammes, just to be clear, and 0.001 megagrams). What was provided on these CPUs was a right shift operation, which typically took only 1 clock cycle to complete.

Some clever software engineers noticed that a right shift by 10 from the byte size got "close enough" to the correct size of a file in kilobytes. They acknowledged that it was a bug, but were happy to let it slide, because it was so close that it didn't matter, and it meant that if you were displaying a directory with 20 files in it, you spend 20 clock cycles computing the size to display, instead of 2000 (getting on for 0.2 seconds).

On the hard drives that they were dealing with where files were never more than a few kilobytes they never displayed a significant error. We now do display significant errors (of 300GB or more), and we now do have sufficient clock cycles to do divisions. Because of that, many OS vendors are fixing this age old bug.

Re:Why the comment on the capacity

[Grishnakh]

Because most people think the attempt to change the accepted definition of terabyte is retarded. Rather like Slashdot's posting interface.

This comment will not be saved until you click the Submit button below.You must wait a little bit before using this resource; please try again later.

The time-delay isn't that bad. What's really retarded is how every time you click inside the comment window, instead of simply placing the cursor where you clicked, it has to unnest another level of comments above. It's impossible to place the cursor with the mouse until all the levels of nesting are opened. I've never seen anything more stupid on a website in my life. Why does Slashdot do this?

Re:Why the comment on the capacity

[Anonymous Coward]

Uh, yeah... that's bullshit... I'm going to have to go with 150MB/s.

Re:Why the comment on the capacity

[wagnerrp]

You never opened the file properties in Explorer and wondered how 4.92GB could equal 5,284,212,740 bytes?

Re:Why the comment on the capacity

[Anonymous Coward]

160TB/sec is awesome! That's like 5000 Bluray DVDs per second!

Re:Why the comment on the capacity

[kimvette]

Everyone knows that Windows misreports TiB as TB.

Uh, no; "everyone*" knows that hard drive manufacturers, computer manufacturers, and resellers misrepresent TiB as TB, and in the rare cases they do disclose it in advertising or on the outside packaging, it is in 3- or 4-point fine print in a low-contrast color and written in a very technical manner that may as well come across as greek to a nontechnical person, or will refer the user to a web site.

Windows reports the traditionally-accepted units to the end user* accurately and consistently. OS X threw a wrench into the works by showing capacities in base 10, which only confuses the user by throwing away the standard in effort to be more intuitive, except then the capacity appears to be different than in other systems. What would the correct solution be? For everyone (manufacturers, resellers, Microsoft, Apple, Linux vendors, etc.) to use KiB, KB, MB, MiB, GB, GiB, TiB, TB correctly and consistently, so there is truth in advertising and in daily use.

* "everyone" != everyone

small

Re:Why the comment on the capacity

[wagnerrp]

I just refuse to use words like tebibibibyte that I can't pronounce without sounding like I have a speech impediment.

Re:Why the comment on the capacity

[kimvette]

I'm a computer person, and I thought that this was the case. Although I am a Software Developer and drives are hardware, so you can't have expected me to know this.

I would expect you to know how software works and how computers count vs. how people count. This is especially true when the subject of "what is a kilobyte" is discussed in the very first introductory computer classes one would take.

Re:Why the comment on the capacity

[J-1000]

According to Google unit conversion, 1 mebibyte = 1 megabyte, and both equal 1024 kilobytes each. Can someone please explain?

Re:Why the comment on the capacity

[Pino Grigio]

Oh, I do know the difference. It's just never consistently presented either in marketing literature or in user interfaces.

Re:Why the comment on the capacity

[beelsebob]

Uh, no; "everyone*" knows that hard drive manufacturers, computer manufacturers, and resellers misrepresent TiB as TB

They do? Those hard drives have a label on them saying 3TB, and indeed store 3,000,000,000,000 bytes, I don't see any misrepresentation there, given that the IEEE, ISO and SI standards all agree that kilo means 10^3, mega means 10^6, giga means 10^9 and tera means 10^12.

Windows reports the traditionally-accepted units to the end user* accurately and consistently.

What percentage of end users do you think are involved in the computer industry and know that some software engineer years ago knew right shift 10 was more efficient than divide by 1000? What percentage do you think know the every day SI unit scale? You may be living in a fantasy land where kilo, mega, giga and tera don't have their traditionally accepted meanings, the majority of the population are not.

Re:Why the comment on the capacity

[beelsebob]

What would the correct solution be? For everyone (manufacturers, resellers, Microsoft, Apple, Linux vendors, etc.) to use KiB, KB, MB, MiB, GB, GiB, TiB, TB correctly and consistently

Sorry to reply again–but this would indeed be the solution. Apple, linux vendors and hard drive makers are already using them correctly (and consistently). Microsoft is not, they need to catch up.

Re:Why the comment on the capacity

[beelsebob]

Google is getting it wrong. 1 Mega byte is equal to 1000 kilo bytes, which is equal to 1000000 bytes. 1 Mebi byte is equal to 1024 kibi bytes, which is equal to 1048576 bytes. These are agreed standards by the IEEE, ISO and IEC.

http://en.wikipedia.org/wiki/Mebibyte

Re:Why the comment on the capacity

[Anonymous Coward]

Dude, that ship has sailed. MiB, GiB, TiB have failed in the marketplace of ideas. Let it go.

Re:Why the comment on the capacity

[ColdWetDog]

I say print 'em all. Let God sort it out.

Re:Why the comment on the capacity

[ColdWetDog]

Way to complex.

For us American consumers, I would suggest

Small
Medium
Large
XXL
XXXL
Oprah Winfrey

None of this mathy stuff.

Re:Why the comment on the capacity

[NatasRevol]

You have to plan for the future.

What's beyond Oprah Winfrey? And what happens if she shrinks? Is that data loss? Is it recoverable or reusable?

Re:Why the comment on the capacity

[Anonymous Coward]

None of that English stuff either, it seems.
 
Doesn't it suck that just about the time you feel the need to mouth off about others being fools you prove yourself among their number?
 
Next time try to proof read and if you still don't know what I'm talking about try taking up 4th grade English.

Re:Why the comment on the capacity

[jedidiah]

Back when I was in school, the propaganda was always that SI units were better because they made more sense in terms of computation being simple base 10 things rather than being halves and thirds and whatnot. SI Units weren't meant to be some sort of alternate regal decree.

All of your droning on is essentially to declare that the new way of doing things is just another form of regal decree.

Forget about whether or not the units make sense, or are useful, or are convenient.

Just enforce the regal decree.

Yeah. All of the SI propaganda is just BS like any other propaganda.

Re:Why the comment on the capacity

[Luyseyal]

OMG, what will we do if the Library of Congress burns down! Or -- traveling backward in time -- all the gold transmutes!

-l

Re:Why the comment on the capacity

[jedidiah]

Binary Gigabyte would have been so nice and descriptive and simple and would have not looked so goofy that no one would want to ever use it.

Of course it was also far to obvious and simple. The beaurocrats that like to try and control these things can't have simple and obvious. It would make far too much sense and lessen the need for more beaurocrats.

Re:Why the comment on the capacity

[rworne]

She shrunk once before during the "Oprah Diet".

Somehow we all survived that. Later, she seemed to recover all the loss just fine... and then some.

Re:Why the comment on the capacity

[Anonymous Coward]

Where I came from, a kilometer was 1,000 meters. A kiloton was 1,000 tons. A kilogram was 1,000 grams and a kilobyte was 1024 bytes. A Megabyte was 1024 kilobytes. A Gigabyte was 1024 megabytes and a Terabyte was 1024 Gigabytes.

The display manufacturers got a slap many years ago, for advertising their displays as being bigger than the actual viewable area. What they didn't get to do, was invent some poncy new name for an inch, saying "Ah, but when we say 17 inches it's actually 17 kiki-inches which is 16 viewable inches..."

It's about time drive manufacturers got the same slap, and started advertising the real capacity of their drives. Sorry, but a Terabyte is NOT a trillion bytes. It's 1,099,511,627,776 bytes. You can call it a Tibibyte if that's what floats your boat. I just want a drive with 8,796,093,022,208 (after formatting overheads) BITS on it, I give a fuck what YOU call it as far as I'm concerned, THAT'S a 1TB drive. The first drive manufacturer that makes one of those, gets my business for life.

So, fuck off with your tibibyte shite and semantics. Why do we put up with this crap? Because some twat somewhere got confused between a metric kilo and a "binary" (for want of a better definition) kilo and decided we couldn't both use the same prefix?

Is "down" a direction, a mood, or the feathers off a duck's arse? How many thousands of other examples are there of words with more than one meaning? Have our teachings of science and language become so pathetic that we need a new prefix because we've become so dumb that we can't tell when it's appropriate for a kilo to be a 1,000 or 1,024?

I suppose you'd be happy if memory manufacturers started pulling the same stunt? "Oh, you wanted a 3Gibibyte chip? Well why didn't you say so, we thought when you said 3GB you meant 3 billion bytes, that's why your 3GB RAM is actually only ... 2.79 GiB"

If I ever felt the need to explain myself when I say kilo-anything to a fellow engineer and have him not understand, by the mere context, whether I mean 1,000 or 1,024 will be the day I jump off a cliff, because the scientific world will have got too stupid for me to bear.

Re:Why the comment on the capacity

[Anonymous Coward]

I'm pretty sure Kibibytes is something I feed my dog.

Re:Why the comment on the capacity

[Jah-Wren Ryel]

Why does Slashdot do this?

Because the guys who did the last redesign thought that using javascript was a good idea but weren't experienced enough to realize adding complexity adds bugs.
Turn off javascript and you won't have that problem. At slashdot, if it works without javascript then it works better without javascript.

Re:Why the comment on the capacity

[wagnerrp]

Isn't that Kibibits?

Re:Why the comment on the capacity

[blackicye]

160GB/s, but yeh, still rather off the chart ;)

160MB/s? ;)

Re:Why the comment on the capacity

[Anonymous Coward]

Thank you for illustrating the point - that there are people in the world who think it was a "mistake", that they were "wrong".

So the memory manufacturers have also got it "wrong"? Funny how everybody EXCEPT drive manufacturers accept a DATA "kilo" to be 2^10, not 10^3.

The computer guys didn't get it wrong, any more than the manufacturer of my fucking duvet didn't expect me to be confused as to whether it was depressed or filled with duck feathers when they said it was down. It's the pedants who've got their panties in a knot...

Re:Why the comment on the capacity

[Anonymous Coward]

You're the idiot railing against "inventing some poncy new name for an inch," while defending the guys who invented a poncy new definition for "kilo."

So the memory manufacturers have also got it "wrong"?

YES. They followed the inconsistent convention that "kilo" = 1024. Hard drive manufacturers didn't Ever since hard drives were invented, capacity was measured in kilo=1000, mega=1000^2, etc.

Re:Why the comment on the capacity

[Shadow99_1]

They can say whatever they want, but even today I'd never even heard of a 'mebibyte' and I have both a degree in comp sci and I've been in IT for over a decade. In fact I'm currently working for a college whose comp sci program doesn't once mention medbibytes anywhere. You ranting about how 'MB' doesn't mean what most of the world was taught seems to mean a whole lot of nothing.

Personally 'way back' in 1996 when I went to college mebibytes didn't exist and we were taught 1 KB (kilobytes) = 1024 bytes. Everything else works off of that. That said I don't belong to the IEEE, so maybe they sent out a newsletter to 'update the world' for their members, but it hasn't done any good.

Re:Why the comment on the capacity

[Anonymous Coward]

You know what's funny? If you'd been arguing about this back in the days when they came up with "kilobyte" you would probably argue against it for all the same reasons.

"Why should bits and bytes in memory be counted differently than in networks and on tape/disk?"

"Where I came from, a kilometer was 1,000 meters. A kiloton was 1,000 tons. A kilogram was 1,000 grams and a kilobyte was 1000 bytes."

"Sorry, but a Terabyte is NOT 1,099,511,627,776 bytes. It's a trillion bytes."

"Have our teachings of science and language become so pathetic that we need to change the meaning of a prefix instead of inventing a new one because we've become so dumb that we can't tell 1,000 doesn't equal 1,024?"

Re:Why the comment on the capacity

[Grishnakh]

Turn off javascript and you won't have that problem. At slashdot, if it works without javascript then it works better without javascript.

Holy crap, is this 1997 or something? I can't even remember the last time I had to even consider turning off javascript for a website.

Re:Why the comment on the capacity

[Anonymous Coward]

omg 160MB/s. It's not lost in space yet...

Re:Why the comment on the capacity

[Jah-Wren Ryel]

This is 2011 - a time when deciding to turn javascript ON is now the question.

Re:Why the comment on the capacity

[flonker]

I'm sorry. You're wrong.

1K = 1024 bytes, because of bits for memory addressing and pins and whatnot. It started with memory. It had nothing to do with shift operations. Further, changing KB from 1024 to 1000 increases inaccuracy, as you will never which standard someone is referring to.

https://secure.wikimedia.org/wikipedia/en/wiki/Binary_prefix

Re:Why the comment on the capacity

[Anonymous Coward]

Accept one detail everyone keeps missing, the unit "byte" is not an SI base unit. That would be like saying a GG (gigagallon) is 10^9 gallons, while we could define it to be that, we could also define it to be 2^30 gallons. Why do people insist on enforcing the SI prefix values on non SI units?

Re:Why the comment on the capacity

[toddestan]

Actually, convention was for storage devices kilo meant 1024, mega was 1024*1024, etc. This was a bend of the rules, but as "byte" is still not a SI unit (unlike, say, "Hertz"), people kind of let it slide. Later in the game, the hard drive manufacturers realized that they could use the other definition of mega to make their hard drives look larger than they really are by intentionally confusing people, and the rest is history.

Also, Linux and Mac still have your so-called "bug". If you don't believe me, ask either OS how much ram is available.

Re:Why the comment on the capacity

[Anonymous Coward]

Actually, convention was for storage devices kilo meant 1024, mega was 1024*1024, etc.
...

Later in the game, the hard drive manufacturers realized that they could use the other definition of mega to make their hard drives look larger than they really are by intentionally confusing people, and the rest is history.

This isn't actually true - hard disk manufacturers have always used k=1000 in their specs. Some floppy formats used 1024, others used 1024*1000, but the story that hard drive manufacturers changed their system to make the disk seem larger is a myth. If you can find an example of a hard drive manufacturer switching their method of calculating capacity, I'd like to see it because it will settle a bet with a friend of mine.

Re:Why the comment on the capacity

[Anonymous Coward]

For every drive they comment that the drives have a 2.72TB capacity reported in windows. Why is this surprising them so much? Everyone knows that Windows misreports TiB as TB. Given that all these drives are advertised as 3TB, and 3TB is equal to 2.728TiB it's hardly surprising the capacity that windows reports, is it?

No, everyone knows that a few dickheads insist on trying to push this i-notation bullshit which directly contradicts established industry usage. Windows reports TB as a power of 2, the companies selling the drives intentionally use base 10 for marketing purposes, if you look at their actual specs they will report them also as a power of 2.
If you're just going to make up a new type of notation then use it for base 10 instead of trying to co-opt the use of TB which STILL is assumed to mean base 2 by anyone who actually has their head outside their anus.

Re:Why the comment on the capacity

[Anonymous Coward]

These are agreed standards by the IEEE, ISO and IEC.

Citation needed. Your wikipedia link does not contain one, and nobody uses the Justin Bieber notation other than a few self-righteous assholes because it makes no fucking sense to measure a binary value in base 10. I'll also note that your precious Wiki also claims on it's page about "kilo" that "2^10 = 10^3" which is news to me.

Base Ten:
1 kilo = 10 ^ 3 (1,000)
1 mega = 10^6 (1,000,000)
1 giga = 10^ 9 (1,000,000,000)

Base Two:
1 kilo = 2^10 (1,024)
1 mega = 2^20 (1,048,576)
1 giga = 2^30 (1,073,741,824)

One byte is 2^8 bits, and bits is what we're actually measuring when we say bytes, because that's the basis for how much information is stored.
So if we use your Bieber system, we see that while 1 kilobyte = 1,000 bytes, it's 8,000 bits NOT 10,000 bits as one would assume by the standard rules, so in order for your system to make ANY sense at all we have to re-define a "byte" as 10 bits, not eight. And that is why nobody in their right mind actually uses that bullshit system 10 years after it was "adopted".

Re:Why the comment on the capacity

[beelsebob]

People insist on using SI prefixes consistently everywhere, because SI units and SI prefixes are different concepts, and because SI prefixs have a defined, consistent meaning.

Note – while you (incorrectly) addressed the SI issue, the IEEE, ISO and IEC *all* define the scales the same way, and all in the context of usage on bytes. The only exception here is that the IEEE says MB can be used to mean 2^20 bytes *in the context of RAM*.

Re:Why the comment on the capacity

[cynyr]

Hmm i wonder how i would describe 4500000 miles? thats not a nice number. but 450k miles isn't technically correct either.

Re:Why the comment on the capacity

[unencode200x]

Citation please, I've never heard this explanation.

Re:Why the comment on the capacity

[WhatAreYouDoingHere]

Hmm i wonder how i would describe 4500000 miles? thats not a nice number. but 450k miles isn't technically correct either.

I personally would call it "four and a half million miles" - not some number of megamiles or kilomiles.

7200 RPM data drives

[89cents]

Instead of paying $179 for a 3TB 7200 TB drive, it makes more sense to pay $129 for a 3TB 5400 RPM drive such as this Hitachi:

http://www.newegg.com/Product/Product.aspx?Item=N82E16822145493

and then add a small SSD with the savings for the OS/apps. The new BIOS/chipsets even allow you to combine them so that the SSD is used as a large cache drive.

Re:7200 RPM data drives

[akirapill]

The speed of high capacity drives can matter a great deal depending on what the system is used for, and read/write speed is not just important for applications and the OS. Ask anyone who does realtime uncompressed video or multi-track audio recording.

Re:7200 RPM data drives

[BobNET]

If they're doing realtime video or multitrack audio, then they can probably afford the faster drive.

Re:7200 RPM data drives

[realityimpaired]

The speed of high capacity drives can matter a great deal depending on what the system is used for, and read/write speed is not just important for applications and the OS. Ask anyone who does realtime uncompressed video or multi-track audio recording.

Yes, but.... as the capacity of a platter increases without increasing the size, the rpm needed to obtain a set transfer rate goes down. It's basic math... when the bit density increases, the read head has to cover less area to pick up the same number of bits. That's not to say that a 7200rpm 3TB drive will not be faster than a 5400rpm 3TB drive, but it does mean that the difference between the two won't be as significant as a 7200rpm 80GB drive versus a 5400rpm 80GB drive, as the transfer will run into other bottlenecks first.

Just check out the reviews for similar cases... the 1TB WD Scorpio Blue laptop hard drive runs at 5200rpm, but because the data is so densely packed, that drive is faster than most 7200rpm 500GB laptop hard drives, and in sustained read it's faster than some SSD's.

More to the point: for most computer users, you will never really notice the difference in speed between a 7200rpm drive and a 5400rpm drive. You will, however, notice the difference in noise. For specific applications, it'll make a difference, but for most of us, it won't at all.

Re:7200 RPM data drives

[Anonymous Coward]

Just check out the reviews for similar cases... the 1TB WD Scorpio Blue laptop hard drive runs at 5200rpm, but because the data is so densely packed, that drive is faster than most 7200rpm 500GB laptop hard drives, and in sustained read it's faster than some SSD's.

Sustained transfer rate is the only thing which high data density improves, and STR is not actually that important for overall performance. You'd be shocked at the real-world effective throughput of HDDs with 100MB/s or better STRs when you ask them to seek just a little bit; it doesn't take much to reduce a HDD to low-single-digit MB/s figures (or even below 1MB/s). A good rule of thumb is that most HDDs cannot average more than 100 seeks per second (that's just 10ms to service each random IO request, which is optimistic in consumer HDDs). So, if you're not reading a minimum of 1MB of data at the end of each seek, throughput is limited by how fast the drive can seek, not its streaming data rate. And all too many IO workloads look small (32KB or less) reads or writes in a random pattern. Data in a filesystem is rarely organized in a nice linear array. The usual exception to that rule is large media files, but how much do you care about how fast those copy? For most users, that's only done once in a blue moon.

This is such a huge deal that one way Microsoft and Apple make their respective operating systems boot faster on HDDs is to record the sequence of sectors read during boot, then rearrange the FS to move them into a nice linear array so that the next time the system boots it doesn't have to seek at all. You can easily improve the disk component of boot time by a factor of 100 with this trick.

The primary benefit of increased spindle speed isn't even increased STR, as most people assume. It does help STR, but the main reason enterprise database drives are 10,000 or 15,000 RPM is improved random access performance. A random IO has two components, seek time (drive moves the head to the desired track) and rotational latency (drive must wait for the desired sector to pass under the head). Average rotational latency is equal to half the time it takes the disk to spin once. At 5400 RPM, average latency is 5.56ms, at 7200 4.17ms, 10K 3ms, and 15K 2ms. The other thing which is usually improved in tandem with spindle speed on higher-RPM drives is seek time, i.e. giving the drive faster actuators to move the heads. 2.5" 15K enterprise drives have average seek times around 3ms; 2.5" and 3.5" 5400 RPM desktop drives have average seek times around 10ms if you're lucky, maybe slower. (This is why I said 10ms total is optimistic.)

The final thing to understand is that spindle speed, seek performance, and capacity (# of platters and heads) all influence power, and power is the main limit to consumer HDD performance. Moving more mass uses more power, and moving it faster also uses more power. Non-enterprise drives are designed to hit fairly low power targets because they have to avoid cooking themselves when used in enclosures with little or no airflow. And on the laptop end, obviously you don't want to eat so much power that it becomes a noticeable battery drain. (For this reason, laptop 7200 RPM drives don't have as much of a seek time advantage over 5400 RPM drives as you'd expect when comparing desktop 5400 RPM to desktop 7200 RPM: they can't increase seek power budget much lest the whole drive end up using more than OEMs will accept.)

More to the point: for most computer users, you will never really notice the difference in speed between a 7200rpm drive and a 5400rpm drive. You will, however, notice the difference in noise. For specific applications, it'll make a difference, but for most of us, it won't at all.

Strongly disagree. The HDD is a very important bottleneck for a lot of use cases, and the difference in price between a 5400 RPM and 7200 RPM HDD is not much. 7200 RPM isn't quite as effective in laptop drives due to the power limitations I mention

Re:7200 RPM data drives

[cynyr]

Could you find me a $50 SSD worth having? Also I would never allow my BIOS to do that, if it failed how would i recover from a partial write?

Una Pagina

[milbournosphere]

Link to print-friendly article: http://hothardware.com/printarticle.aspx?articleid=1712

Graphed speeds are wrong?

[Nemilar]

Am I reading the graphs wrong, or are they claiming 160,000MB/s throughput on those drives?

Is that supposed to be KB/s? I might buy 160MB/s (that's still crazy high), but 160GB?

Re:Graphed speeds are wrong?

[Anonymous Coward]

Has to be K.

Re:Graphed speeds are wrong?

[Anonymous Coward]

Maybe it's burst throughput and not sustained?

Re:Graphed speeds are wrong?

[wagnerrp]

No. The fastest SATA interface currently available bursts at 600MB/s.

Re:Graphed speeds are wrong?

[owlstead]

Burst throughput from the drive itself still can not surpass SATA throughput, and even SATA-3 is not *that* fast.

Re:Graphed speeds are wrong?

[Anonymous Coward]

no they are correct. the cache on the drives is 64MB which is screwing up by dumping burst read data. they should have accounted for this but didnt.

Re:Graphed speeds are wrong?

[Anonymous Coward]

I wonder the same. I just bought a 1.5TB drive which does about 120 MB/s in ext4. Over a thousand times that throughput in a 3TB drive? I don't buy it.

Re:Graphed speeds are wrong?

[Anonymous Coward]

A Samsung Spinpoint F3 can reach those types of speeds in read, and can go over 200MB/s in Burst Write while sustaining over 100MB/s Write.

So this shouldn't be exactly surprising. There are faster drives on the market than the example I'm telling you about.

Re:Graphed speeds are wrong?

[Anonymous Coward]

Maybe they're European and it's a decimal point.

Re:Graphed speeds are wrong?

[thegarbz]

I might buy 160MB/s (that's still crazy high), but 160GB?

Not so crazy when you think about it. As density has increased for a drive spinning at a certain speed more data passes under the head. Drives with larger densities (as opposed to simply more platters) typically perform faster.

I don't trust my data to a single huge drive

[mikael_j]

Sure, a single external drive for backups is one thing but for everyday use I prefer to use RAID-5 or RAID-Z. Sure it's anecdotal but it just seems to me that newer drives fail more often than older ones. Not to mention that losing all the data on a 3 TB disk is a bit worse than losing all the data on a 540 MB or even 9 GB disk was. Sure I had important data on those as well, but it was easier to keep the most important stuff backed up properly.

Re:I don't trust my data to a single huge drive

[ColdWetDog]

The idea of a rational backup strategy is that you don't lose data, no matter what size drive you are using. So if you're worried about a 3TB drive failing, you're doing it wrong.

Re:I don't trust my data to a single huge drive

[Anonymous Coward]

That's why you buy several of these, fill them, and then go blind.

Re:I don't trust my data to a single huge drive

[owlstead]

The rational backup strategy for my movie collection *is* a RAID-1. One of which has actually failed (Samsung 2GB) so I have to replace it *quick*. It's not 100 safe or anything, but it's a balanced decission in my opinion.

Documents are stored on my SSD, my RAID and online, but I don't need 3 GB for that anyway.

Re:I don't trust my data to a single huge drive

[ColdWetDog]

And that's fine. But backup strategy shouldn't be based on 'ooh, that drive is too big to fail'. That IS what RAID is for, after all.

Re:I don't trust my data to a single huge drive

[wagnerrp]

The claims that newer drives are more error prone is a fallacy, resulting from a failure to understand basic statistics. These are people who in the past have bought one, maybe two hard drives, but now they have several OS drives on several computers, plus several more for bulk storage, portable storage, etc. When you have five times the number of drives, you are five times more likely to suffer a failure in one of them. People are experiencing more failures, because there is more to fail, and they are incorrectly equating that to a belief about reliability.

Re:I don't trust my data to a single huge drive

[Nethead]

"..that drive is too big to fail."

Oh man, I can't wait to use that one in an argument.

Re:I don't trust my data to a single huge drive

[Anonymous Coward]

Most of my movies are over 2GB individually. Do you mean 2TB and 3TB ?

Re:I don't trust my data to a single huge drive

[mikael_j]

I can only speak for myself but if anything I had more drives "back in the day". These days I often only have a single disk for a machine with bulk storage in an array accessed over the network. It used to be that I would have multiple hard drives per machine (as an example, what was once my main workstation, a 486DX4-75, had a 210 MB IDE disk, a 540 MB IDE disk, a SCSI controller card and a couple of old SCSI drives I found lying about. What does my current main workstation have then? A single 1 TB SATA disk).

So no, for me your hypothesis does not hold true, I used to have lots of disks, I still have a box somewhere with lots of old disks in the 100 MB to 30 GB range. These days I just don't buy as many disks, I don't use as many disks and despite this it seems that they are more failure-prone.

Re:I don't trust my data to a single huge drive

[mikael_j]

My point was that it was easier to keep your important data backed up when you only had a few hundred MB or a few GB of data to worry about at any given time. These days if you have say, 2.5 TB of data, it becomes quite a hassle just to find the important data. Even if you know roughly where your important data is. That is, I may know that my important documents are in ~/Documents while random movie rips are in /mnt/bulkstorage/movierips but that's still not good enough if I've got 15+ GB of data in ~/Documents. And let's not forget the 30+ GB of photos in ~/Pictures. And so on...

Re:I don't trust my data to a single huge drive

[wagnerrp]

I've been buying hard drives for about the past decade, and off the top of my head, I've owned somewhere around 40 drives, from 32GB up to 2TB. The failure rate I've experienced has been consistent enough that I haven't noticed any different between the different generations. Maybe 2-3 died in the first couple months. Another 6-8 died within the first year. The rest are either still in use, or were retired before they died, and sitting in a drawer, presumably still functional.

Re:3TB Hard Drives in my pants!

[Anonymous Coward]

Where no one but your mother will ever find them.

That's not what MTBF "means"

[Quila]

Pun intended. Mean time between failure, it's only the mean, statistics. In the real world, it's quite normal to run drives with over a million hours MTBF and have a couple percent of them fail each year.

MTBF is really only helpful when you're running a bunch of drives and need to calculate projected time and money you'll spend replacing them. It has no real application to one drive's life expectancy.

Re:That's not what MTBF "means"

[rthille]

Between two drives, one with 750,000 hour MTBF and one with 75,000 hour MTBF, which would you choose for one or 2 drives? The MTBF isn't exactly predictive of your drives' lifespans, but it definitely has real application to the decision about which drives to buy...

3TB

[TheMan28]

Woow that is really big

Re:3TB

[NatasRevol]

Not so much.

http://9to5mac.com/2011/09/06/seagate-announces-industrys-first-4tb-hard-drive/

Why compare speed?

[obi1one]

Why compare read and write speeds on huge (and in a few cases low rpm low energy use) drives like these? For most users, the selling point is huge amount of storage for large files (video etc) in a single drive. Energy usage and heat producion might be relevant, and maybe a quick speed benchmark to give people an idea of what the drives are capable of, but 5 pages of speed benchmarks is silly. The differences in speed are so small really (20% between the fastest and slowest seems about typical) as well. Who buys 3 TB hard drives based on speed benchmarks? Give me big cheap drives with a decent warranty please, Ill use SSDs when I want speed.

Not A Bad Review IF . . .

[tgeek]

. . . your intention is to put a single 3TB drive in a desktop machine. IMNSHO, that's a fairly risky and unwise proposition. I think the review would've been better if the authors had covered a few more items of interest to the storage systems market (even the hobbyist/consumer/SOHO segments). For example: How much power does each drive consume? Temperatures? Noise? Error recovery (particulary WD's TLER)? I think these things might be of some interest to the broader market for these types of drives.

BIOS doesn't recognize my drive

[mcelrath]

How many times have we been through this "my BIOS doesn't recognize my drive because it's too large". Then the BIOS vendors find another way to tack on another factor of two. Then next year we have the same problem. Why the hell can't we solve this problem once and for all? Is there some fool that actually believes that next year, drives won't be bigger?

Re:BIOS doesn't recognize my drive

[Anonymous Coward]

If you follow the UEFI link in the summary, you will find this quote: "... allows for a maximum disk and partition size of 9.4 ZB (9.4 × 10^21 bytes)". This maybe won't solve it once and for all, but still...

Re:BIOS doesn't recognize my drive

[Anonymous Coward]

How many times have we been through this "my BIOS doesn't recognize my drive because it's too large". Then the BIOS vendors find another way to tack on another factor of two. Then next year we have the same problem. Why the hell can't we solve this problem once and for all? Is there some fool that actually believes that next year, drives won't be bigger?

We've had 48-bit LBA since 2003, which can support disks up to 128PB.

Re:BIOS doesn't recognize my drive

[Ex-MislTech]

For us old foggies what we did is read the drive parameters off the drive
and then manually enter them.

Then if the controller could not address all the space we used
what was called a drive overlay software usually provided
by the manufacture, that should get you up and running
but back in the day drive compression software could cause
serious issues with drives built with a drive overlay.

Also data recovery get more than just a little tricky.

If the bios can't autodetect the drive that is your most likely
path to an easy fix that or a BIOS update if they add support
for larger drives.

Good Luck ...

Re:BIOS doesn't recognize my drive

[rrohbeck]

But then you won't have to buy a new controller/host adapter/motherboard each time the interface standard is bumped up. It's called planned obsolescence.

Re:BIOS doesn't recognize my drive

[Anonymous Coward]

The problem is, the 'solution' is more expensive then the solution.
Bigger drives need more sectors; more sectors means a bigger address space, more space means more ram, more data width..
try convincing someone in the ninties trying to get to past the 800mb limit that it was worth allocating 48+ bits *per sector* to hard drive controllers.

Re:BIOS doesn't recognize my drive

[Skapare]

But you don't need to have UEFI to do it. You can do it with a legacy BIOS. You just have to know the standard for how the drives of that size will reveal their exact size, implement that in the next BIOS version, and you are there.

Re:3TB Hard Drives in my pants!

[Anonymous Coward]

Are you sure it's not a 3.5 inch floppy in your pants?

Now I have a 4TB Ubuntu box with plenty of Porn

[Anonymous Coward]

can you even watch so much porn in a lifetime ?

Re:Now I have a 4TB Ubuntu box with plenty of Porn

[Anonymous Coward]

can you even watch so much porn in a lifetime ?

You want your porn in good quality with 1080p, 5.1 surround sound and several audio tracks (3 different languages + comments by cast). That is about 25 gb / hour. (just check your bluray backups, its a fair estimate) So actually your lifetime of porn is just 6.66 days.

Re:Now I have a 4TB Ubuntu box with plenty of Porn

[Anonymous Coward]

So actually your lifetime of porn is just 6.66 days.

Shit, I'd go through that in a week.

Re:Now I have a 4TB Ubuntu box with plenty of Porn

[quantumphaze]

But that's unhealthy going over 16 hours a day.

My personal choice on Backups.

[Meridock]

I have been burned on 80GB drive failure, where the backup was on a different drive in the same machine (cost reasons), so I upgraded to a NAS with RAID (money more available)... Later on, I was in the process of backup, and I experienced a failure of the array due to a firmware issue and still lost a LOT of data. Those 2 experiences made me invest in redundancy AND backups. I now have a second NAS with RAID that is the primary backup device, and a set of cheap HD's for secondary backups. Is this overkill? Nope, not unless I find a way to place these in two remote locations :) So the better plan you have and execution of the plan - the 3TB drive failure should mean as much as a 1.44MB Floppy that goes t-up.

Re:My personal choice on Backups.

[networkBoy]

I backup onto 500 gig 2.5inch drives.
They are fairly cheap/gig and take less physical space than an equivalent stack of DVDs.
Important stuff is on a RAID1 of three 300 gig drives, and two 2TB drives (also backed up) less important stuff is backed up, but only on one disk in a JBOD collection.
If a JBOD drive fails, inconvenient, but that's all.
-nB

Very bad experience with the Hitachi

[SuperKendall]

it makes more sense to pay $129 for a 3TB 5400 RPM drive such as this Hitachi:

I had a really bad experience with this hitachi (not the more expensive one mentioned in the article). I ordered one and started synchronizing a 2TB drive onto this one.

At first everything worked well, but after the first 1TB or so it started to slow down. I re-started the transfer from the middle, but after 10 hours it had only transferred 100GB!

I bought the Seagate 3TB drives and that seems to be working much better (in that a full 2TB transfer took only 10 hours or so in a dual USB 3.0 dock).

I agree that for some uses a large but slowish drive can suffice, but for photography work it's really better to simply have a large fast drive (the SSD cache would not really help much since the write speeds are slow).

Re:Very bad experience with the Hitachi

[Anonymous Coward]

At first everything worked well, but after the first 1TB or so it started to slow down. I re-started the transfer from the middle, but after 10 hours it had only transferred 100GB!

Check the numbers reported by SMART. (The raw numbers, not the "user-friendly" numbers.)

I had a similar experience not too long ago during which transfer rates would be fast for most I/O operations, but bog down to nearly zero (as in, less than one-megabyte-per-second) in the crappy spots. Watching the copy and manually refreshing the SMART monitoring tool, I observed the raw error rate creeping up in precisely the spots at which transfer rates were slowest. The drive wasn't dead, but it was most certainly dying. (Hold on, OS, gimme another few hundred spins of the platter to see if I can figure out what's on this sector!) Before retiring the drive the next day, I played with it and was able to replicate the behavior on a per-file basis ("Check it out. This 5-megabyte file will take 30 seconds to copy because of two or three SMART read errors, but the one next to it will copy instantly") and in the case of two corrupt files with actual hard errors, could predict exactly on which byte the copy operation (after several minutes and several hundred read errors in SMART) would eventually fail.

Re:Very bad experience with the Hitachi

[bill_mcgonigle]

At first everything worked well, but after the first 1TB or so it started to slow down. I re-started the transfer from the middle, but after 10 hours it had only transferred 100GB!

How were you syncing? I did a 2TB Hitachi to 3TB Hitachi with mdraid and it progressed at 125-140MB/s for the entire transfer. The 2TB Hitachi was on an LSI 3801E (no 3TB support!) and the 3TB Hitachi was attached to AMD mobo SATA 6Gbps.

Re:Very bad experience with the Hitachi

[SuperKendall]

How were you syncing? I did a 2TB Hitachi to 3TB Hitachi with mdraid and it progressed at 125-140MB/s for the entire transfer

I was using rsync, it was steady at about that rate like I said for the first TB or so - then it plummeted and didn't seem to be getting any faster.

After that I was pretty gun-shy of using the brand so I went back to Seagate...

Of course all HD failures are totally anecdotal but I knew not to keep THAT particular drive.

Re: Unrelated Question....

[Anonymous Coward]

Did you used to go by the alias 'Trox Kenja' anywhere? Perhaps TKC rings a bell?

Re:nigger nigger

[tonywong]

Posts that get modded down to -5 should automatically have their IPs revealed.

EFI and Linux

[Anonymous Coward]

The only Linux distros that I played with EFI with where ia64 bit versions that ran on the Itanium machines I had at my last job.
Do any regular distros even have the capability of installing with an EFI compatible boot loader such as elilo or grub-efi?
I don't know about windows 7 or windows 2008 even on this. Do Windows OSs support installing a non MBR type disks? This seems a long way off for people to move away from MBR disks. I'm anxiously awaiting EFI, have been for years now. How long will MBR drag on.

Re:EFI and Linux

[compro01]

Windows Vista 64-bit since SP1, Windows 7 64-bit (32-bit versions are SOL), and Server 2008 support UEFI/GPT.

Here's an example

[Quila]

http://db.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html

Scroll down to the table and see for example a 1 million hour MTBF drive with a real-world annual replacement rate (how many die every year) one-sixth that of a 1.5 million MTBF drive.

Re:nigger nigger

[Dishevel]

Right.
The government would never use that against the people.

Re:nigger nigger

[morgauxo]

Why? So a bunch of script kiddies would turn their attention to some coffee shops and Tor nodes?

Seagate

[Venner]

I have one of the Seagate 7200.11 drives I bought in Sept 2009 that had the firmware issue at launch. Never experienced any problem with it myself, always passed all tests, and SMART status was great. Night before last, it disappeared under Windows. I shut down, checked the cables, rebooted and...failed SMART on boot. I should have done some more testing then, but I rebooted to run a disk scanner (Ultimate Boot CD - hightly recommend keeping a burn around) and it stopped being detected by bios. That quick - no warning, nothing.

The disk spins up to speed, then clicks several times before spinning down. After much looking, I found several people who'd had a similar issue and were able to resolve it via the serial interface, so I have some test tools and cables on the way. Hopefully I can get it reset and accessible again.

It's still under warranty (5 years, thank god), but I want the DATA on the blasted thing and don't want to spend 10x its cost. I have redundant copies of the important stuff (family photos, genealogy research, documents, music), but have probably 60 hours of old family 8mm & VHS recordings on there I hadn't gotten time to go through yet.

Re:Seagate

[whoever57]

1.That's what backups are for.
2. I think that Seagate will fix it for you so that the data is recovered.

Re:Seagate

[Anonymous Coward]

I have one of the Seagate 7200.11 drives I bought in Sept 2009 that had the firmware issue at launch. Never experienced any problem with it myself, always passed all tests, and SMART status was great. Night before last, it disappeared under Windows. I shut down, checked the cables, rebooted and...failed SMART on boot. I should have done some more testing then, but I rebooted to run a disk scanner (Ultimate Boot CD - hightly recommend keeping a burn around) and it stopped being detected by bios. That quick - no warning, nothing.

You never upgraded the firmware?

The nature of that bug was that you never would see any problems or warning signs, right up until the one time you got unlucky. It's a bit like Russian Roulette, with the trigger pull happening every time the drive spins down or powers off.

It has to do with internal logging. Like any modern drive it has an error / maintenance log, so that it can track its own health. It's a simple circular log: a fixed-size array of records, with a pointer to the "current" entry. To write a new entry, you overwrite the oldest, and advance the "current" pointer, wrapping around from the end to the start if needed. This log is scanned every time the drive powers up, as part of the selftests necessary for the drive to declare that it's ready to start accepting read/write commands. The bug is that if the pointer to the current log entry is evenly divisible by 64 (or some magic number like that), the powerup selftest code crashes and the drive never completes selftest. There's nothing physically wrong with the drive, there isn't even log corruption, it's just a bug in the code which reads the log.

It's still under warranty (5 years, thank god), but I want the DATA on the blasted thing and don't want to spend 10x its cost. I have redundant copies of the important stuff (family photos, genealogy research, documents, music), but have probably 60 hours of old family 8mm & VHS recordings on there I hadn't gotten time to go through yet.

If it's the bug I describe above, you're going to be able to recover the drive with all data intact by updating its firmware through that serial connection on the back. You should look into whether Seagate will do it for you; I'm pretty sure they had a free program to un-brickify affected drives, though they might not have an ironclad guarantee of data retention. (I would if I were them, for CYA legal reasons, so if you're really attached to the data I'd understand wanting to try it yourself before sending the drive away.)

Re:Seagate

[Venner]

I should have clarified. Yes, I updated the firmware when the issue became known and never experienced problems before or after, until now. I've run across threads mentioning that the first firmware released to correct the issue...didn't. Perhaps I nabbed that one without realizing it.

1.That's what backups are for.
2. I think that Seagate will fix it for you so that the data is recovered.

1. The video on the drive hadn't been worked with to be backed up yet; this is an additional 1Tb of raw footage. I've got 2Tb of completed video with a 2Tb backup already. And a crapload of DVDs padded by DVDisaster. I'm pretty serious about backups.
2. IF my issue was with the publicized bug, I've heard they offered free data recovery. If self-recovery doesn't work, I'll end up putting in a warranty claim and hoping its covered. Otherwise, it could be $300-500+, which I'd probably not pay. It'd just be a reaaaaaal pain to redo the recordings.

The bug is that if the pointer to the current log entry is evenly divisible by 64 (or some magic number like that), the powerup selftest code crashes and the drive never completes selftest.

Yeah, I remember reading a thread on ./ at the time from one of the Seagate engineers. I think it was something like, if the drive wrote a 360th log entry, but then powered off before writing the 361st, it got stuck. I created worse issues in assembly programming in college a decade ago, but thankfully my mistakes didn't make it to production. D'oh.

I've got a spliceable USB cable arriving tomorrow, so we'll see how it goes. Fingers crossed.

Re:Seagate

[unencode200x]

How'd it go? I'd love to hear!

Re:3TB Hard Drives in my pants!

[froggymana]

I have rounded up the best 3TB Hard Drives in my pants!

That's odd, some girl just told me that you had a 3 1/2" floppy.

Not big enough

[cashman73]

Based on the current size of the Library of Congress, you'd need a RAID of 93 of these to store everything! And you'd need to increase that RAID by two drives every month to keep up!

How about external HDDs?

[antdude]

Do 3 TB exist and are reliable?

Re:750,000 hours MTBF. BS all the way

[Anonymous Coward]

Does anyone expect any hard drive to last 136 years, or 1.2 million hours? The mean time before failure numbers are pure nonsense.

I have the Hitachi 3TB drive

[mkiwi]

I bought the Hitachi drive listed in the article, and it does fairly well performance wise. However, the clunker is loud, takes a long time to spin up, and generally makes too much heat/noise. I've owned some Seagate Cheetah 15K.3's in the past and this hard drive is as loud as them, and takes as long to spin up.

I am actually ordering a new WD Green 3TB drive from Amazon in the hopes that a lower spindle speed and power consumption will translate into less noise. I run a SSD for my main boot drive and applications and use the 3TB drives to do backups and store misc. files, so I'm not wanting for super high performance. If you're used to a HDD, then the Hitachi is a good choice for a boot drive, but don't get the drive for its acoustics.

3 TB? Pshaw!

[demonbug]

4TB is where it's at!

Re:3 TB? Pshaw!

[oik]

I'd be willing to bet that this "drive" is actually a pair of 2TB ones...

Re:3 TB? Pshaw!

[oik]

..and I'd be wrong apparently: http://www.thinq.co.uk/2011/9/7/seagate-ships-4tb-hard-drive/

Movie collection on a 2GB HDD

[Anonymous Coward]

Combined with 160GB/s reads, I can see why backups aren't an issue for you.

It's not exactly clear sailing.

[ResidentSourcerer]

There may be little problem with newer motherboards, but I can tell you there is a lot of combinations of stuff out there that won't work with a 3TB drive.

I just got burned on this. Had a not very old 500 GB Lacie external drive. The 500 GB drive in it was getting noisy, so I bought a Hitachi 3 TB drive, popped the case, and swapped drives. My Mac recognized it as a 801 GB drive. WTF!

A couple hours later I knew more about LBA. (Hitachi has good info on their web site.)

You need an OS that supports 48 bit LBA. You need drivers that support 48 bit LBA. You need adapter cards that support 48 bit LBA.

In my case the Lacie is a multi protocol box, so IT has firmware. And that firmware does not support 48 bit LBA, so bit 33 of the capacity is stripped off and I see 1 TB - 2 TiB -1 = 801 GB

I find it amusing.

3 TB for $150 bucks. 50 bucks a TB. My first hard drive added 1200 to the price of the computer. It was 10 MB and even that had to be logically divided into 8 chunks to be addressable by the 2 MHz Zilog Z-80.

I remember when CHS limitations restricted disks to 32 MB. There have been a series of limits since. Some of the limits were clearly stopgaps for a short respite, (We'll write bigger sectors and get a factor of 8) But several have been on the basis of "This should fix the problem for a few decades."

ZFS uses 64 bit addressing. Bets on how long before the first company ships a disk that won't address it.

10 years MTBF

[vaporland]

When i was doing IT support work I had a client with an Apple 120MB hard drive that had run continuously (been in active use) for over ten years. I doubt it was ever turned off during that time.

It was a seagate as I recall... they don't make 'em like that anymore.

Re:nigger nigger

[Crag]

Posts that get modded down to -5 should automatically have their IPs revealed.

Point one: circumstantial evidence

Just because a network transaction occurs between two IPs doesn't mean the hosts currently behind those IPs or their users were responsible for the offensive transaction. Your request (expose IPs of offensive ACs) is the meatspace equivalent of "hate speech sent through the USPS should have the return addresses posted publicly."

Letters and cards sent from buildings, and IP packets sent from hosts are circumstantial evidence. Condemning the owners or residents of a building, or the user of a host by its mail or network traffic is short-sighted and unjust.

Point two: free speech

Words alone are not harmful. Speaking out against a class of people is a bad idea, but it must remain protected speech for slippery slope reasons. We draw the line at threats only because they announce a destructive intention, and even then we respond to threats less strongly than we do to action. This is fair. Saying "X is bad" is not actually harmful to X. Saying "I'm going to hurt X" announces an intention to do harm which should be dealt with. Saying "It would be a good idea to hurt X" is a grey area which must be judged within a context to determine which side of the line it falls on.

When we fail to defend free speech our society becomes more brittle at best, and we give away power to cheaters at worst.

Point three: gaming the system

It is not particularly difficult to amass an army of Slashdot accounts with moderation points such that a single person could decide to apply -10 moderation to a post at will. Your proposal would grant such an army the ability to lookup any slashdot poster's IP. Do you know who is most likely to have the time and impetus to do this? The kind of person who trolls slashdot with racist nonsense.

You are asking to give control of the privacy of every slashdot poster to the kind of person who has no reservations about acting anti-socially.

TL;DR - End the witch hunts. Trollers gonna troll.