Date: Mon, 2 Mar 1998 11:52:57 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Jamie Bowden <jamie@itribe.net> Cc: Terry Lambert <tlambert@primenet.com>, hackers@FreeBSD.ORG Subject: Re: help - make world fails Message-ID: <Pine.BSF.3.96.980302114439.1426A-100000@trojanhorse.pr.watson.org> In-Reply-To: <199803021430.JAA15071@gatekeeper.itribe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Mar 1998, Jamie Bowden wrote: > > o NFS client locks need to be remembered locally so that > > they can be reasserted in case of a server crash. This > > is my way of saving the state. > > Isn't NFS stateless. Sonetimes I wonder what Sun was thinking trying > implement a stateless design over a network. Sandberg, et. al, "Design and Implementation of the Sun Network Filesystem", ~1985? "The NFS uses a stateless protocol. The parameters to each procedure call contain all of the information necessary to complete the call, and the server does not keep track of any past requests. This makes crash recovery very easy; when a server crashes, the client resends NFS requests until a response is received, and the server does no crash recovery at all..." "...Using a stateless protocol allows us to avoid complex crash recovery and simplifies the protocol... In fact the client can not tell the difference between a server that has crashed and recovered, and a server that is slow." This said, of course, my clients still crash when the server goes down and something happens on the client (i.e., a call to mount, df, quota, or something :). The problem with stateless is, of course, that not all concepts associated with file system access are representable in a stateless way -- such as locking. Coda, for example, retains a lot of state with regards to cache information on both client and server side. The client retains the file (:)), and the server forms a callback so that it can notify the client on a change. Coda does not have a concept of locking, though, as it was determined (:O) that most of the file activity of interest involved sequential one-time read followed by sequential one-time write, no shared access, etc. This is true in the general case, but resoundingly not true for the specific cases where people try to use locking :). I'd love to see someone write a simple lock manager for Coda to allow exclusive advisory locking support (posix-style) based on some kind of distributed quorum database or something. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980302114439.1426A-100000>