Date: Thu, 12 May 2011 08:57:17 -0500 (CDT) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: How to enable cache and logs. Message-ID: <alpine.GSO.2.01.1105120842580.20825@freddy.simplesystems.org> 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 Wed, 11 May 2011, Jeremy Chadwick wrote: > > 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. > Consumer-level SSDs do not have extremely high write performance (and it > gets worse without TRIM; again a 70% decrease in write speed in some > cases). It is certainly a factor. However, large block writes (something like 128K, I don't remember exactly) bypass the dedicated log device and instead are written to the main store (with only a reference being added to the dedicated device). The reason this is done is for the exact reason you point out. The SSD has a very fast seek and zero rotational latency but being a singular resource it suffers from bandwidth limitations. The main store usually suffers from multi-millisecond seeks and rotational latency but offers linearly scalable and substantial write performance for larger writes. Matt Ahrens has described this a few times on the zfs-discuss list and there is mention of it on slide 15 of the presentation found at "http://www.slideshare.net/edigit/zfs-presentation". The large write feature of the ZIL is a reason why we should appreciate modern NFS's large-write capability and avoid anchient NFS. It is worth mentioning that the ZIL is a write-only device which is only read when the system boots or a pool is imported. The writes are usually "write and forget" since zfs uses them to improve its ability to cache larger transaction groups. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.2.01.1105120842580.20825>