Date: Wed, 11 May 2011 18:38:49 -0400 From: Jason Hellenthal <jhell@DataIX.net> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: How to enable cache and logs. Message-ID: <20110511223849.GA65193@DataIX.net> In-Reply-To: <20110511120830.GA37515@icarus.home.lan> References: <4DCA5620.1030203@dannysplace.net> <20110511100655.GA35129@icarus.home.lan> <4DCA66CF.7070608@digsys.bg> <20110511105117.GA36571@icarus.home.lan> <4DCA7056.20200@digsys.bg> <20110511120830.GA37515@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeremy, On Wed, May 11, 2011 at 05:08:30AM -0700, Jeremy Chadwick wrote: > On Wed, May 11, 2011 at 02:17:42PM +0300, Daniel Kalchev wrote: > > On 11.05.11 13:51, Jeremy Chadwick wrote: > > >Furthermore, TRIM support doesn't exist with ZFS on FreeBSD, so folks > > >should also keep that in mind when putting an SSD into use in this > > >fashion. > > > > By the way, what would be the use of TRIM for SLOG and L2ARC devices? > > I see absolutely no benefit from TRIM for the L2ARC, because it is > > written slowly (on purpose). Any current, or 1-2 generations back SSD > > would handle that write load without TRIM and without any performance > > degradation. > > > > Perhaps TRIM helps with the SLOG. But then, it is wise to use SLC > > SSD for the SLOG, for many reasons. The write regions on the SLC > > NAND should be smaller (my wild guess, current practice may differ) > > and the need for rewriting will be small. If you don't need to > > rewrite already written data, TRIM does not help. Also, as far as I > > understand, most "serious" SSDs (typical for SLC I guess) would have > > twice or more the advertised size and always write to fresh cells, > > scheduling an background erase of the 'overwritten' cell. >=20 > AFAIK, drive manufacturers do not disclose just how much reallocation > space they keep available on an SSD. I'd rather not speculate as to how > much, as I'm certain it varies per vendor. >=20 Lets not forget here: The size of the separate log device may be quite=20 small. A rule of thumb is that you should size the separate log to be able= =20 to handle 10 seconds of your expected synchronous write workload. It would= =20 be rare to need more than 100 MB in a separate log device, but the=20 separate log must be at least 64 MB. http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide So in other words how much is TRIM really even effective give the above ? Even with a high database write load on the disks at full compacity of the= =20 incoming link I would find it hard to believe that anyone could get the=20 ZIL to even come close to 512MB. Given most SSD's come at a size greater than 32GB I hope this comes as a=20 early reminder that the ZIL you are buying that disk for is only going to= =20 be using a small percent of that disk and I hope you justify cost over its= =20 actual use. If you do happen to justify creating a ZIL for your pool then= =20 I hope that you partition it wisely to make use of the rest of the space=20 that is untouched. For all other cases I would reccomend if you still want to have a ZIL that= =20 you take some sort of PCI->SD CARD or USB stick into account with=20 mirroring.=20 --=20 Regards, (jhell) Jason Hellenthal --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJNyw/5AAoJEJBXh4mJ2FR+besH/39USB9nnfhl5wL/rH+i7lpY 7lWVW48D0V8kbb2IAOSyGkIrUsvBqdHWmS6FJ5aYPzcrQVJg/ipiuY9c4n/SB9yy k7wF4PgU3uFFyluEKofsRLFtccCd+a5+U5QEdgoT2HXtcI6SNC0tk6dwUJL1M0uu Rzc3g7RQWF1hauDna7Mle13G43iQQThOTnpzWFVQFISQv3Nve/pYUVVXKKwS5e+n g+pS6NkImO6pb070BrAEwv4H4Xm0VBaFRIi2qV1Uc0J350vXjNIfWMBEO6Q4JNWV vBATQh7xR/OyttVXfAVnaohxdKsYhr34VqDdHjfSCsRlPZaH0ifSq6C0QLQeFhk= =o/7q -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110511223849.GA65193>