From owner-freebsd-fs@FreeBSD.ORG Wed Nov 14 06:37:18 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 E693299F for ; Wed, 14 Nov 2012 06:37:18 +0000 (UTC) (envelope-from smckay@internode.on.net) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by mx1.freebsd.org (Postfix) with ESMTP id 355558FC14 for ; Wed, 14 Nov 2012 06:37:18 +0000 (UTC) Message-Id: <57ac1f$gf6p7c@ipmail05.adl6.internode.on.net> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AitWAJI6o1ABigXDPGdsb2JhbAAuFoU0hSO4ZxgBAQEBODSCHgEBBAF5EAgDDQsTG0MUBhMZh2sFx04CAQIWhQuBBgOcCQONNg Received: from unknown (HELO localhost) ([1.138.5.195]) by ipmail05.adl6.internode.on.net with ESMTP; 14 Nov 2012 17:07:16 +1030 From: Stephen McKay To: Chris BeHanna Subject: Re: SSD recommendations for ZFS cache/log References: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net><943159E4-8824-4767-96E1-89E8EC69DCDF@behanna.org> In-Reply-To: <943159E4-8824-4767-96E1-89E8EC69DCDF@behanna.org> from Chris BeHanna at "Tue, 13 Nov 2012 22:18:54 -0600" Date: Wed, 14 Nov 2012 17:37:08 +1100 Cc: FreeBSD FS , Stephen McKay 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:37:19 -0000 On Tuesday, 13th November 2012, Chris BeHanna wrote: >On Nov 13, 2012, at 21:51, Stephen McKay wrote: > >> [...lots of good advice about measuring, and lots of good advice about L2ARC...] I'm glad people found what I wrote useful. I'll have to rant more often. :-) >> 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. > >If you'll pardon what may be an ignorant question, does this >matter if you have your machine on a UPS, especially if you run >upsmon or nut to do a graceful shutdown when there are n minutes >of battery remaining? I would still care. But then, I assume my hardware is out to get me. :-) In the end, it's a matter of risk assessment. How valuable your data is vs how difficult it is to recover vs how likely it is to be lost. High value data that cannot be recovered should be stored (backed up) in many places on highly reliable media because even a low risk of loss is bad(1). Low value data can be treated more roughly, and maybe occasional (detectable) corruption or loss is OK. The difficulty is in how we can calculate the chance of loss when we have no published statistics on power failure corruption rates in SSDs. Multiply that by the chance your UPS may fail(2) (which I'm guessing you don't have a number for either), and we have what we hope is a very small number, but which might in reality be large enough to cause grief. If I ran a bank, my ZIL would likely be a redundant array of battery backed RAM disks (that's the most expensive and fastest sort, you can reduce your life expectancy simply by reading the price list). And my power supply would be redundant. And my UPS would be redundant. And I'd do generator tests frequently. And the armed guards would keep cleaners out of the computer room. And ... But at home, you have to make your best guess and go from there. As I've said before, the end result of my calculations was to have no SSD ZIL at all. I think for most people this is an entirely reasonable situation. Cheers, Stephen. (1) There's a long discussion of disk redundancy (mirror vs raidz, etc) and backup strategies (periodic vs continuous, off/on-line, on/off-site, automated/ad hoc) to mitigate hardware failures, software errors, system administrator fumbles, hacker attacks and the plain disregard the universe has for you that I've left out here but which matters at least as much as broken SSDs do. (2) UPS failure can include the owner tripping over the power cord or accidentally switching it off. Watching someone accidentally switch off a room full of computers this way caused much merriment. No, wait! It caused us all several days of pain. :-(