Continuing the refresh of
MacNN, we've launched some testing initiatives. The first, a
rundown of iTunes Match/Music problems with stored libraries is still underway, and we're hoping for more information later this week. The second: a close look at Apple's Trim activation for third-party SSDs, which was introduced in the launch of 10.10.4 -- and we've got some initial results to report.
History
Solid state drives (SSDs) are very fast, relying on flash cells to store data rather than spinning platters like conventional hard drives. The drive speed is generated by both the speed of the media as a whole, as well as parallelism, where the data is broken up across the range of flash cells, in a sort of
de facto striped RAID.
In general, pieces of a file won't occupy an entire block of space on the drive, only part of it. So, when a file is deleted, the OS "forgets" where the file is -- but the data is still physically present, and generally scattered all over the SSD.
Regardless of how much data has to be written to a block, a SSD has to process the entire block when it is writing. A write to a completely empty block is faster, as the drive doesn't have to copy the partially-full block to cache, and make the changes in cache before it completely overwrites the cell. If the block was empty in the first place, then the write is faster, since the cache isn't involved. While a drive is idle, the Trim feature -- if needed -- cleans up partially-full cells, allowing for fastest writes without having to swap to the drive's cache.
As we mentioned earlier this month following the OS X 10.10.4 update, Apple has implemented a way to
enable Trim for third-party SSDs, without resorting to a potentially-unsafe third party hack. However, prior to executing the terminal command to turn the feature on, Apple issues a stern warning, making it perfectly clear that the risk of data loss falls squarely in the hands of the user.
Reports have circulated about various Linux deployments
having issues with Trim data collection, with drives corrupting data under the open-source OS. Given the reports from the Linux side, and Apple's warning, we thought we'd test the issue on OS X.
There are two types of Trim -- queued, and sequential. We're testing sequential Trim, as implemented by the drive's firmware.
Testing Gear
We've got four SSDs from Samsung for this round of testing: either old retail stock, or original firmware and in-use for some time. On the testing block are the 840 EVO and Pro, and the 850 EVO and Pro drives, all 2.5-inch size, and 512GB capacity. All of the drives are pre-loaded with 200GB of data, which isn't modified in any way by the testing process.
The testing hardware is a 2012 i7 Mac mini running OS X 10.10.4. Connected to the Mac mini to support the drives are a
RocketStor 5212 Thunderbolt SATA dock, and a
dual-channel USB 3.0 RocketStor 5122B dock. All of the power supplies for the hardware are connected to an uninterruptible power supply, to prevent power outages or brownouts from effecting the testing process or inducing any SSD failure.
Protocol
Transferred files vary in size from 64KB through 6.3GB, adding up to 350GB per transfer. The drive copies were set up "round robin," progressing through drives one through four, one copy at a time. When a copy option off the drive was completed, the data was deleted through a normal Finder move to trash and empty trash routine.
Drives sat completely idle between transfer rounds other than OS indexing, giving each drive as much time idle as both reading and writing, and more than enough time for Trim collection to begin between operations. At this time, each drive has seen over 300TB of data copied to and from the drive.
Initial Conclusions
So far, so good. We are seeing some cell failures, but since we're slamming the drives with well more data than a SSD will see in regular OS drive use, that's to be expected. What we're not seeing is any Trim-related data corruption.
The future of this test
We've already started phase two -- all of the drives have been updated to the most recent version of the firmware, some of which rectified a different slow data access and writing issue. The "round robin" data moves is now underway, and will be complete in about 11 days. We're not expecting any problems, other than more cell failures. As we explained above, this is normal, expected, and compensated for by the drive firmware.
We're aware that the test isn't perfect. It is an accelerated process, where we're artificially loading and unloading the SSDs to implement the idle Trim feature faster than normal use. Our use pattern on the drives is far heavier than normal OS drive usage, and less sporadic -- a SSD with an installed OS is "tickled" a lot, for virtual memory, OS file access, app loading, and the like. What we're doing is more akin to constant use of the drive for a Photoshop scratch disk.
What this test is not is a comprehensive test of Trim's reliability under OS X and with all SSDs ever manufactured. Results specifically apply only to the Samsung 840 and 850 Pro and EVO series. This test could have been performed under Windows as well, as the real issue here is the drive's firmware routines, and less about any "implementation" by Apple, as all Apple did was provide a tool to enable the feature in firmware.
MacNN will report back when the second phase of the testing is complete. We are watching for more reports of drive issues with Trim, and will consider adding drives from other manufacturers to the test rig -- if you've got a drive in mind, either leave a comment here or
let us know in an email..
Top