Date: Thu, 12 May 2011 09:42:45 +0100 From: krad <kraduk@gmail.com> To: Jason Hellenthal <jhell@dataix.net> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: How to enable cache and logs. Message-ID: <BANLkTi=vOD5EJSo14otdD%2BCxThJ7kE5txA@mail.gmail.com> In-Reply-To: <20110511223849.GA65193@DataIX.net> References: <4DCA5620.1030203@dannysplace.net> <20110511100655.GA35129@icarus.home.lan> <4DCA66CF.7070608@digsys.bg> <20110511105117.GA36571@icarus.home.lan> <4DCA7056.20200@digsys.bg> <20110511120830.GA37515@icarus.home.lan> <20110511223849.GA65193@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 May 2011 23:38, Jason Hellenthal <jhell@dataix.net> wrote: > > Jeremy, > > On Wed, May 11, 2011 at 05:08:30AM -0700, Jeremy Chadwick wrote: > > On Wed, May 11, 2011 at 02:17:42PM +0300, Daniel Kalchev wrote: > > > On 11.05.11 13:51, Jeremy Chadwick wrote: > > > >Furthermore, TRIM support doesn't exist with ZFS on FreeBSD, so folk= s > > > >should also keep that in mind when putting an SSD into use in this > > > >fashion. > > > > > > By the way, what would be the use of TRIM for SLOG and L2ARC devices? > > > I see absolutely no benefit from TRIM for the L2ARC, because it is > > > written slowly (on purpose). Any current, or 1-2 generations back SS= D > > > would handle that write load without TRIM and without any performance > > > degradation. > > > > > > Perhaps TRIM helps with the SLOG. But then, it is wise to use SLC > > > SSD for the SLOG, for many reasons. The write regions on the SLC > > > NAND should be smaller (my wild guess, current practice may differ) > > > and the need for rewriting will be small. If you don't need to > > > rewrite already written data, TRIM does not help. Also, as far as I > > > understand, most "serious" SSDs (typical for SLC I guess) would have > > > twice or more the advertised size and always write to fresh cells, > > > scheduling an background erase of the 'overwritten' cell. > > > > AFAIK, drive manufacturers do not disclose just how much reallocation > > space they keep available on an SSD. I'd rather not speculate as to ho= w > > much, as I'm certain it varies per vendor. > > > > Lets not forget here: The size of the separate log device may be quite > small. A rule of thumb is that you should size the separate log to be abl= e > to handle 10 seconds of your expected synchronous write workload. It woul= d > be rare to need more than 100 MB in a separate log device, but the > separate log must be at least 64 MB. > > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide > > > So in other words how much is TRIM really even effective give the above ? > > Even with a high database write load on the disks at full compacity of th= e > incoming link I would find it hard to believe that anyone could get the > ZIL to even come close to 512MB. > > > Given most SSD's come at a size greater than 32GB I hope this comes as a > early reminder that the ZIL you are buying that disk for is only going to > be using a small percent of that disk and I hope you justify cost over it= s > actual use. If you do happen to justify creating a ZIL for your pool then > I hope that you partition it wisely to make use of the rest of the space > that is untouched. > > For all other cases I would reccomend if you still want to have a ZIL tha= t > you take some sort of PCI->SD CARD or USB stick into account with > mirroring. > > -- > > Regards, (jhell) > Jason Hellenthal > > > You have just spotted a gap in the market I suspect. Maybe SSD manufacturers need to produce a sata based ssd of 1 or 2 gb of the fastest write speed available flash on the market. Produce it for < =A350 and you should have a big market
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=vOD5EJSo14otdD%2BCxThJ7kE5txA>