> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Erik Trimble > > SSDs do Garbage Collection when the controller has spare cycles. I'm not > certain if there is a time factor (i.e. is it periodic, or just when > there's time in the controller's queue). So, theoretically, TRIM helps > GC when the drive is at low utilization, but not when the SSD is under > significant load. Under high load, the SSD doesn't have the luxury of > searching the NAND for "unused" blocks, aggregating them, writing them > to a new page, and then erasing the old location. It has to allocate > stuff NOW, so it goes right to the dreaded read-modify-erase-write > cycle. Even under high load, the SSD can "process" the TRIM request > (i.e. it will mark a block as unused), but that's not useful until a GC > is performed (unless you are so lucky as to mark an *entire* page as > unused), so, it doesn't really matter. The GC run is what "fixes" the > NAND allocation, not the TRIM command itself.
This is really all a detail which is device specific. If the SSD controller is designed to do so, it can simultaneously erase one block on one bank, while performing RMEW or whatever operation on another bank. Again, I don't know if/when/which drives are built with that design, but I know it's not architecturally impossible. In which case, the TRIM would be useful, even for devices that are working under maximum load. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
