Date: Tue, 09 Apr 2013 10:05:42 +0800 From: Julian Elischer <julian@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: When will we see TRIM support for GELI volumes ? Message-ID: <51637776.8010001@freebsd.org> In-Reply-To: <20130319082732.GB1367@garage.freebsd.pl> References: <51479D54.1040509@gibfest.dk> <20130319082732.GB1367@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/19/13 4:27 PM, Pawel Jakub Dawidek wrote: > This is not what I see. On one of my SSDs in my laptop I've two > partitions, both running ZFS, but one of them on top of GELI. I > don't use ZFS TRIM yet, as I see no slowdown whatsoever. How can you > say this is lack of TRIM slowing your writes? The performance > degraded over time? For those readers wondering what all teh fuss about TRIM and SSDs is about: A quick description as to why TRIM is useful..... When doing a long sequence of writes on an SSD you eventually run out of free chunks of flash. When you do, an existing written chunk (or actual a bunch of them) is rewritten and the free space recovered using regular garbage collection techniques and defragmentation. If the chunks rewritten are 80 % full (20% is data that has been replaced and is not not of interest), then you need to rewrite 5 of them to get a complete new empty chunk of flash. This is called "Write Amplification" (WA). SO if you are writing,youare competing with the internal garbage collection process, except that it is producing 8 times as much data as you are (reading AND writing 80% of 5 chunks in the same time that you write one chunk. Thus your through put is going to be limited to 1/9th of the bandwidth of the flash. This is a huge drop in performance when you "hit the wall". SSDs have an internal path for this which is higher performance, so the drop may be less in practice, but it will still be there. If you have TRIM, and assume that an additional 20% of the drive is 'available' because it is not in use by the filesystem, then when we re-do the calculations we find that we only need to rewrite 2.5 chunks, and each one has only 60% data, so WA is 2 x 2.5 x 0.6, = 3.. in other words the internal process is using only 3 times as much of the flash bandwidth as you are. so your throughput can be 1/4 of the max instead of 1/9 of the max. this is a > 100% improvement. In addition, you are rewriting and erasing each chunk half as many times. so the SSD should last twice as long.. Julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51637776.8010001>