A Hybrid Approach For SSD Speed From Your 2TB HDD

Claave writes "bit-tech.net reports that SilverStone has announced a device that daisy-chains an SSD with a hard disk, with the aim of providing SSD speeds plus loads of storage space. The SilverStone HDDBoost is a hard disk caddy with an integrated storage controller, and is an easy upgrade for your PC. The device copies the 'front-end' of your hard disk to the SSD, and tells your OS to prefer the SSD when possible. SSD speeds for a 2TB storage device? Yep, sounds good to me!"

Comments

Sounds like bullshit to me

[Anonymous Coward]

How would the disk supposedly know, which part of the 2TB I am going to need next?

Re:Sounds like bullshit to me

[obarthelemy]

My guess is, it won't. It must be a dumb cache that just monitors which sectors/clusters are most often read, and caches those.

It may be better than the current use of SSDs though, which is to put a whole OS on them even though there's many parts of the OS that are barely used. If I had an SSD, IE8 would be on it !

Re:Save your money...

[adonoman]

Or just plug in a usb drive into any Windows 7 computer.

RTMFA already

[Weaselmancer]

They even have a fucking picture.

The 2.5 caddy is for your SSD. Mount your 3.5 wherever you like.

Re:Good operating system compatibility?

[kungfuj35u5]

There are a number of options: Firstly: Use a different machine with samba if you want to give the storage to your windows hosts. This option isn't for everybody, but over gigabit while it will be a third of the bandwidth with regular SATA, you definitely will notice the benefits (especially for async I/O, the dedicated slog device removes a lot of overhead). Secondly: It wouldn't be difficult to implement this as a software solution in windows to be quite honest. Caching models/algorithms are anything but complicated and one could easily write this in userspace or kernelspace. ZFS happens to do this on the file system layer, but it could easily be written on a much higher level of abstraction. There is nothing here that requires an ASIC design level of logic other than maybe freeing some bandwidth on your SATA bus for the bleeding in and out of cache to disk. Thirdly: Microsoft wrote off a feature in vista for moving swap to a dedicated disk (although this was forever possible since windows 2000 simply by specifying a different "page file"). Who's to say that microsoft wouldn't add that to their storage API under the disk management MMC. I can easily see an "add cache device" option being feasibly done.

Re:Save your money...

[iamhassi]

True, and everything sounded find until I read this
"Every time the system starts, HDDBOOST will initiate mirror backup automatically to ensure front-end data between the two drives are the same."

on every system start it's going to create a mirror backup, which sounded bad unless it works like Mirror RAID which doesn't take any time at all, it mirrors in real-time

So basically on every startup it mirrors the HD to the SSD, then pulls everything from the SSD until it needs to write data. Writing data goes on the HD, not the SSD. When starting up again the SSD mirrors all the new written data from the HD and continues on.

Sounds technically feasible and that should be faster and I'd love to see some benchmarks although I'm not sure how that'd work because reading data should look incredibly fast since it's on the SSD but written data goes to the HD so that'd be normal speed meaning a benchmark might not show amazingly fast speeds yet your PC should be noticeably quicker.

Been There, Done That

[HTH NE1]

Sounds a lot like the CacheCard from SiliconDust for Series1 TiVos, except instead of an SDRAM DIMM it uses an SSD. And the CacheCard doesn't sit between the devices but instead connects to the TiVo motherboard's card-edge connector, provides an Ethernet port, and is designed only to cache a particular 0.5 GiB part of the drive.

But since the SDRAM loses its contents on power off, it does add significant time to test and fill at startup, while the SSD would be ready nearly immediately.