Date: Mon, 4 Jan 2016 15:10:22 -0600 (CST) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: freebsd-fs@freebsd.org Subject: Re: NFS reads vs. writes Message-ID: <alpine.GSO.2.01.1601041459340.23704@freddy.simplesystems.org> In-Reply-To: <568A047B.1010000@aldan.algebra.com> References: <8291bb85-bd01-4c8c-80f7-2adcf9947366@email.android.com> <5688D3C1.90301@aldan.algebra.com> <495055121.147587416.1451871433217.JavaMail.zimbra@uoguelph.ca> <568A047B.1010000@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Jan 2016, Mikhail T. wrote: > Yes, indeed. Disabling sync got the writing throughput all the way up to > about 86Mb/s... I still don't fully understand, why local writes are > able to achieve this speed without async and without being considered > dangerous. Local writes are buffered to RAM and the current set of changes (many writes may have been obviated by overwrites) are written at all once as part of the next ZFS transaction group, which can take up to 5 seconds to occur. Each transaction group completes after all disks have positively acknowledged a cache flush. Using this approach, the on-disk data is coherent but it is possible to lose up to 5 seconds of data (back to the previous commited transaction group). The zfs intent log (slog) remembers the pending synchronous writes (which are still written into RAM!) and marks them as committed when the transaction group completes. If the server loses power or spontaneously reboots, the pending writes from the intent log are written to pool disks when the server comes up. 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.1601041459340.23704>