[zfs-discuss] Pure SSD Pool

Eric Sproul
Tue, 12 Jul 2011 14:41:18 -0000

On Tue, Jul 12, 2011 at 1:06 AM, Brandon High <bhigh at freaks.com>
wrote:
> On Mon, Jul 11, 2011 at 7:03 AM, Eric Sproul <esproul at 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