On Tue, Jul 12, 2011 at 1:06 AM, Brandon High <bh...@freaks.com> wrote: > On Mon, Jul 11, 2011 at 7:03 AM, Eric Sproul <espr...@omniti.com> wrote: >> Interesting-- what is the suspected impact of not having TRIM support? > > There shouldn't be much, since zfs isn't changing data in place. Any > drive with reasonable garbage collection (which is pretty much > everything these days) should be fine until the volume gets very full.
But that's exactly the problem-- ZFS being copy-on-write will eventually have written to all of the available LBA addresses on the drive, regardless of how much live data exists. It's the rate of change, in other words, rather than the absolute amount that gets us into trouble with SSDs. The SSD has no way of knowing what blocks contain live data and which have been freed, because the OS never tells it (that's what TRIM is supposed to do). So after ZFS has written to almost every LBA, it starts writing to addresses previously used (and freed by ZFS, but unknown to the SSD), so the SSD has to erase the cell before it can be written anew. This incurs a heavy performance penalty and seems like a worst-case-scenario use case. Now, others have hinted that certain controllers are better than others in the absence of TRIM, but I don't see how GC could know what blocks are available to be erased without information from the OS. Those with deep knowledge of SSD models/controllers: how does the Intel 320 perform under ZFS as primary storage (not ZIL or L2ARC)? Eric _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
