From owner-freebsd-current Sat Jul 13 21:15:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA05874 for current-outgoing; Sat, 13 Jul 1996 21:15:49 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA05869 for ; Sat, 13 Jul 1996 21:15:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id VAA06027; Sat, 13 Jul 1996 21:09:55 -0700 From: Terry Lambert Message-Id: <199607140409.VAA06027@phaeton.artisoft.com> Subject: Re: NFSv3 fixes for review To: dfr@nlsys.demon.co.uk (Doug Rabson) Date: Sat, 13 Jul 1996 21:09:55 -0700 (MST) Cc: current@FreeBSD.ORG, dfr@render.com In-Reply-To: <31E77EA6.41C67EA6@nlsys.demon.co.uk> from "Doug Rabson" at Jul 13, 96 11:47:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have just integrated some fixes to the NFSv3 code from Frank van der > Linden (frank@fwi.uva.nl). The first bug is the same one as the > 'corrupt output from makesyscalls.sh on an nfsv3 mount' bug. I have > verified this one by testing on a loopback mount (which is all I can > do from my home machine). I have not tried to reproduce the second > two problems but the fixes seem safe. > > While I was here, I also fixed the truncated 32bit minor numbers on > nfsv3 mount bug. I believe that Bruce originally suggested the fix > for this? > > Could someone please review these changes (diffs included) so that I > can commit them. This fix seems to work right for me. I'm nervous about the use of the timeval, mostly because I'm not sure that it is monotonically increasing in the ntpd time synchronization case (and haven't looked deep enough to verify that the reported time from the microtime is not affected by adjustments. Is there a seperate monotonically increasing clock, which is not modified by time adjust? I guess this would be a factor only on a system with a relatively high drift rate (such that a reboot could occur such that the delay did not exceed the drift, causing the XID to go backward). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.