While generally available for software RAID systems, except AppleRAID, the TRIM command is normally not supported by hardware RAID systems.Įnabling TRIM doesn’t automatically improve performance, and in some circumstances can instead impair performance.
Operating systems, including macOS, gained TRIM support around 2010, but this has proved quite complex and varied by type of SSD, and by file system. This allows the SSD controller to erase that block, and maintains good write performance even under heavy use with limited free space. To avoid incurring such overhead, the operating system can maintain a list of blocks which are no longer in use, and once a block becomes unused, it can inform the SSD’s firmware that the block can now be re-used. This is commonly addressed by relocating any other retained data within the block, so enabling that block to be erased ready to receive the new data. This is complicated by the fact that data is written in pages of 4-16 kB, but erase commands always affect complete blocks, which typically consist of 128-512 pages. However, before NAND flash memory cells used in SSDs can be re-used for writing, their contents must be erased, a process which makes writing to them significantly slower. When re-using those blocks for new files only requires that they are rewritten, as on a hard disk, that’s not a problem, as the disk controller can choose to reuse them whenever it wants without any side effects. On any storage medium, the file system normally deletes files by marking their storage blocks as being no longer in use. This isn’t an abbreviation, but refers to the TRIM command, which is central to this issue. With many Mac users switching from hard disk storage to SSDs, and following my recent article about adding a two-SSD external enclosure, I thought it might be useful to look at some commonly-raised issues about SSDs: TRIM, wear levelling, and how they interact (or don’t) with macOS, particularly APFS.
0 kommentar(er)
