Date: Thu, 12 May 2011 18:19:50 -0500 (CDT) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS: How to enable cache and logs. Message-ID: <alpine.GSO.2.01.1105121805500.8019@freddy.simplesystems.org> In-Reply-To: <1700693186.266759.1305241371736.JavaMail.root@erie.cs.uoguelph.ca> References: <1700693186.266759.1305241371736.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 May 2011, Rick Macklem wrote: >> The large write feature of the ZIL is a reason why we should >> appreciate modern NFS's large-write capability and avoid anchient NFS. >> > The size of a write for the new FreeBSD NFS server is limited to > MAX_BSIZE. It is currently 64K, but I would like to see it much larger. > I am going to try increasing MAX_BSIZE soon, to see what happens. Zfs would certainly appreciate 128K since that is its default block size. When existing file content is overwritten, writing in properly aligned 128K blocks is much faster due to ZFS's COW algorithm and not needing to read the existing block. With a partial "overwrite", if the existing block is not already cached in the ARC, then it would need to be read from underlying store before the replacement block can be written. This effect becomes readily apparent in benchmarks. In my own benchmarking I have found that 128K is sufficient and using larger multiples of 128K does not obtain much more performance. When creating a file from scratch, zfs performs well for async writes if a process writes data smaller than 128K. That might not be the case for sync writes. 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.1105121805500.8019>