Date: Mon, 7 Jun 1999 16:15:44 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: Nate Williams <nate@mt.sri.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/nfs nfs_socket.c Message-ID: <199906072315.QAA30425@apollo.backplane.com> References: <199906070342.UAA04118@peterw.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Thanks for back-porting these changes!
:
:What's really bugging me right now is the good old block-of-nulls in
:vnode_if.c etc, and that's on an old 2.2.7-S client of a fairly recent
:3.1-S server. The server copy is correct, and the client has the corrupted
:copy. It's even wierder that this client is the one that wrote the file in
:the first place, just moments before it tried to compile it and failed.
:
:I'm pretty sure I recall this particular problem getting fixed, but I don't
:remember if it was one of John Dyson's commits a while ago, one of Doug's,
:or one of Matt's in 4.0... I wish I had been paying more attention :-).
:
:The block of null chars goes from 0x3000 to 0x38bd.. Kinda wierd ending
Blocks of null characters occur when you mmap() a NFS file in combination
with doing other I/O on the file ( it does not have to be simultanious or
in any particular order ). What happens is that the VM system
fully-validates the VM page underlying the buffer due to a page fault.
Even if it doesn't take a fault, the underlying page can only be
validated in DEV_BSIZE'd chunks and you wind up with the same problem.
NFS buffers are not always fully instantiated in 3.x or earlier, which
means that the struct buf's valid range may not cover a full page.
This creates a dysfunction between the VM backing store and the buffer
cache. If the (clean) buffer in the buffer cache is thrown away and later
reconstituted, the buffer cache recalculates the valid range based on
the valid bits in the backing VM page... which are incorrect at this
point.
Thus zero's get incorporated into the buffer. ( actually, garbage gets
incorporated, but the autozeroing code in the system tends to give us
zero'd pages even when we do not ask for them so we usually see zeros
rather then garbage ).
Under -current, we fixed this by forcing read-before-writes on buffers
in order to ensure that they are fully valid, and by changing from
DEV_BSIZE'D alignment to byte-alignment when sizing a buffer. The
underlying VM pages are still DEV_BSIZE granular -- there is nothing we
can do about that, but since the buffers are fully instantiated it does
not pose a problem. The only exception to the rule is at the end of the
file, where a buffer may be chopped off by the end of the file. Since
this value is recorded in the NFS node & vnode, it poses no problem to
buffers being reconstituted. ( though there might be races involved if
the NFS file is resized out from under the client that I haven't found
yet ).
-Matt
Matthew Dillon
<dillon@backplane.com>
:offset - nowhere near a block boundary - but it reminds me of the changes
:Matt made in his recent jumbo nfs patch to rework the piecemeal writes for
:the valid and/or dirty offset/end pointers. However, the end of the nulls
:is right in the middle of "&vop_mkdir_desc,\n", specifically everything
:except the "sc,\n" was clobbered. It doesn't even look like it would match
:a partial write boundary.
:
:> Nate
:
:Cheers,
:-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906072315.QAA30425>