OCZ Wants To Cache Your HDD With an SSD 189
sl4shd0rk writes "OCZ is coming out with Synapse Cache; an SSD cache for your hard drive. The SSD runs software that copies data into the cache from your hard drive as you work with it. The data sits on the SSD until it gets less activity and gets flushed to the hard disk. Aside from boosting your IOPS to 10k/75k (read/write), the SSD also supports AES encryption, SMART and TRIM."
Re:Good idea, how will the implementation be ? (Score:5, Informative)
The SSD itself is a Sandforce 2281-based MLC drive with 50% overprovision for redundancy. Unless they've really screwed the firmware, it should be just fine, though no word on how it competes in price with other drives of similar size.
The caching function(unlike the Seagate hybrid units) is simply software: Supports Windows 7, no BIOS goo or specialized SATA features required; plugs into the OS somewhere in the storage handling area and shuffles data between the main mechanical HDD and the designated cache SSD.
On the plus side, that should(at least conceivably) give it considerably higher-level knowledge of what the OS is doing with which to make caching decisions(unlike caching firmware, which only has the SATA commands to go on). On the minus side, it means Win7 only, and your storage system is Not the place you want potentially flaky code, so if they aren't on the ball, we could see some serious bluescreening and/or OS hosing going on....
Re:SSD Cache and corruption (Score:3, Informative)
Obv I have no idea how OCZ plans on doing this, but I can tell you what a standard journaling fs does.
In any event, how well can this device recover from a dirty-cache shutdown?
Chances are this cache is transparent. The blocks translate to vblocks which map to physical blocks on the rotational media. A "dirty" block is a vblock which hasn't been committed to the physical block. However, this is transparent to the filesystem. When the system comes back up and the journal is replayed at say, some operation 10, and we find the relevant blocks for op 10 which happen to be vblocks in the SSD, the write is stable. It's a NOOP from the filesystem perspective.
What happens if the device just dies? Will I still be able to mount the HDD and recover data?
This is the same as a single, non-tiered, drive dying. Same semantics- cache is dead is equivalent to the drive being dead. That is to say unless the journal and superblock live somewhere else. IIRC ext2/3 keeps the initial copy of the superblock in a few places on the drive. Depending on which you can recover, you'll get a version of the filesystem (likely the one when you first created the fs, i.e. an empty fs). In short, pay attention to your SMART data, and always (ALWAYS!) backup.
It would be interesting to see how a journaling file system handles the abstraction of one volume read/written between two different drives. Were not talking about RAID5 here where you at least have parity data to recover from.
Most journals arent like NVRAM and don't follow the copy on write semantic. Journal replay is usually a data-loss event if all writes weren't stable before the replay. With that in mind, most volume managers (the original "VM"!) allow your fs to write to as many drives as the vm allows. This seems no different. But yeah, maybe they're doing something smarter here.