Date: Wed, 27 Nov 2013 20:31:06 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: RFC: NFS client patch to reduce sychronous writes Message-ID: <20131127183106.GB59496@kib.kiev.ua> In-Reply-To: <1694315515.21775878.1385562535320.JavaMail.root@uoguelph.ca> References: <20131127085245.GW59496@kib.kiev.ua> <1694315515.21775878.1385562535320.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--sB9dJ6svPyodOVES Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 09:28:55AM -0500, Rick Macklem wrote: > Kostik wrote: > > On Tue, Nov 26, 2013 at 06:41:13PM -0500, Rick Macklem wrote: > Well, if an app. writes a file with holes in it, without the bzeroing > the hole can end up with garbage in it instead of 0s. See the attached > trivial test program I used. Ok. >=20 > > More, the zeroing seems to overwrite part of the previously valid > > content of the buffer, unless I mis-read the patch. This breaks > > the mmap/file consistency, since buffer pages may be mapped by > > usermode > > process, and it could observe the 'out of thin air' zeroes before the > > writing thread progressed to fill the zeroed part with new content. > >=20 > Well obcount is set to the offset in the block of the current EOF > (np->n_size - lbn * biosize) and the zeroing is from there to the new > size of the buffer. My intent was to only zero out the chunk that is > being "grown" by this write. If that part of the file is already mmap()'d > and could have been written by an app. already, I can see a problem, > but I don't know how it would be fixed? But, if the old size of the file is not biosize-aligned, than lbn*biosize is less than the old EOF ? >=20 > I'll try and come up with a test case for this. I'll admit I don't > know when the file's size (n_size) gets updated when mmap()'d. Sorry, I do not understand the question. mmap(2) itself does not change file size. But if mmaped area includes the last page, I still think that the situation I described before is possible. --sB9dJ6svPyodOVES Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSljppAAoJEJDCuSvBvK1BtKYP/3Cl/ogeCvuuCoQJl3/Hqott MgxvK+efYn/BjqVNdnZg/QPES6DV/B9GdE4pwwKmU6dU2NErwVqN2CArdFJ1INjB Q3ygLtk+dq+FYwAqC2yKoX0vkqlAGM8bxjPVZWdXYv2MBA1Tm4FXlBs9Mc7yy5lI 738eCjimLwRbgBMuRmmfUcVB60vMTRJuGfn67GaKHcY2ayKQ6ly/xrBexn23bG26 p31ZP4jarYbApwtKZgMga+FKz2e+O1gPEazEiMCNs7Hjosgq07kl5djNfwXvNMbv Y/ACYH5gSa+7RCO8OS3Q9PUnJc8b/0HyBtsx58T9Lk2vgjIs8e3+Ne4ki0sF+sMt iO3d7/5ZEKIRJzgzXYlk+Hw5S/+r+POLx3F3SuJzo12fnA9RdnDGjYhZz1qmpL/E wtC90ZMpQuu5Jrqv3UtT5v3QlUc5wH/kIDbCZbmmAwUsQ9qixLvyBlOlCXdGNFmT dapOmVm3QxDmkKW+I2BAwXYB1sz1fxnfcqHHojrxM3SXZEoTlYBPCUSKzcRJ/Oyu I3p1JNHDDD0vxA3dvRpJS6BTphtLxLOwPDu7S+GcDBNBIK+A4n0PgoEPJtSUaK6v GrfiIm8iP+kG8d5Oypu5cB5tlTpoyiX/6Hg52pjwXezh7pbFYOgPKtlvztvhBWM/ N+YJ1bRTCa2kq5ix1eoe =T025 -----END PGP SIGNATURE----- --sB9dJ6svPyodOVES--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131127183106.GB59496>