== SSDs and the RAID resync problem By now, most people know that SSDs have a problem with long term use; their write speed degrades (sometimes dramatically) once enough data in total has been written to the SSD, even if the filesystem has lots of free space left (because you've written files and then deleted them). The way around this is for OSes to use the [[TRIM command http://en.wikipedia.org/wiki/TRIM_(SSD_command)]] to tell SSDs which parts of the device aren't used by the filesystem. It recently struck me that this has interesting implications for part of the [[RAID resync problem BigRAID5Problem]]. Support for TRIM isn't restricted to SSDs, so as OS support for TRIM gets more and more widespread (and better), block-level RAID devices can get better and better at knowing what blocks are actually in use and what blocks are free. This has all sorts of uses, the most obvious being that you don't have to copy free blocks when resyncing a RAID array. (This would also help the really smart enterprise RAID systems, which do things like create sparse arrays and then only allocate space as the array gets written to. TRIM support would let them deallocate unused space from these sparse arrays and thus probably make a bunch of storage admins rather happy.) This doesn't get 'dumb' block-level RAID quite up to [[the level of ZFS ../solaris/ZFSAndBigRaidProblem]], but it gets them much closer. (However, all of this probably won't happen very fast. Hardware RAID changes only slowly and hardware RAID vendors may wait to support TRIM until it's fairly widely supported in popular server OSes, so we could be looking at several years of delay.)