From owner-freebsd-current Mon Jul 15 03:13:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25671 for current-outgoing; Mon, 15 Jul 1996 03:13:43 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA25666 for ; Mon, 15 Jul 1996 03:13:39 -0700 (PDT) Received: (from dfr@localhost) by minnow.render.com (8.6.12/8.6.9) id KAA07653; Mon, 15 Jul 1996 10:17:51 +0100 Date: Mon, 15 Jul 1996 10:17:51 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: current@FreeBSD.ORG Subject: Re: NFSv3 fixes for review In-Reply-To: <199607140409.VAA06027@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 13 Jul 1996, Terry Lambert wrote: > > 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). I think that the time is only used to specify the first xid used. Subsequent ids just increment the first one. The fix was needed because some servers noticed xids for a client going back to zero when the client rebooted and complained. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939