|
On Fri, Sep 28, 2001 at 02:11:09PM -0700, Steven Lang wrote:
> On Thursday 27 September 2001 03:52 pm, Horms wrote:
> > As far as I can work out you'll need the persistance to be much longer than
> > 5s. NFS is stateless, but regardless, when a client connects to a server a
> > small ammount of state is established on both sides. The stateless aspect
> > comes into play in that if either side times out, or a reboot is detected
> > then the client will attempt to reconnect to the server. If the client
> > doesn't reconnect, but rather its packets end up on a different server
> > because of load balancing the server won't know anything about the client
> > and nothing good will come of the sitiation. The solution to this is to
> > ensure a client consistently talks to the same server, by setting a really
> > long persistancy.
>
> I actually specifically tested for this. Now it may just be a linux thing,
> not common to all NFS platforms, but in my tests, when packets were sent to
> the server other than the one mounted, it happily serves up the requested
> data without even blinking. So whatever state is being saved (And I do know
> there is some minimal state) seems unimportant. It actually surprised me how
> seamlessly it all worked, as I was expecting the non-mounted server to reject
> the requests or something similar.
That is quite suprising as the server should maintain state as to
what clients have what mounted.
> > There is also the small issue of locks. lockd should be running on the
> > server and keeping track of all the locks the client has. If the client
> > has to reconnect, then it assumes all its locks are lost, but in the mean
> > time it assumes everything is consistent. If it isn't accessing the same
> > server (which wouldn't work for the reason given above) then the server
> > won't know about any locks it things it has.
>
> This could indeed be an issue. Perhaps setting up persistence for locks.
> But I don't think it is all bad. Of course, I am basing this off several
> assumptions that I have not verified at the moment. I am assuming that NFS
> and GFS will Do The Right Thing. I am assuming the NFS lock daemon will
> coordinate locks with the underlying OS. I am also assuming that GFS will
> then coordinate the locking with the rest of the servers in the cluster. Now
> as I understand locking on UNIX, it is only advisory and not enforced by the
> kernel, the programs are supposed to police themselves. So in that case, as
> long as it talks to a lock daemon, and keeps talking to the same lock daemon,
> it should be okay, even if the lock daemon is not on the server it is talking
> to, right?
That should be correct, the locks are advisor. As long as
the lock daemons are talking to the underlying file system (GFS) then
the behaviour should be correct, regarldess of which lock daemon
a client talks to, as long as the client consistently talks to
the same lock daemon for a given lock.
> Of course, in the case of a failure, I don't know what will happen. I will
> definately have to look at the whole locking thing in more detail to know if
> things work right or not, and maybe get the lock daemons to coordinate
> locking.
Given that lockd currently lives entirely in the kernel
that is easier said than done.
--
Horms
|
