Forgot your password?
typodupeerror
Data Storage Upgrades

A Hybrid Approach For SSD Speed From Your 2TB HDD 194

Posted by timothy
from the bottleneck-feedback-loop dept.
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!"
This discussion has been archived. No new comments can be posted.

A Hybrid Approach For SSD Speed From Your 2TB HDD

Comments Filter:
  • Just a cache? (Score:5, Insightful)

    by Erich (151) on Wednesday February 03, 2010 @03:01PM (#31013374) Homepage Journal
    Haven't disk manufacturers been doing this forever, using faster memories to cache disk? I guess the difference now is that the memory is slower than DRAM and non-volatile so it isn't lost in the event of power failure? Or maybe you can get more flash storage at a low price point?
  • by GungaDan (195739) on Wednesday February 03, 2010 @03:01PM (#31013380) Homepage

    I don't see where a 2.5" HD is required - 3.5" should be fine. The gizmo looks like a 2.5" to 3.5" adapter tray, but the HD is not installed in the gizmo.

    Besides, have you ever heard of a 2.5" 2TB drive?

  • by sakdoctor (1087155) on Wednesday February 03, 2010 @03:02PM (#31013398) Homepage

    No software or driver update is required

    Some software is needed to achieve the magic

  • by Anonymous Coward on Wednesday February 03, 2010 @03:04PM (#31013418)

    I DNRTFA, but this really just seems like a fancy version of cache to me....

  • by argent (18001) <peter.slashdot@2006@taronga@com> on Wednesday February 03, 2010 @03:09PM (#31013490) Homepage Journal

    No, it's a simple version of cache that doesn't actually do proper caching. All it does is preloading, and only over part of the device. Most of the volume of the hard disk will have no performance boost at all. You'd almost certainly be better off just having two devices, and using junction points on Windows or soft links on UNIX to move the frequently accessed files to the smaller disk.

  • Re:Just a cache? (Score:3, Insightful)

    by asdf7890 (1518587) on Wednesday February 03, 2010 @03:17PM (#31013598)

    "DRAM is yesterday's news. SSDs are the future. And they cost a lot more than a pile of memory chips, therefore they must be better. Order fifty." -- Some PHB

    SSDs are cheaper per Gb then DRAM. Compare the price of a 64Gb SSD to 64Gb with of decent DDR2/3 RAM. The per-Gb price difference is likely to grow too as SSD prices are falling more sharply than DRAM prices at the moment.

  • by KDN (3283) on Wednesday February 03, 2010 @03:17PM (#31013600)
    Would it not be more cost effective to add more main memory to the machine? Main memory would be a lot faster than SSD ram. Also I have a concern that frequently updated blocks (like your file system superblocks) would not get written out to disk in a timely fashion.

    Now, maybe you could do it safely if the device had RRD ram to handle the caching, SSD flash ram to handle power outages, a rechargable battery or ultra cap to provide power to write the RRD ram to flash ram after a power outage, and a controller to handle all this. You would need to implement all the normal os buffer caching and writebacks as well.

  • File system (Score:1, Insightful)

    by olau (314197) on Wednesday February 03, 2010 @03:27PM (#31013704) Homepage

    There was a paper some years ago about building the file system in such a manner that smaller files were placed on an SSD ( 1 MB) and large files were placed on a harddisk. At that time, SSDs were a lot smaller than today though.

    Generally, it can make sense to discriminate your files because they don't all have the same space and access characteristics. Maybe 100 files is taking up 90% of the space compared to the other 9900 files. Maybe it's similar for the access pattern.

    Still, for the idea to fly, you need to a robust algorithm and it needs to be clever about the strengths of the hardware. For instance, SSDs aren't so hot at random writes, sadly. Less than 0.1 msec write time would be neat for an ACID database.

  • Re:Holy carp! (Score:3, Insightful)

    by radish (98371) on Wednesday February 03, 2010 @03:32PM (#31013758) Homepage

    Well... it looks like there finally might be a reason to spend the money on an SSD. Up until now, it would be a nice speed boost, but the cost:performance ratio is so out of whack for SSDs, it just makes purchasing one ridiculous unless you have some very specific needs

    "Very specific needs" like wanting my OS & apps to load as fast as possible? Putting OS, apps, pagefile etc on the SSD greatly improves system responsiveness. FLACs, MP4s & JPGs can stay on a spinning disk, I don't need to access them so quickly. A couple hundred bucks on a smallish SSD gives you a MUCH better performance kick that spending the equivalent on RAM or CPU, in my experience (provided of course you have at least an average spec machine to start with).

  • by drinkypoo (153816) <martin.espinoza@gmail.com> on Wednesday February 03, 2010 @03:36PM (#31013806) Homepage Journal

    Would it not be more cost effective to add more main memory to the machine?

    I've never had a machine with capacity for more than 12GB RAM.

    Also I have a concern that frequently updated blocks (like your file system superblocks) would not get written out to disk in a timely fashion.

    That's a bigger problem with your RAM-based approach than with a flash-based one.

    Now, maybe you could do it safely if the device had RRD ram to handle the caching, SSD flash ram to handle power outages, a rechargable battery or ultra cap to provide power to write the RRD ram to flash ram after a power outage, and a controller to handle all this.

    You can get this with ZFS, a DRAM disk with a backup battery (volatile disks do exist that you load with DIMMs) and a caching raid controller with a backup battery.

  • by tepples (727027) <tepplesNO@SPAMgmail.com> on Wednesday February 03, 2010 @03:45PM (#31013904) Homepage Journal

    There is nothing new or impressive about this device.

    Other than that it is compatible with applications and peripheral drivers designed to run on the majority operating system for home and office PCs, which has no support for ZFS.

  • by ByOhTek (1181381) on Wednesday February 03, 2010 @04:06PM (#31014146) Journal

    If you RTFA you'd find the 2.5" drive is for the SSD, not the rotational drive.

    The bracket mounts the SSD inside of it, and then passes failed requests to the HDD, which is external to the bracket.

  • Re:Your sig (Score:4, Insightful)

    by KlomDark (6370) on Wednesday February 03, 2010 @04:56PM (#31014714) Homepage Journal

    // You sound jealous...

  • by Anonymous Coward on Wednesday February 03, 2010 @04:57PM (#31014728)
    You place too much value on a single drive bay. Buy a larger case already.
  • by redelm (54142) on Wednesday February 03, 2010 @05:28PM (#31015072) Homepage

    There are alignment tricks with SSD around their large erase blocks, so you have to be careful partitioning.

    Also, consumer-grade MHC SSDs are _not_ tremendously faster than spinning disks in transfer speed. Maybe 20%. Access time is where SSDs shine, 0.2 ms vs 8-10ms .

    A simple scheme I use is to put the OS & small, frequent datafiles on SSD, and large [image] files on platter.

    This might not help large databases with sparse access, but lots of RAM disk cache should be better. IIRC Seagate had a disk with flash boost, but had trouble with it.

  • Re:Holy carp! (Score:3, Insightful)

    by ftobin (48814) * on Wednesday February 03, 2010 @05:50PM (#31015338) Homepage
    While that is true in many cases, when one drive dies you will get much better read and write performance out of RAID 1 than RAID 0.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (9) Dammit, little-endian systems *are* more consistent!

Working...