Slashdot Mirror
SSHDs Debut On the Desktop With Mixed Results
crookedvulture writes "Seagate's solid-state hybrid drives have finally made it to the desktop. The latest generation of SSHDs debuted with a 2.5" notebook model that was ultimately hampered by its slow 5,400-RPM spindle speed. The Desktop SSHD has the same 8GB flash payload and Adaptive Memory caching scheme. However, it's equipped with 2TB of much faster 7,200-RPM mechanical storage. The onboard flash produces boot and load times only a little bit slower than those of full-blown SSDs. It also delivers quicker response times than traditional hard drives. That said, the relatively small cache is overwhelmed by some benchmarks, and its mechanical sidekick isn't as fast as the best traditional hard drives. The price premium is a little high, too: an extra $30 for the 1TB model and $40 for the 2TB variant, which is nearly enough to buy a separate 32GB SSD. Seagate's software-independent caching system works with any operating system and hardware platform, so it definitely has some appeal. But dual-drive setups are probably the better solution for most desktop users."
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
They seem to have forgotten a little defect. SSDs have a low failure rate, high speeds, okay prices, but everyone's scared of flash memory degradation after a number of writes. Some crappy one would get 1500 write cycles on a chip but OCZ ones get 9000 which, even at my high usage on a 128GB drive, is at least 8 years before it fries.
So Seagate decides to take the biggest pitfall and hated feature and put it into a hybrid drive. All data written to the gigantic drive is passed through that 8GB buffer first. Flash memory that can put up with that amount of writes over the long term doesn't exist. These drives would maybe last a year or two if you're lucky.
I've had one in my desktop for a couple years now.
"But dual-drive setups are probably the better solution for most desktop users."
The SSHDs are useful, but we tend to combine them on our multicore machines.
Different stripes for different tykes.
-- Tigger warning: This post may contain tiggers! --
Came out for the desktop and everything else for that matter in 1995. Get with it, people.
I must say I find Linux's bcache much more appealing than hardware hybrids. I'm also not sure how this new hybrid drive would cope with software full disk encryption.
I had one of the laptop versions for about a year and a half now, and it's definitely an improvement over a traditional drive and considerably cheaper per GB than an SSD.
I'm not sure why the majority of the population wouldn't opt for these as they still give you decent capacity and speed over dedicated HD or SSD drives.
Sure they're not as good as a dedicated setup with a SSD and a HD, but then again, the average user can still install everything on their C: drive without making any changes from the default installation.
I looked at buying one of these. Writes don't really go to flash. Selected blocks are asynchronously copied to flash.
There's cool way to avoid the cash over use you mention that I wish someone would make in an under $500 drive. Have 4GB of flash, 4GB of DRAM, and a capacitor. Random writes go to DRAM, making random io a thousand times faster. On power failure, the capacitor flashes the contents of the DRAM to the flash. You get the speed of DRAM, crash safety, and 3TB of capacity from the underlying spindle.
I've been using a conventional hard drive paired with a SSD in Apple's Fusion drive configuration. This is only for Macs, but it makes it possible to use whatever size SSD you want, and the system automatically keeps the most recently written data on the SSD, saving the user the trouble of having to decide what to keep on the SSD and what to keep on the HD. In practice, the speedup is quite dramatic.
Hell I bought a dozen (12) 32GB thumb drives (USB flash) for $10 ea. 4x the size at 1/3 the cost so I have to agree that this is a crappy option especially as they've cut the actual cache down from 32M to 64M on these drives by using a meager 8M of flash. don't know if these new Seagates are even worth buying but they've pretty much shot themselves in the foot with this kind of crap.
Prices are Bare drives from Newegg (OEM)
Seagate 1TB Barracuda ST100DM003 with 64M cache $70
WD Green Intelipower 1TB Unkonwn Cache $70
Half the cost of the so called Hybrid drives. For the extra $70 you can almost get several different SSD's from 30 to 64 Gigs in capacity.
Mod me up/Mod me down: I wont frown as I've no crown
Well, in that case you could actually just skip the flash entirely.
The RAM could write directly to a dedicated area on the hard disk in the event of a power failure - sort of like how hibernate / suspend to disk works now.
Try reading again. 8 GB of Flash. It's not the same as a 65MB cache on a standard drive, it's more like two drives bundled into one package with the most used files 'cached' on the 8 GB of Flash. I'm not clear yet on if the files are actually cached (meaning there is another copy on the 2 TB HDD part), or if they live normally in the 8 GB Flash part.
For one thing, it is annoying to have to separate the OS and whatever apps you want to launch fast on to a tiny drive from everything else. So it is of use to people that need cheap space, but wish to have convenience.
However another use is for people like me: Who have SSDs, but can't afford them for all their storage. I have a 512GB SSD for my boot and program drive, and another 256GB SSD for my samples. However I then have 2x2TB HDDs for storing data, particularly bounced audio tracks. I can't afford that in SSDs, just too much money.However the SSHDs, those I can, and probably will, afford. That wold give me SSD like performance for most things I do, no worries about a burst of multi-track writes overloading the media, but have cost effective storage to packrat large amounts of data.
I also could see them being useful in NAS units perhaps. Another level of caching to help accelerate random reads, while keeping disk cost down.
They aren't the be-all, end-all, but I see plenty of use.
In general, I don't see a lot of use of an SSHD on the desktop, at least not with only 8GB of NAND. There are significant advantages for a system (such as a notebook) where there is only a single available storage option.
However, if you have the capability to have both an SSD and an HDD you have a couple of much better options (e.g. on a notebook with an mSATA port or any desktop).
1. Install OS to SSD, manually manage installing things to HDD.
This will generally give you the fastest performance for the things that really need them, but you're losing a lot of your SSD to OS + hibernation file (if enabled) and you have to know how to manage multiple drives effectively.
2. Install OS to HDD, dedicate a portion of the SSD to caching (e.g. with Intel Smart Response Technology) and use the rest for things you always want SSD performance with.
This gives very simple drive management - by default you install everything to the HDD. The SSD caches the most-used stuff and you can manually move things which benefit most from SSD characteristics to the SSD. Definitely the easiest setup to usefully use an SSD when setting up a machine for someone else.
BTW this is how I've got my ultrabook set up (32GB SSD cache, 80GB SSD data partition). The 32GB of cache is approximately equal to the Windows 7 OS + Hibernate file (16GB RAM) so I'm not really losing any space, but it's being used more usefully. And things which greatly benefit from fast random access (e.g. source code trees) are on my SSD.
Yeah I have setup the fusion system with a Mac Pro (4 disk bays), with a OWC 128gb and a fast enterprise 7200 rpm disk. runs about half ssd speed range ++, Very stable very satisfied with it, there is good tutorials of settings this up on the net. Plus you have space for another disk that backups this combination every hr. Reason is that I use software that stores a lot on system disks, so this works better than buying expensive large size ssds.
Current SAS raid controllers have pretty much that. DRAM + NAND flash + supercap, write ram to flash on power loss, restore flash to ram on power-up.
Solves the common problems with battery backed DRAM like constantly having to check/replace the damn battery and prolonged power outages killing unwritten data (which usually hosed the whole array).
After reading TFA, I was wrong, that was the previous model. This model does cache some writes in an area of the flash operated as SLC.
with actual real world write speeds of around 20 MB/s, that capacitor would need to spin the drive for three minutes. That would be one hell of a capacitor. Flash chips use less power and are faster, so they could run long enough on capacitors that actually exist.
.
I really do hate overloading acronyms. SSH / SSHD is pretty well known already. It's what most unix folks (and I really do hope that that is the majority of slashdot readership) use to log on to servers every single day.
C'mon.
"Rune Kristian Viken" - http://www.nwo.no - arca
I've had their first generation SSHD drives for about two years and it has been so great that I ended up recommending the most recent (3rd gen) 2.5" drives to a friend. That turned out to live for only 3 weeks before giving me the embarrassment to have it replaced yet again.
As much as it is nice to have that "hybridness" in one form factor, this recent blunder will deter me from ever trusting Seagate again.
A hybrid drive is better for MOST users. very few users can figure out how to configure windows to put /users elsewhere from the main drive. It's a HUGE design flaw that they dont let you pick it at install time like every other freaking OS on the planet.
Do not look at laser with remaining good eye.
Run PGP Full Disk Encryption and see if it performs well. That shit will screw it up good.
Suppose you were an idiot and suppose you were a member of Congress
They are cached, the data exists on the rust too so if something bad happens to the flash your data is generally safe-ish... you have backups anyway, right?
Shhhhhhhhhhhd
Windows might have to rely on proprietary fakeraid drivers, but Linux does not.
I have my OS on a Plextor SSD and most everything else on the new Seagate 2TB SSHD. It works pretty well. If I need something to start up very quickly I put it on the SSD which still has 100GeeBees free. Boot time is about 4 seconds, but I sleep or hibernate, which is a 1 second startup. Why not use this as a secondary disk? It was like $15 more.
For READS, yes it's mainly about boot time and the first time you open a frequently used program. WRITES on the other hand can't be cached to RAM, not for more than a few seconds (and some not at all). Persistent cache makes all the difference for random writes.
The benchmarks understate the improvement because they generally lack locality and frequent rewrites. Benchmarks typically spread writes all over a 2 TB drive. In actual use, random writes aren't truly random. A database will write to the same xx MBs thousands of times, as will an email client and many other applications. Having the 500 MB that is your database on the flash cache is a huge improvement for these types of workloads. For some other workloads, the improvement is minimal.
Do you happen to have any real world comparisons between these newer and some other options. The 512 MB of battery backed RAM in my 3ware 95xx SHOULD be awesome for some workloads where it's not. It's better than turning off the cache, but it's not what I was hoping for.
Since mdadm software raid is much faster than the 3ware for my raid 5, I'm hesitant to spend $$$ on a high end raid card that likely will be slower and less compatible than modern software raid. When bcache is in the vendor kernels THAT looks like a giant win with some PCIe flash.
The idea of buying a $40 32GB SSD and using it as a cache instead of a hybrid drive is silly - those cheap SSD's wear out very quickly with sustained writes.
I don't know if it's SLC, or what, on the drives, but you can push a lot of data to disk and not break the SSD on these things, which is fairly remarkable for NAND flash.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
PCIe is very "close to the processor", and PCIe flash cards are available. They are awesome, but require software such as bcache.
So you would divvy up your system into a
64Gb SSD C: and a
1Tb 7200 D:
blazing fast c drive, equivalent suck d drive ...is twice or more faster. ... everything.
I would spend the same and get twice the capacity of a solution that on average
FOR EVERYTHING not just the c drive.
My photos are faster, my vmdk are faster, my compiles are faster,
"For READS, yes it's mainly about boot time and the first time you open a frequently used program. WRITES on the other hand can't be cached to RAM, not for more than a few seconds (and some not at all). Persistent cache makes all the difference for random writes."
You generally only need to cache writes for a few fractions of a second, until the write head is in position to transfer them to disk. Dynamic RAM is fine for this, and using a persistent medium is not going to magically improve your results here.
"The benchmarks understate the improvement because they generally lack locality and frequent rewrites. Benchmarks typically spread writes all over a 2 TB drive. In actual use, random writes aren't truly random. A database will write to the same xx MBs thousands of times, as will an email client and many other applications. Having the 500 MB that is your database on the flash cache is a huge improvement for these types of workloads. For some other workloads, the improvement is minimal."
The effect you want here is achieved simply and without any problem by simply adding 500mb of RAM to the system cache which knows a lot more about access patterns and files than the on-drive logic can possibly gather.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
its called OS cache, just allocate 4GB of ram to caching and be done with it
good luck with power outages tho
Who logs in to gdm? Not I, said the duck.
It's the noise! I just can't stand a machine that grinds when something is about to load. I can tolerate a little delay, if it is silent.
It really needs a 7200rpm disk, in a laptop form factor. 5400 rpm laptop disks really suck badly, even with a lot of disk cache.
This looks like a cheap and nasty way to extract a little more mileage from obsolete 5400rpm disk technology.
Avoid like the plague, if you see a disk that is 7200rpm in a laptop, unless you like crippled I/O.
Or you can buy 32-64 GB SSD and HDD, and use flashcache, and you will have the same hybrid drive but with 4-8 times larger cache.
s/crookedvulture/information week/g
I'm going to voice the opinion that software-independent caching system is definitely NOT the way to go: the firmware has no way of knowing how often the files are going to be accessed in the future and if they should be kept in cache for a longer time, the firmware doesn't know what type of a file it is, the firmware doesn't know the size of it and so on and so forth -- basically, it knows none of the important details and will end up caching stuff it doesn't need to cache, will end up not caching things that should be kept in cache and since it doesn't know actual filesystem details it can't even optimize its own structures to match those of the filesystem in use. It's just a really basic block cache.
I'm going to voice the opinion that software-independent caching system is definitely NOT the way to go: the firmware has no way of knowing how often the files are going to be accessed in the future and if they should be kept in cache for a longer time, the firmware doesn't know what type of a file it is, the firmware doesn't know the size of it and so on and so forth -- basically, it knows none of the important details and will end up caching stuff it doesn't need to cache, will end up not caching things that should be kept in cache and since it doesn't know actual filesystem details it can't even optimize its own structures to match those of the filesystem in use. It's just a really basic block cache.
Apple's Fusion drive works quite well that way. They don't care about files - everything is based on 128 KByte blocks; probably the write page size of the SSD drive. In a typical configuration (128 + 1000 GB) you have about 9 million blocks of which the one million that is used most often is located on the SSD drive. It even works if you use a VM to run Windows.
If you have a large music library, typically only the metadata from each music file will be on the SSD drive. If you have apps that are large because of 20 localisation, plus megabytes of help files, videos for introduction etc. only the part of the app that you actually use is on the SSD drive. Directories are accessed a lot, so they go on the SSD drive. All automatically.
And there's a 4 GB write cache, which allows gazillions of small writes to the SSD drive to be streamed at maximum speed, and then the real write happens when the drive isn't busy.
Apple's Fusion drive works quite well that way. They don't care about files - everything is based on 128 KByte blocks;
I just googled around and it seems you're incorrect on that -- since it's the operating system that handles the caching it is also aware of the filesizes and the likes and doesn't even try to start caching large files, videos and such. The SSHD, as mentioned in the article, isn't aware of such things and will waste time and effort on caching stuff it shouldn't be caching in the first place.
The major difference is that the cache from the SSHD is persistent while your RAM isn't. For your OS to buffer a certain file it still needs to read it a first time from the disk. E.g. when starting up or rebooting this helps you nothing at all. The SSHD (might) have said file in cache and hence can serve it much faster.
I'm not sure how you come to the conclusion that your system cache "knows a lot more about access patterns and files than the on-drive logic can possibly gather.".
Given the way HD's work these days the OS knows nothing about what is actually happening on the disk. Do you really believe that the block-addressing used by the OS is actually related to how the data is spread out on the disk ?
If there is one thing to be learned on slashdot, it has to be sarcasm.
"The major difference is that the cache from the SSHD is persistent while your RAM isn't. For your OS to buffer a certain file it still needs to read it a first time from the disk. E.g. when starting up or rebooting this helps you nothing at all. The SSHD (might) have said file in cache and hence can serve it much faster."
That's what I have been saying over and over. This will give you persistence which should mean a faster boot, but is of little or no utility outside of that, when compared to the alternatives.
"I'm not sure how you come to the conclusion that your system cache "knows a lot more about access patterns and files than the on-drive logic can possibly gather."."
Because the OS actually knows which blocks are assigned to which files, what type of files they are, etc. The disk only knows what the OS wants stored in which logical address. The disk simply doesnt have access to the information that's needed to do truly intelligent caching.
"Given the way HD's work these days the OS knows nothing about what is actually happening on the disk. Do you really believe that the block-addressing used by the OS is actually related to how the data is spread out on the disk ?"
Of course not. But the disk simply translates one coordinate system to another, it does not (and should not!) implement the filesystem or have any high level information about the contents of the drive.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Especially since SSHD seems to be an abbreviation for "Solid State Hard Disk" which is false, since a disk isn't ever itself "solid state". Even "Solid State Hard Drive" would still be misleading, because these "drives" are not entirely solid state. If they just called it an "SSAHD" (the A for "Asssisted") it would make more sense.
Power loss is the reason for the capacitor to copy the RAM to flash, to basically make persistent DRAM cache.
one of the 2.5" drives. Benchmarks are a dubious thing - sure you can overwhelm the cache but in real world use that is not going to be an issue. Most users are doing the same thing(s) over and over and the drive optimizes to keep the necessary files in the ssd for rapid access. Likewise, modern drives, even the 5400 variants, are fast enough to keep up with video recording. So this really boils down to - are you willing to take a performance hit on the odd times you actually read or write a gigantic file in exchange for near equal everyday performance and a huge capacity at a very cheap price.
In my caae, the answer is a firm yes.
The Fusion drive does not use the SSD as a cache. Rather, it merges the SSD and the HD into one large virtual drive, keeping the most recently written data on the SSD and the old stuff on the HD. The advantage, of course, is that you can pair a reasonably sized SSD, which will hold most of the data that you or currently using, with a big HD, and get much of the speed benefit of a SSD at much lower cost than a SSD big enough to hold all your data, and without the need to "triage" your data to decide what should go on which drive. I currently have a 240 GB SSD paired with a 1 TB HD, and the speed increase is quite dramatic.
Off course these disks do not know anything about the filesystem at all; all they do is look at the raw throughput. There is something to be said about the OS knowing which files are worth caching and which not; but in the end the cache on the SSHD will come to the same conclusion as it simply keeps track about which blocks of data are most often requested. Plus, having an SSHD doesn't magically sabotage your system cache.
Like I said, you may find all sorts of reasons to not like it, in practice the thing delivers on its promise. It's far from perfect and it can be fooled into taking the wrong decisions but that's not a terrible thing to happen as it will 'heal' over time.
Example : my laptop used to have a Momentus XT and although the older model has only 4Gb cache, it booted faster, had Visual Studio open in A LOT less time, could bring Excel up in 2 seconds, same for SSMS, Firefox would load faster, etc ... I very much doubt all of those programs fit in those 4Gb but still it managed to find out which were most 'important' as the loading times of ALL those programs (os) were remarkably lower ALL THE TIME vs my colleagues' machines that were pretty much exact copies safe for the fact they had the original 'ordinary "black" whatever disks". At a certain point in time I had to run a virtual machine for a while and -not entirely unexpected- after a couple of ''virtual reboots' said machine also started up remarkably faster, programs inside it got faster to load too etc... but all of this came at the expense of slower loading of eg. VS when started 'locally'. After the VM-project was finished it took a couple of days for everything to turn back to normal and I guess if I had kept the virtual machine and started it up again then it would have been its original 'slow' again.
Currently I have Samsung EVO Pro + that WD Scorpio Black in the media-bay. The SSD feels 100x faster than did the SSHD but I noticed that having the XT as data-disk (used pretty much only for backups & multimedia) didn't really make much of a difference vs a normal disk as the access patterns were simply not appropriate for it. So I put it in my little file/media-server at home where it makes more sense.
If there is one thing to be learned on slashdot, it has to be sarcasm.
Flash solves the problem of waiting for verified writes. That's why putting database logs onto battery-backed high speed memory improves performance dramatically.
That said, do desktops really need that kind of performance boost. Unless you're doing some serious data creation, the only thing that's slow on today's desktops is booting Windows. Linux boots so fast, I wouldn't bother worrying about throwing hardware at that 'problem', and Windows isn't even that bad these days. Whether ChromeOS and it's like ever really replace traditional desktops, the desktop workload is going to continue to move in the direction that Chrome addresses. Brute speed (beyond the basics to provide a smooth experience) will become less and less of a factor. As it is, battery life seems to be overtaking speed as the main hardware concern.
Posted from my Android phone. Oh, I can change this? There, that's better...
I really do hate overloading acronyms. SSH / SSHD is pretty well known already. It's what most unix folks (and I really do hope that that is the majority of slashdot readership) use to log on to servers every single day.
C'mon.
I use telnet
The fact it's called SSHD is bugging me, it's confusing, who picked the name?
Because Windows already takes care of this with SuperFetch. After you load the OS it immediately caches the applications you use most often into available ram, and removes them when you actually USE that ram. The cached applications load instantly, and the hard drive is none-the-wiser.
In fact, there used to be a grand push to put as much DDR cache in hard drives as was cost-effective, but the performance improvements have really disappeared after 32MB. The fact is that people access far too wide a range of large data files, and the OS has been smart enough to keep everything it needs memory-resident for awhile now.
The SSHD is an attempt to handle the two major weaknesses of SuperFetch:
(1) Boot time is still limited by the speed of your hard drive.
(2) Application loads are cached, but not data I/O. They are also removed from cache when memory is needed by other applications.
It does a surprisingly good job for such a small price premium. As long as you're not doing more server-oriented loads (i.e. streaming media to multiple users or serving large numbers of Bittorrent users) the non-volatile cache works well to compliment SuperFetch. It's a good compromise solution for people who don't want to pay the premium for an SSD + hard drive.
Man is the animal that laughs.
And occasionally whores for Karma.
Be careful of google, it's easy to find wrong information. There was a lot of speculation reported as fact when Apple first talked about Fusion Drive, based on reading too much into the (naturally) very abridged explanation of the tech which Apple's executives gave in keynote speeches. That's probably what you found.
In practice, Fusion Drive turns out to be implemented in Apple's LVM (logical volume manager) layer. The LVM layer knows nothing of files, it's a block device abstraction. The Fusion Drive LVM driver is actually just a special case of their spanning LVM driver, one which is aware that one drive that is a member of a spanned volume is faster than the other. It tries to keep the fast disk full of frequently used blocks, except for a 4GB zone to buffer incoming writes. When it chooses what blocks to move where, it does so on the basis of block-level access frequency, not higher order abstractions like files.
That said, before Fusion Drive, OS X already had some heuristics (and provisions for applications to provide explicit hints) to try to detect / be told when data shouldn't be cached in RAM. So for example if you write a movie player app, and you want it to be a nice citizen which doesn't cause all of the free RAM to get filled with gigabytes of movie data as it works its way through the file, you use the hint API to tell the OS "hey I'm reading this stuff only once, you shouldn't cache it because I'll never need it again". And if you don't do that, there are still heuristics the kernel uses to try to guess. I wouldn't be surprised if they added something to pass these performance hints down to the Fusion Drive LVM code, because anything you don't want to cache in RAM is probably also something you don't want to migrate to the SSD.
It isn't true that it will never locate certain kinds of data on the SSD, though. If nothing else, most written data goes to the SSD temporarily even if the system subsequently decides to background-migrate it to the HDD.