Sandforce SSD in a fusion drive- anyone tested this yet?

[elvisizer]

I'm curious how a sandforce based SSD will perform in a fusion drive setup. The reason I ask is that, as we all know, sandforce chipset SSD's use compression on data before writing to flash, so their performance varies in connection with how compressable the data being written is. One consequence of this is that sandforce SSD's have terrible performance on systems that have FileVault 2 enabled- since the SSD controller can't tell what any of the data is none of it gets compressed, and the performance suffers as a result.

Filevault 2 and fusion both create core storage logical volumes, so I'm wondering if that will be enough to trigger the problem or if the unencrypted fusion logical volume will allow the sandforce controller to do it's thing successfully . . .
Has anyone built their own fusion drive with a sandforce SSD and run some benchmarks on it?

 

[derbothaus]

Not yet. I may do an Intel 520 and 1TB Caviar Black. We'll see if I have the time.

 

[deconstruct60]

I
Filevault 2 and fusion both create core storage logical volumes, so I'm wondering if that will be enough to trigger the problem or if the unencrypted fusion logical volume will allow the sandforce controller to do it's thing successfully . . .

Encryption removes redundant information just as much as compression does. If the data is unencrypted, but stored on two disks it is a non issue.
Just using a logical volume has no significant impact.

If the Fusion Drive is filled with 80% compressed data that isn't used much, then the impact will be very low. If the "hot" files on the drives are compressed files then the impact is much higher, since they will be moved to the SSD.

While Sandforce drives are slower than peak, it is still substantially faster than a HDD. As long as the Fusion Drive is much faster than a sole HDD, it is better.

Performance isn't as big of an issue as lifetime. Writing a significant above average amount of compressed data to a Sandforce drive will cause it to wear out sooner. ( they store more metadata and without the extra pockets to stuff that data into, the write footprint expands. )

 

[elvisizer]

Encryption removes redundant information just as much as compression does.

full disk encryption definitely prevents the sandforce controller from analyzing and compressing data-- performance goes down to less than 80 MBps for write operations on sandforce SSDs that have filevault 2 or other FDE running on them-- suspiciously similar to the 70 MBps on writes I'm seeing from the fusion drive I built using an OWC mercury extreme pro (sandforce) SSD.

I ordered a samsung 830 yesterday so I'll swap out the OWC for that and then re-test, but right now it's looking like the performance hit you see with those controllers and FV2 also applies to fusion drives.

 

[deconstruct60]

I ordered a samsung 830 yesterday so I'll swap out the OWC for that and then re-test, but right now it's looking like the performance hit you see with those controllers and FV2 also applies to fusion drives.

Eh? If you have FV2 turned on it doesn't matter one lick whether it is a Fusion set up or a single device. The core issue is that the SSD is being sent blocks that are encrypted. If the encryption is worth anything then the data will have all the characteristics of random patterns. Hence, it can't be compressed.

If you want to test for an impact on fusion specifically then you'd turn encryption off. There is no "also applies" inference to be made by the your experiment.

The modern Sandforce drives support FDE. It is just they support it through the controller ( Opal http://en.wikipedia.org/wiki/Opal_Storage_Specification ) instead of the software implementations layers on top of the device. Unfortunately, OS X doesn't leverage standards and implements their own "home grown", proprietary solution.

Another part of the issue here is that Sandforce drives store data encrypted anyway. So encrypting on top of encrypting is somewhat a waste of effort and at the very least redundant. If encryption with FV2 is the primary objective then don't buy Sandforce drives. That has as much to do with FV2's design as it has with the Sandforce design.

 

[elvisizer]

Eh? If you have FV2 turned on it doesn't matter one lick whether it is a Fusion set up or a single device.

I never said I was running FV2 on the fusion test I've set up, and I'm not.

The core issue is that the SSD is being sent blocks that are encrypted. If the encryption is worth anything then the data will have all the characteristics of random patterns. Hence, it can't be compressed.

Right. Which is why everyone knows to avoid sandforce SSDs if you're going to use FV2.

If you want to test for an impact on fusion specifically then you'd turn encryption off.

Right. Which is exactly what I said I was doing in my original post.

The modern Sandforce drives support FDE. It is just they support it through the controller ( Opal http://en.wikipedia.org/wiki/Opal_Storage_Specification ) instead of the software implementations layers on top of the device. Unfortunately, OS X doesn't leverage standards and implements their own "home grown", proprietary solution.

Sandforce drives using the sf2281 or newer controllers can be opal compliant, yes, but there's still a hell of a lot of sandforce ssd's out there that use earlier revisions. My OWC drives both are sf1000 series, so they do not do hardware encryption. Also, nice FV2 trolling! FV2 is a bog-standard software FDE solution- sandforce drives have the same issues with ANY software FDE . . . like truecrypt, for instance.


Anyway, all of this is a tangent. I received the samsung ssd today, so I'll swap out the OWC and compare benchmark results tomorrow.

 

[peterson12]

Eh? If you have FV2 turned on it doesn't matter one lick whether it is a Fusion set up or a single device. The core issue is that the SSD is being sent blocks that are encrypted. If the encryption is worth anything then the data will have all the characteristics of random patterns. Hence, it can't be compressed.

If you want to test for an impact on fusion specifically then you'd turn encryption off. There is no "also applies" inference to be made by the your experiment.

The modern Sandforce drives support FDE. It is just they support it through the controller ( Opal http://en.wikipedia.org/wiki/Opal_Storage_Specification ) instead of the software implementations layers on top of the device. Unfortunately, OS X doesn't leverage standards and implements their own "home grown", proprietary solution.

Another part of the issue here is that Sandforce drives store data encrypted anyway. So encrypting on top of encrypting is somewhat a waste of effort and at the very least redundant. If encryption with FV2 is the primary objective then don't buy Sandforce drives. That has as much to do with FV2's design as it has with the Sandforce design.

I was going through an interesting reading on Sandforce Encryption. It explains the read & write latency very nicely.here is the link http://www.sandforce.com/userfiles/...-Conference_Security_7Myth_Dmitry_Obukhov.pdf.

 

[GermanyChris]

full disk encryption definitely prevents the sandforce controller from analyzing and compressing data-- performance goes down to less than 80 MBps for write operations on sandforce SSDs that have filevault 2 or other FDE running on them-- suspiciously similar to the 70 MBps on writes I'm seeing from the fusion drive I built using an OWC mercury extreme pro (sandforce) SSD.

I ordered a samsung 830 yesterday so I'll swap out the OWC for that and then re-test, but right now it's looking like the performance hit you see with those controllers and FV2 also applies to fusion drives.

My SF 1200 and 2200 series have never slowed that much with filevault. They never slowed enough for me to notice.

 

[deconstruct60]

I never said I was running FV2 on the fusion test I've set up, and I'm not.

If you are using jpeg, mpeg, or other compressed files to drive your MBps Fusion drive tests then pragmatically you are.

What is confusing is your assertion that there is some sort of coupling between Fusion and the corner cases that impact Sandforce drives. Nothing presented so far support that. Looks far more likely that the over-provision allocation of your specific drives may be significantly toasted and the drive slows down when 95% full. Of that a non-raid spec'ed sandforce drive is being deployed in a RAID setting. Either way, nothing new being illuminated here but old issues.

Also, nice FV2 trolling! FV2 is a bog-standard software FDE solution- sandforce drives have the same issues with ANY software FDE . . . like truecrypt, for instance.

Truecrpt is also proprietary. Your stab at labeling trolling is lame. And you claim of any software is false.

" ... SecureDoc supports all Trusted Computing Group (TCG) OPAL compliant Hard Drives. Our experience with SEDs goes back to 2007 when we introduced support for the Seagate Momentus Drive Trust self-encrypting drive. ... "
http://www.winmagic.com/support/competitive-checklist

It is purely a matter of the software implemented to use standards and not solely depend upon a proprietary solution.

 

[MatthewAMEL]

I have a 240GB OWC SSD with a 500GB Hitachi SpinPoint in a DIY FusionDrive in my MBP.

No problems.

Two notes:

Make sure you have version 5+ of the firmware for your Sandforce SSD.

Enable TRIM via the method of your choice. I used Grant Parnell's PERL script to enable mine.

Straight SSD performance was 560MB/sec reads, 518MB/sec writes, Fusion Drive is 192GB/sec reads, 145MB/sec writes. I have no idea how reliable BlackMagic is testing the FusionDrive.

IMHO, I think Apple is throwing a curve to all the established disk utilities out there. It's going to take a while for them to catch up with the features and gotchas associated with CoreStorage.

Filevault 2 is enabled on the drive.

 

[peterson12]

full disk encryption definitely prevents the sandforce controller from analyzing and compressing data-- performance goes down to less than 80 MBps for write operations on sandforce SSDs that have filevault 2 or other FDE running on them-- suspiciously similar to the 70 MBps on writes I'm seeing from the fusion drive I built using an OWC mercury extreme pro (sandforce) SSD.

I ordered a samsung 830 yesterday so I'll swap out the OWC for that and then re-test, but right now it's looking like the performance hit you see with those controllers and FV2 also applies to fusion drives.

When data is sent to the SSD it is encrypted already. Any program that sends encrypted data is redundant. Most people do not need to encrypt the data before it gets to the drive. In fact if you let the drive encrypt the data you save CPU resources. Then if you use SandForce the drive is already much faster than all other drives on writes so you benefit from two speed enhancements (1. No CPU load, and 2. the drive writes to SandForce are incredibly fast when you let it encrypt the data)

 

[Inconsequential]

I have a 240GB OWC SSD with a 500GB Hitachi SpinPoint in a DIY FusionDrive in my MBP.

No problems.

Two notes:

Make sure you have version 5+ of the firmware for your Sandforce SSD.

Enable TRIM via the method of your choice. I used Grant Parnell's PERL script to enable mine.

Straight SSD performance was 560MB/sec reads, 518MB/sec writes, Fusion Drive is 192GB/sec reads, 145MB/sec writes. I have no idea how reliable BlackMagic is testing the FusionDrive.

IMHO, I think Apple is throwing a curve to all the established disk utilities out there. It's going to take a while for them to catch up with the features and gotchas associated with CoreStorage.

Filevault 2 is enabled on the drive.

That isn't right, but it is the behavior I have with a 2TB 7200 + 160GB Intel X25-M.

You *should* be able to write to the SSD for 4GB at FULL SSD SPEEDS.

Problem is for some reason our drives arn't being emptied again, so only 500MB or so is actually written to the SSD before being pushed to the HDD, hence the increased read/write speeds, but not full SSD speeds.

I've actually turned it off as it wasn't working properly.