Date: Thu, 28 Nov 2013 09:18:21 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Kirk McKusick <mckusick@mckusick.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: RFC: NFS client patch to reduce sychronous writes Message-ID: <20131128071821.GH59496@kib.kiev.ua> In-Reply-To: <201311272320.rARNKEKQ045789@chez.mckusick.com> References: <661293549.22251424.1385592648623.JavaMail.root@uoguelph.ca> <201311272320.rARNKEKQ045789@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--GI+6NRUBHXI5NCMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Nov 27, 2013 at 03:20:14PM -0800, Kirk McKusick wrote: > The ``fix'' of bzero'ing every buffer cache page was made to UFS/FFS > for this problem and it killed write performance of the filesystem > by nearly half. We corrected this by only doing the bzero when the > file is mmap'ed which helped things considerably (since most files > being written are not also bmap'ed). I am not sure that I follow. For UFS, leaving any part of the buffer with undefined garbage would cause the garbage to appear on the next mmap(2), since page in is implemented as translation of the file offsets into disk offsets and than reading disk blocks. The read always fetch full page. UFS cannot know if the file would be mapped sometime in future, or after the reboot. In fact, UFS is quite plentiful WRT zeroing buffers on write. It is easy to see almost all places where it is done, by searching for BA_CLRBUF flag for UFS_BALLOC(). UFS does perform the optimization of _trying_ to not clear newly allocated buffer on write if uio covers the whole buffer range. Still, on error it falls back to clearing, which is performed by vfs_bio_clrbuf() call in ffs_write(). --GI+6NRUBHXI5NCMC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSlu48AAoJEJDCuSvBvK1BGvAP+wdCrnmlXGV5S8Rc6S8aYqP3 +gLf+MmOOkEkbUttXgt6UU56pDZ0gm9NPGwTwdIT5YkjJ6gAvnA3jwFJ1Sqf8NC7 x1cKrXsy5/GIpKfa/mtFrLjVQk+dqYCNWA3tvqPHIQlhEu9sV2G8SpFqu1OcTUpu 3Kzi8/nC75Il2WsjaU3zk7NTiFdyg0iaCg5vm0IlA/P9GF721jEMpue+ccyvgpXQ FZr9OO2Wq8rKNuGE/dzV33Tj67/yRgkLxqBjZz84g7BXslS3dhVazfrA/UnNJRJr J7oZV7L9ot2t5RgAdxWLbDYsLc4OpjtzFQ6WjxyRNVZgrOGfSwIJbIqSDflRlVsm NbJLoaBoDvVUj4Okv/PhMTxcicFFfwDqO8IhLa6ETvMEt+9pqjJDgx9WmBBfTkLX xAfm91wes3J+fOaRozLSh8Gwg2S7s/VOFDibp2f7Zh97AMGAzpB5vXecEAd6S4fu 7Xk3TCVrWrYCGMFhH7ftFUFKY1rEteN584xcNWEjeFoILt+K+DctuVBx6MkQQ7ud zAUcVAWypvzhdM86N7l+Fl+9RsGuxheVdFvbRnhcefXD3hzqojcPWY/0MLKw4h5e NGR7bea73Xr5R5wt2ldTCFZcTpSBMHGj4/n0Qk7ILCd6yi79fJSIakFalgPWWkhY YjilSDQU+SiHxg/6kb/z =D01p -----END PGP SIGNATURE----- --GI+6NRUBHXI5NCMC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131128071821.GH59496>