On 7/25/2011 4:28 AM, Tomas Ögren wrote:
On 25 July, 2011 - Erik Trimble sent me these 2,0K bytes:

On 7/25/2011 3:32 AM, Orvar Korvar wrote:
How long have you been using a SSD? Do you see any performance decrease? I 
mean, ZFS does not support TRIM, so I wonder about long term effects...
Frankly, for the kind of use that ZFS puts on a SSD, TRIM makes no
impact whatsoever.

TRIM is primarily useful for low-volume changes - that is, for a
filesystem that generally has few deletes over time (i.e. rate of change
is low).

Using a SSD as a ZIL or L2ARC device puts a very high write load on the
device (even as an L2ARC, there is a considerably higher write load than
a "typical" filesystem use).   SSDs in such a configuration can't really
make use of TRIM, and depend on the internal SSD controller block
re-allocation algorithms to improve block layout.

Now, if you're using the SSD as primary media (i.e. in place of a Hard
Drive), there is a possibility that TRIM could help.  I honestly can't
be sure that it would help, however, as ZFS's Copy-on-Write nature means
that it tends to write entire pages of blocks, rather than just small
blocks. Which is fine from the SSD's standpoint.
You still need the flash erase cycle.

On a related note:  I've been using a OCZ Vertex 2 as my primary drive
in a laptop, which runs Windows XP (no TRIM support). I haven't noticed
any dropoff in performance in the year its be in service.  I'm doing
typical productivity laptop-ish things (no compiling, etc.), so it
appears that the internal SSD controller is more than smart enough to
compensate even without TRIM.


Honestly, I think TRIM isn't really useful for anyone.  It took too long
to get pushed out to the OSes, and the SSD vendors seem to have just
compensated by making a smarter controller able to do better
reallocation.  Which, to me, is the better ideal, in any case.
Bullshit. I just got a OCZ Vertex 3, and the first fill was 450-500MB/s.
Second and sequent fills are at half that speed. I'm quite confident
that it's due to the flash erase cycle that's needed, and if stuff can
be TRIM:ed (and thus flash erased as well), speed would be regained.
Overwriting an previously used block requires a flash erase, and if that
can be done in the background when the timing is not critical instead of
just before you can actually write the block you want, performance will
increase.

/Tomas

I should have been more clear: I consider the "native" speed of a SSD to be that which is obtained AFTER you've filled the entire drive once. That is, once you've blown through the extra reserve NAND, and are now into the full read/erase/write cycle. IMHO, that's really what the sustained performance of an SSD is, not the bogus numbers reported by venders.

TRIM is really only useful for drives which have a low enough load factor to do background GC on unused blocks. For ZFS, that *might* be the case when the SSD is used as primary backing store, but certainly isn't the case when it's used as ZIL or L2ARC.

Even with TRIM, performance after a complete fill of the SSD will drop noticeable, as the SSD has to do GC sometime. You might not notice it right away given your usage pattern, but, with OR without TRIM, a "used" SSD under load will perform the same.

--
Erik Trimble
Java Platform Group Infrastructure
Mailstop:  usca22-317
Phone:  x67195
Santa Clara, CA
Timezone: US/Pacific (UTC-0800)

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to