Date: Wed, 14 Nov 2012 14:51:22 +1100 From: Stephen McKay <smckay@internode.on.net> To: Tom Evans <tevans.uk@googlemail.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org>, Stephen McKay <smckay@internode.on.net> Subject: Re: SSD recommendations for ZFS cache/log Message-ID: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> In-Reply-To: <CAFHbX1K-NPuAy5tW0N8=sJD=CU0Q1Pm3ZDkVkE%2BdjpCsD1U8_Q@mail.gmail.com> from Tom Evans at "Thu, 08 Nov 2012 21:07:24 -0000" References: <CAFHbX1K-NPuAy5tW0N8=sJD=CU0Q1Pm3ZDkVkE%2BdjpCsD1U8_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57ac1f$gf3rkl>