Date: Thu, 5 May 2011 15:31:56 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-fs@FreeBSD.org, Alexander Motin <mav@FreeBSD.org> Subject: Re: TRIM clustering Message-ID: <20110505133156.GE14661@garage.freebsd.pl> In-Reply-To: <20110503134826.712070yt2urhxp8g@webmail.leidinger.net> References: <4DBBB20A.5050102@FreeBSD.org> <20110430072831.GA65598@icarus.home.lan> <20110501000656.00007ea1@unknown> <20110501133752.GC3245@garage.freebsd.pl> <20110503134826.712070yt2urhxp8g@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--imjhCm/Pyz7Rq5F2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 03, 2011 at 01:48:26PM +0200, Alexander Leidinger wrote: > Quoting Pawel Jakub Dawidek <pjd@FreeBSD.org> (from Sun, 1 May 2011 > 15:37:52 +0200): >=20 > >On Sun, May 01, 2011 at 12:06:56AM +0200, Alexander Leidinger wrote: > >>On Sat, 30 Apr 2011 00:28:31 -0700 Jeremy Chadwick > >><freebsd@jdc.parodius.com> 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. >=20 > 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. Doing TRIM for cache devices before first use might be slightly useful, but it may make the boot time longer. L2ARC is designed to work with very slow devices - if they cannot keep up we will simply not evict cache from ARC to L2ARC. That's not a big problem. Doing TRIM for cache devices at run time seems pointless to me. Optimal use is when cache device is 100% full, so new data replaces old data and there is no window where we could put TRIM. We would need to replace writes with trim+write, which will increase the latency. TRIM will be more useful for regular data within a pool and most useful for log devices as we do free blocks there and this is where latency is critical (log devices are there to reduce latency). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --imjhCm/Pyz7Rq5F2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk3CpssACgkQForvXbEpPzT6+QCdFVDXFHUJmgrv4BqkgWeLbqn2 bAoAoLyI0fjfMP5ZLAo6WS94/jevKKGh =6roC -----END PGP SIGNATURE----- --imjhCm/Pyz7Rq5F2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110505133156.GE14661>