From owner-freebsd-fs@FreeBSD.ORG Wed Nov 14 06:34:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A928F8C0 for ; Wed, 14 Nov 2012 06:34:02 +0000 (UTC) (envelope-from spork@bway.net) Received: from smtp3.bway.net (smtp3.bway.net [216.220.96.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0DC8FC0C for ; Wed, 14 Nov 2012 06:34:01 +0000 (UTC) Received: from toasty.sporklab.com (foon.sporktines.com [96.57.144.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp3.bway.net (Postfix) with ESMTPSA id 08B2A95868; Wed, 14 Nov 2012 01:25:22 -0500 (EST) References: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> In-Reply-To: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Charles Sprickman Subject: Re: SSD recommendations for ZFS cache/log Date: Wed, 14 Nov 2012 01:25:22 -0500 To: Stephen McKay X-Mailer: Apple Mail (2.1084) Cc: Tom Evans , FreeBSD FS 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: Wed, 14 Nov 2012 06:34:03 -0000 On Nov 13, 2012, at 10:51 PM, Stephen McKay wrote: > On Thursday, 8th November 2012, Tom Evans wrote: >=20 >> I'm upgrading my home ZFS setup, and want to speed things up a bit by >> adding some SSDs for cache/log. I was hoping some more experienced >> heads could offer some advice on what I've gleaned so far. >=20 > Before you get excited about SSD for ZIL, measure your synchronous > write rate. If you have a mostly async load, you may get little > or zero improvement. >=20 > To measure ZIL activity, install dtrace and run Richard Elling's > zilstat script. Everyone with more than a passing interest in ZFS > should do this. Measurement always beats speculation. >=20 > On my workstation, I have sync writes only during email delivery, > and for that I'm willing to spend the extra few milliseconds a > hard disk takes so that I don't have to risk my data on a consumer > grade SSD. >=20 > I have no way to determine in advance the behaviour of an SSD on > power failure so I assume all the ones I can afford have bad > behaviour. :-) I know that expensive ones contain capacitors so > that power failures do not corrupt their contents. By the nature > of advertising (from which we know that any feature not excessively > hyped must therefore not be supported), we must conclude that other > SSDs by normal operation corrupt blocks on power failure. >=20 > So, that puts SSDs (that I can afford) behind standard disks for > reliability, plus I wouldn't benefit much from the speed, so I don't > use an SSD for ZIL. >=20 > Even if you have a sync heavy load (NFS server, say, or perhaps a > time machine server via netatalk), the right answer might be to > subvert those protocols so they become async. (Maybe nothing you > do with those protocols actually depends on their sync guarantees, > or perhaps you can recover easily from failure by restarting.) > You'll only know if you have to make decisions like this (expensive > reliable SSD for ZIL vs cheating at protocols) if you measure. So, > measure! >=20 > As for L2ARC, do you need it? It's harder to tell in advance that > a cache device would be useful, but if you have sufficient RAM for > your purposes, you may not need it. Sufficient could be approximately > 1GB per 1TB of disk (other rules of thumb exist). >=20 > If you enable dedup, you are unlikely to have sufficient RAM! So > in this case L2ARC may be advisable. Even then, performance when > using dedup may be less than you would hope for, so I recommend > against enabling dedup. >=20 > Remember that L2ARC is not persistent. It takes time to warm up. > If you reboot often, you will get little to no use from it. If > you leave your machine on all the time, eventually everything > frequently used will end up in there. But, if you don't use all > your RAM for ARC before you reboot anyway, your L2ARC will be > (essentially) unused. Again, you have to measure at least a little > bit (perhaps using the zfs-stats port) before you know. >=20 > On the plus side, a corrupt L2ARC shouldn't do any more than require > a reboot, so it's safe to experiment with cheap SSDs. >=20 >> The drives I am thinking of getting are either Intel 330, Intel 520, >> Crucial M4 RealSSD or Samsung 830, all in their 120/128GB variants. >=20 > Do any of these contain capacitors for use when power fails? =20 I may be out of date on this, but when I last looked, the Intel 320s were the only "consumer" drives that were safe: = http://newsroom.intel.com/servlet/JiveServlet/download/38-4324/Intel_SSD_3= 20_Series_Enhance_Power_Loss_Technology_Brief.pdf (apologies for the = pdf, but there's Intel actually saying the drives are safe) This expands on it a bit: http://blog.2ndquadrant.com/intel_ssd_now_off_the_sherr_sh/ And this post contains results of some "pull the plug" tests: = http://archives.postgresql.org/message-id/4D9D1FC3.4020207@2ndQuadrant.com= This post also contains some interesting thoughts on the lifetime of = these drives: http://blog.2ndquadrant.com/intel_ssds_lifetime_and_the_32/ Charles > If not > then I'd assume they are unsafe for use as ZIL and would limit them > to L2ARC. If you can show that any of these somehow avoid corruption > on power failure without a capacitor system, I'd love to know how that > works! >=20 > Cheers, >=20 > Stephen. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"