I have over 2,000 hours of operation at the time of this writing on a 4 disk array of these in a hardware RAID 5 on a MegaRAID 9361-8i controller. On the plus side this has partial power loss protection and RAIN protections and it looks like it covers what it needs to while the controller with RAID controller BBU covers the rest. They are also really fast and especially in a 4 disk RAID the performance is quite impressive.
One thing I am finding out is hardware RAID tends not to support TRIM. (Don't know of any hardware RAID controller that do, but sounds like software RAID will depending.) I have tried all kinds of things to reduce the amount of writing to these drives, but no matter what I do they are way higher than any other SSD I have. I started off averaging anywhere from .44 DWPD to .54 DWPD to physical media with a write amplification of 5 - 8. I have done a number of things to reduce the writing to the drives and reduce write amplification, but so far I have not seen this number drop by nearly as much as I would like. My latest calculations for a 2 week average is 0.36 DWPD to physical media with a write amplification in the 20 - 30 range depending on individual drives. In other words my total host writes have dropped off dramatically, but I have only been able to make a relatively small dent on what gets written to the physical media. While the drives are rated for 360 TBW for the 1 TB version I have, something interesting I have come across is SMART attribute 202. According to this once each drive (attribute 173) went over 30 cycles, attribute 202 went from 1% to 2%. This suggests the physical media writes possible are 1,500 P/E cycles. In other words the manufacturer anticipates a write amplification factor of a little over 4 in their estimate for how much you can write to the drive. My calculations are I have upwards of 11 years of operation before exceeding the physical P/E limit. The growing body of evidence is suggesting the background operations are being overly aggressive to the point where I feel confident enough to knock off a star, especially as I have seen Intel drives that seem to have this under much better control than Crucial/Micron has it. Maybe they need to learn from their flash partner on how to program their background routines such as GC (garbage collection) and wear leveling. Also the power_on_hours attributes tend to be way off. For example ~13.5 real days of continuous uptime gets reported at 10.2 days of uptime and each drive varies wildly in the uptime number reported even though they have all been on for about the same amount of time. Some things I have done to reduce "host writes" to the drive, which better highlights this issue of overly aggressive background operations are:
1. Over-provision by an addition 20%. I went the full measure by downloading Micron's utilities for Linux (for some reason Crucial, which is the same company does not have Linux utilities and their Windows GUI is a non functional piece of junk) and using the CLI tool to over-provision as the CLI tool is the only way that works. This tool specifically said that it 'sanitize'(es) the drive which should mean erased and thus even without trim that space should be permanently set aside for background operations. I suppose I can go back and do the manufacturer secure erase just in case the 'sanitize' operation while resizing did not actually free up the reserved space it should have, but it is a PITA erasing and restoring a system drive array, especially when one is so dubious that the end result would be any better.
2. Turned off atime. What this means under Linux / UNIX is every time a file is read from, its access time gets updated. The default it to update once every 24 hours so multiple read accesses over a short period does not cause a write storm (of atime updates written), but I am looking to get rid of any writes that are not necessary so I set the attribute in /etc/fstab to noatime.
3. Moved /var and swap to mechanical drives. /var is a place where Linux / UNIX does a number of small writes for various system tasks and state tr and tends to not be performance dependent, so it lives just fine on mechanical drives. The computer I stuck a 4 disk SSD array has lots of RAM, so I use swap more as an indicator that something has gone over-budget unexpectedly or if unused pages are determined to not need to be in RAM anymore. So for me it is fine if these (/var and swap) live on mechanical drives. In fact if swapping happened too quickly I might not notice there is a memory allocation problem, so defeating the purpose of why I really use swap while at the same time grinding these SSDs into the dirt. This is also done for my VMs.
4. Set the sync rate on the RAID controller to 120s. Especially as I am doing a redundant RAID 5, when the system is mostly idle, small writes are common, so it helps to provide time to group up writes into a stripe set. I was finding at the default 4s the writes on average were not very well grouped. Switching to 120s the host writes dropped dramatically as the writes became grouped much better. I have a super-cap and flash backup on the controller, so in the event of unexpected power loss this data sitting in the controller's cache will be preserved until the system is powered back on. There is actually a guide on the Internet suggesting to just use write through with SSDs for best random I/O performance with this RAID controller, but with drives like these the protection is partial, plus you want to do all you can to minimize writes to them. Maybe if you used real "Enterprise" SSDs with full capacitor backup on the drives you could comfortably use them in write through mode.
I would consider this drive acceptable for an entry level hardware RAID at home. Would probably toast these drives in no time flat in a more industrial or heavy use home / power user setting. Otherwise it would be cheaper to get enterprise class drives with full capacitor backup, generous over-provisioning already configured, and a reasonably high DWPD rating (at least 0.5 or higher depending on workload and probably 1.0 or more) as even for home use so you can get through the warranty period without voiding it way too early by exceeding the P/E cycle rating of the drives. Please note I am using these drives on a home computer and I have had a lot of non computer related distractions as of late, so am not banging on these anywhere near as hard as I would have in the past. While I have seen some SSDs at work go significantly (but not drastically) above and beyond their write endurance rating over the years (while at least 5 years old or younger), I have also had SSDs at home fail after about 6 years with tonnes of read errors while still well below their rated P/E cycle limit. Single or software RAID you probably have much better chance as my single SSD drive machines see 10 - 50x less writes to the physical media. Something that makes this acceptable for my RAID setup is even if the use was inline with my single drive systems, SSDs seem to have a limited shelf life. So with some tweaks I am fairly confident that I pushed down the writing to media down enough to see a full life of these drives as I suspect age will get them first like what has happened with all of my older flash media. I am just not happy that I could not go further and have larger margins like I should be able to, especially if the pace of work picks up on this system and I end up wearing these out prematurely after all due to the margin being eaten up by overzealous background operations on these drives.
| Hard Drive | 1 TB Solid State Drive |
|---|
