From owner-freebsd-fs@FreeBSD.ORG Tue May 3 14:33:43 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD8C106566C; Tue, 3 May 2011 14:33:43 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2BDB48FC19; Tue, 3 May 2011 14:33:42 +0000 (UTC) Received: from outgoing.leidinger.net (p5B155A42.dip.t-dialin.net [91.21.90.66]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E7DF3844017; Tue, 3 May 2011 16:33:27 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 0179011C6; Tue, 3 May 2011 16:33:24 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p43EXOnR046041; Tue, 3 May 2011 16:33:24 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 03 May 2011 16:33:24 +0200 Message-ID: <20110503163324.11285rolq1oyrnlc@webmail.leidinger.net> Date: Tue, 03 May 2011 16:33:24 +0200 From: Alexander Leidinger To: ticso@cicely.de, Bernd Walter References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan> <20110501000656.00007ea1@unknown> <20110501133752.GC3245@garage.freebsd.pl> <20110503134826.712070yt2urhxp8g@webmail.leidinger.net> <20110503132517.GF1549@cicely7.cicely.de> In-Reply-To: <20110503132517.GF1549@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E7DF3844017.A04FF X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0, required 6, autolearn=disabled) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1305038008.30478@0FRKaNgB0n/VcxxUkpbs+g X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org, Alexander Motin , Pawel Jakub Dawidek Subject: Re: TRIM clustering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 14:33:43 -0000 Quoting Bernd Walter (from Tue, 3 May 2011 15:25:17 +0200): > On Tue, May 03, 2011 at 01:48:26PM +0200, Alexander Leidinger wrote: >> Quoting Pawel Jakub Dawidek (from Sun, 1 May 2011 >> 15:37:52 +0200): >> >> >On Sun, May 01, 2011 at 12:06:56AM +0200, Alexander Leidinger wrote: >> >>On Sat, 30 Apr 2011 00:28:31 -0700 Jeremy Chadwick >> >> wrote: >> >> >> >>> On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote: >> >> >> >>> Other notes: TRIM needs to be supported on swap as well, and in my >> >>> opinion this is just as important as it being in UFS. I'm not sure >> >>> how one would implement that. >> >> >> >>This brings up the question if a ZFS cache (where the contents do not >> >>survive a reboot) is completely TRIMmed before used (and normally >> >>trimmed during use)... >> > >> >It is not trimmed at all. >> >> This does not sound like the optimal solution... is there a way to >> know the first access after boot/attach to a cache device? If yes, >> would it be possible to TRIM the complete provider (except for some >> static data which needs to be there) from this place? This would not >> solve the not TRIMmed during use part, put at least a reboot/reattach >> could provide a sane state. > > What would be the possible benefit? > I mean it's just until the device is filled, which won't happen that > regular in environments where cache devices make sense. If a cache is not full, it is not used well (or you do not access that much data, but in this case you do not have to worry). The benefit of the initial TRIM should be a faster cache-fill latency (if it matters or not depends upon your use-case/drive-channel-usage). Regarding the in-use-TRIMming... I agree that it is subject to discussion (and the use-case), but at least it looks like a more correct solution. If large objects are removed from the cache, following cache fills could have lower write latency. Again, if this matters or not depends upon your use-case/drive-channel-usage. > More interesting would be to have the cached data reboot persistent > one day instead of TRIMing it. I assume this would be more work than to teach it to TRIM (looking for low haning fruits), but in general I agree. Bye, Alexander. -- Fools rush in -- and get the best seats. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137