From owner-freebsd-fs@FreeBSD.ORG Tue May 3 14:07:47 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 3B468106564A for ; Tue, 3 May 2011 14:07:47 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 96DAC8FC0A for ; Tue, 3 May 2011 14:07:46 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p43Db59L039034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2011 15:37:06 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p43DapMk069143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2011 15:36:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p43DPHG8002183; Tue, 3 May 2011 15:25:17 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p43DPHgm002182; Tue, 3 May 2011 15:25:17 +0200 (CEST) (envelope-from ticso) Date: Tue, 3 May 2011 15:25:17 +0200 From: Bernd Walter To: Alexander Leidinger Message-ID: <20110503132517.GF1549@cicely7.cicely.de> References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan> <20110501000656.00007ea1@unknown> <20110501133752.GC3245@garage.freebsd.pl> <20110503134826.712070yt2urhxp8g@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110503134826.712070yt2urhxp8g@webmail.leidinger.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de 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 Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 14:07:47 -0000 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. More interesting would be to have the cached data reboot persistent one day instead of TRIMing it. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.