From owner-freebsd-current Wed Dec 15 23:43:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D40C514FF5 for ; Wed, 15 Dec 1999 23:43:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA49890; Wed, 15 Dec 1999 23:43:06 -0800 (PST) (envelope-from dillon) Date: Wed, 15 Dec 1999 23:43:06 -0800 (PST) From: Matthew Dillon Message-Id: <199912160743.XAA49890@apollo.backplane.com> To: Poul-Henning Kamp Cc: Andrew Gallatin , freebsd-current@FreeBSD.ORG Subject: Re: Serious server-side NFS problem References: <14376.945329041@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> NFS uses the kernel 'boottime' structure to generate its version id. :> Now normally you might believe that this structure, once set, will :> never change. The authors of NFS certainly make that assumption! : :Is this another case of "lets assume the time of day is a random number" or :is there any underlying assumption about time in this ? : :-- :Poul-Henning Kamp FreeBSD coreteam member :phk@FreeBSD.ORG "Real hackers run -current on their laptop." It basically needs to be a unique for each server reboot in order to allow clients to resynchronize. The time has historically been used for this purpose since NFS networks tend to require ntp synchronization anyway. The time was used even before systems had realtime clocks -- the kernel would load it's initial time from the last access time stamp in the root filesystem (or superblock, I forget which it was). Under NFSv2 it wasn't as critical. Under NFSv3 the protocol will break badly if the number stays the same across a reboot - there would be a massive loss of data. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message