Slashdot Mirror
Hybrid Seagate Hard Drive Has Performance Issues
EconolineCrush writes "The launch of Seagate's Momentus XT hard drive was discussed here last week, and for good reason. While not the first hybrid hard drive on the market, the XT is the only one that sheds the Windows ReadyDrive scheme for an OS-independent approach Seagate calls Adaptive Memory. While early coverage of the XT was largely positive, more detailed analysis reveals a number of performance issues, including poor sequential read throughput and an apparent problem with command queuing. In a number of tests, the XT is actually slower than Seagate's year-old Momentus 7200.4, a drive that costs $40 less."
The drives are fine, it's just a firmware issue. They'll fix it in the next few months. It's not like people who bought the drives are screwed because of faulty equipment.
This is why I hesitate to be an early adopter of new technology. There's always real-world conditions that occur when a wider sample size comes available (i.e., the Release to Market) than can be reproduced in a lab during testing--and that's true of virtually ANY product. While the problems generally are fixable, it's a pain in the rear to deal with them in the interim. I'll let others be the guinea pigs, thank you very much.
I don't post AC. I like my -1, Flamebaits. Trump/Sheen 2012 on the Batshit Insane ticket!
Quite a common occurrence with hybrids, actually. There are unique difficulties when cross breeding heteroploid organisms, which manifest in.... oh wait.
If there's one thing I've learned with Seagate, it's that they're terrible at fixing firmware issues. Their 500GB hard drives for laptops were notorious for having issues caused by crappy firmware that never got resolved by the time I trashed mine.
The caching and everything is all happening at a level below the OS and the file system, but these tests seem to have all been run in Windows 7 Ultimate x64, whatever that is.
Would another file system (ext4, for example) on Linux/*BSD or HFS+ on Mac OS yield different results, I wonder, w/and w/o swap? Can there be clashing optimization techniques here?
There was an issue with sound with drives around 2001 that they wouldn't fix. Then Dell said something to the effect of "they think our computers are crap, you fix it or we stop buying from you" and it was fixed. Anything smaller than that, and they would ignore it. I did update the firmware, and it made a huge difference in noise.
Learn to love Alaska
(a.) volatile memory is cheap for the amount needed for only the cache search (all it has to store is maybe 16 bytes per sector which is tiny). The ram cache is a trivial amount of the cost compared to the flash memory which is where your sectors are being stored.
(b.) re-read what I've listed above - I'm not suggesting you remove the OS tier of disk caching.
(c.) a fully associative algorithm is trivial in complexity in contrast to their 'adaptive' algorithms. A CS101 undergrad could implement a reasonable implementation in a hour. This is trivial stuff.
The OS is awful at write-back as if the power fails you've lost state. The benefit of a hybrid drive is that the flash is non-volatile. Writing to the flash ram is cheap. Writing to the disk is expensive. You get the best of both worlds with a flash based write-back cache.
The benefit of flash is it's cheaper than RAM so you can have more of it whilst being far faster than mechanical. Having a 32 or 64 GB flash hybrid drive provides sufficient cache to only rarely need to write back to the disk for most user operations whilst not forcing a 'system' and 'data drive'. As far as the system is concerned, it's just presented as one very fast 2 TB drive (or whatever).
The only time the system will slow down is when you begin to strip the cache which is perfectly reasonable as it means you've exhausted the flash capacity. For 99.999% of usage situations, this will never occur and it will feel just like a very very quick 2 TB flash drive.
I'm curious - what sort of algorithm would you use that can effectively store the data needed for a cache search that can represent 4096 byte sectors in 16 bytes.
As for the 'only time the system will slow down is when you have out-read the cache' - that's exactly the scenario that the OP is describing - massive serial reads on files that are larger than the cache. IIRC the cache was sized on the order of a few Megabytes, and every multimedia file I read all day / all night (music files, video files, gave vobs, etc) is at least that large, most are much larger.
PS - A CS101 undergrad could implement a reasonable implementation in a hour.
Now that's funny. Most first semester CS 101 undergrad students I've met couldn't pour rocks out of a box if the instructions were printed on the underside of the box.
Glonoinha the MebiByte Slayer