RFC: NFS client patch to reduce sychronous writes

[Rick Macklem]

Kostik wrote:
> 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 ?
> 
Yes, at this point np->n_size is the old size and this calculates the
offset within the file's last block of the old EOF and puts it in
obcount. bcount is the offset of the new EOF that will result
after the write.

> > 
> > 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.
> 
> 
Yes, I'll need to look at this. If it is a problem, all I can think of
is bzeroing all new pages when they're allocated to the buffer cache.

Thanks for looking at it, rick
ps: Btw, jhb@'s patch didn't have the bzeroing in it.