RFC: NFS client patch to reduce sychronous writes

[Konstantin Belousov]

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.

> 
> > 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.
> > 
> 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 ?

> 
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20131127/93cd0acf/attachment.sig>