Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Nov 2012 01:25:22 -0500
From:      Charles Sprickman <spork@bway.net>
To:        Stephen McKay <smckay@internode.on.net>
Cc:        Tom Evans <tevans.uk@googlemail.com>, FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   Re: SSD recommendations for ZFS cache/log
Message-ID:  <D7876686-8992-4C5F-94A5-BCDEB5E07237@bway.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 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"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7876686-8992-4C5F-94A5-BCDEB5E07237>