From owner-freebsd-fs@FreeBSD.ORG Tue Apr 9 02:06:00 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4333273F; Tue, 9 Apr 2013 02:06:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 01408964; Tue, 9 Apr 2013 02:05:59 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r3925ljm085516 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 8 Apr 2013 19:05:51 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51637776.8010001@freebsd.org> Date: Tue, 09 Apr 2013 10:05:42 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: When will we see TRIM support for GELI volumes ? References: <51479D54.1040509@gibfest.dk> <20130319082732.GB1367@garage.freebsd.pl> In-Reply-To: <20130319082732.GB1367@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:06:00 -0000 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