From owner-freebsd-current Sun Jan 17 21:52:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA21872 for freebsd-current-outgoing; Sun, 17 Jan 1999 21:52:05 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA21859; Sun, 17 Jan 1999 21:52:02 -0800 (PST) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.9.1/8.9.1) with SMTP id VAA11700; Sun, 17 Jan 1999 21:51:58 -0800 (PST) Date: Sun, 17 Jan 1999 21:51:58 -0800 (PST) From: Chris Timmons To: freebsd-current@FreeBSD.ORG cc: John Polstra , luoqi@FreeBSD.ORG Subject: NFS: likely problem is vfs_bio.c rev 1.188 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra did some leg work and found a few candidate commits which he suggested backing out one by one to see if they affected the current situation with NFS. On the server I downgraded vfs_bio.c to rev 1.187 & rebooted; no luck. I then installed the same kernel (with the downgraded vfs_bio.c) to the client. Bingo. With both NFS client & server machine running rev 1.187, the problem so far as building XFree86-contrib from an NFS mounted /usr/ports disappears. As Chuck Robey noted, it seems like the client's writes are not completely being committed to the server, which results in partially baked files which are truncated. Unfortunately -r1.188 -r1.187 doesn't apply cleanly, so there's some work to be done by Eivind to adapt his subsequent commits if we were to say, back out 1.188 prior to the branch. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message