From owner-cvs-all Mon Jun 7 16:16: 3 1999 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1EECC14DB5; Mon, 7 Jun 1999 16:15:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA30425; Mon, 7 Jun 1999 16:15:44 -0700 (PDT) (envelope-from dillon) Date: Mon, 7 Jun 1999 16:15:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199906072315.QAA30425@apollo.backplane.com> To: Peter Wemm Cc: Nate Williams , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/nfs nfs_socket.c References: <199906070342.UAA04118@peterw.yahoo.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :> 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 :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