Date: Thu, 12 May 2011 09:33:06 +0300 From: Daniel Kalchev <daniel@digsys.bg> To: freebsd-fs@freebsd.org Subject: Re: ZFS: How to enable cache and logs. Message-ID: <4DCB7F22.4060008@digsys.bg> In-Reply-To: <20110512033626.GA52047@icarus.home.lan> References: <4DCA5620.1030203@dannysplace.net> <4DCB455C.4020805@dannysplace.net> <alpine.GSO.2.01.1105112146500.20825@freddy.simplesystems.org> <20110512033626.GA52047@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12.05.11 06:36, Jeremy Chadwick wrote: > On Wed, May 11, 2011 at 09:51:58PM -0500, Bob Friesenhahn wrote: >> On Thu, 12 May 2011, Danny Carroll wrote: >>> Replying to myself in order to summarise the recommendations (when using >>> v28): >>> - Don't use SSD for the Log device. Write speed tends to be a problem. >> DO use SSD for the log device. The log device is only used for >> synchronous writes. Except for certain usages (E.g. database and >> NFS server) most writes will be asynchronous and never be written to >> the log. Huge synchronous writes will also bypass the SSD log >> device. The log device is for reducing latency on small synchronous >> writes. > Bob, please correct me if I'm wrong, but as I understand it a log device > (ZIL) effectively limits the overall write speed of the pool itself. > Perhaps I misstated it in my first post, but there is nothing wrong with using SSD for the SLOG. You can of course create usage/benchmark scenario, where an (cheap) SSD based SLOG will be worse than an (fast) HDD based SLOG, especially if you are not concerned about latency. The SLOG resolves two issues, it increases the pool throughput (primary storage) by removing small synchronous writes from it, that will unnecessarily introduce head movement and more IOPS and it provided low latency for small synchronous writes. The later is only valid if the SSD is sufficiently write-optimized. Most consumer SSDs end up saturated by writes. Sequential write IOPS is what matters here. About TRIM. As it was already mentioned, you will use only small portion of an (for example) 32GB SSD for the SLOG. If you do not allocate the entire SSD, then wear leveling will be able to play well and it is very likely you will not suffer any performance degradation. By the way, I do not believe Windows benchmark has any significance in our ZFS usage for the SSDs. How is TRIM implemented in Windows? How does it relate to SSD usage as SLOG and L2ARC? How can ever TRIM support influence reading from the drive?! TRIM is an slow operation. How often are these issued? What is the impact of issuing TRIM to an otherwise loaded SSD? Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DCB7F22.4060008>