Date: Tue, 13 Nov 2012 22:25:44 -0600 From: Bryan Drewery <bryan@shatow.net> To: Stephen McKay <smckay@internode.on.net> Cc: FreeBSD FS <freebsd-fs@freebsd.org>, Eitan Adler <eadler@FreeBSD.org> Subject: Re: SSD recommendations for ZFS cache/log Message-ID: <50A31D48.3000700@shatow.net> In-Reply-To: <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net> References: <CAFHbX1K-NPuAy5tW0N8=sJD=CU0Q1Pm3ZDkVkE%2BdjpCsD1U8_Q@mail.gmail.com> <57ac1f$gf3rkl@ipmail05.adl6.internode.on.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A31D48.3000700>