From owner-freebsd-fs@FreeBSD.ORG Wed Nov 14 04:26:00 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 3F7DBB59 for ; Wed, 14 Nov 2012 04:26:00 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id E65C08FC14 for ; Wed, 14 Nov 2012 04:25:59 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=GlY1a8 upBE0n1YZpMU/uxfJ+lN0scza7d+AWl4sVRE9fPuLcbJdHiWXIw/iX38TjphwH11 h0KIYF46s6yLjAAWVlTenI8xn04nr/WtRdtnEBe/efZ+eIacpezR9myr6OYq9Ccr 7N5I1OzUgaNa6gxDQSmKugbIEQwwfs/qk26VI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=18jScapueb5t X1Lla5y/06p/6zscRRS8w3Q9uBqP3x8=; b=TDiV60WPLwoUjmFUCIhvJzLNfW5Q azRhtKEdHll0RLVKi/Bxo/X8tVud+rWbBhC+u04VAGY+hr0Mpxwal4wDu6xpIv4Y 5AJ78o8oA3L4NuW6jhzD+o68xlUqzwIrOMG8NaNPUxygZ4OGV0G8oOBE0N6BvaQ6 /dmIFjlJwEkIT98= Received: (qmail 17092 invoked from network); 13 Nov 2012 22:25:51 -0600 Received: from unknown (HELO ?10.10.0.115?) (bryan@shatow.net@10.10.0.115) by sweb.xzibition.com with ESMTPA; 13 Nov 2012 22:25:51 -0600 Message-ID: <50A31D48.3000700@shatow.net> Date: Tue, 13 Nov 2012 22:25:44 -0600 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen McKay Subject: Re: SSD recommendations for ZFS cache/log References: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> In-Reply-To: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> X-Enigmail-Version: 1.4.5 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD FS , Eitan Adler 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 04:26:00 -0000 On 11/13/2012 9:51 PM, Stephen McKay wrote: > On Thursday, 8th November 2012, Tom Evans wrote: > >> 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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! > > 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). > > 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. > > 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. > > 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. > >> 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. > > Do any of these contain capacitors for use when power fails? 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! > > Cheers, > IMHO this whole post should be enshrined into an FAQ or manpage or wiki. It's very informative and compelling. > 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" >