From: Mike Eisler (mike@eisler.com)
Date: 09/22/00-02:29:07 PM Z
Message-Id: <200009221931.MAA20493@eagle.webpros.com> Date: Fri, 22 Sep 2000 12:29:07 -0700 (PDT) From: Mike Eisler <mike@eisler.com> Subject: Re: lock stateid, sequence number and lease interaction >From: "William A.(Andy) Adamson" <andros@umich.edu> > >>> The stateid has to be checked first - it is the only way >>> to find the lockowner. If the stateid is bad, the sequence >>> number cannot be bumped because the lockowner can't be >>> identified. So, the client when getting a NFS4ERR_XXX_STATEID >>> error needs to decrement the lockowners sequence number otherwise >>> it will be inconsistant for other lockowner operations. >> >>If the client gets a bad stateid status from the server, then playing >>with the sequence number isn't going let the client recover, because >>the next operation requiring a stateid is going to fail. > >here's where i struggle with the assumptions behind the concept of lockowner >on the client. > >first, to set the stage: > >the stateid -> lockowner,lock,file association. >there are many stateid's associated with a lockowner, one per open file. >there is one seq num counter associated with a lockowner that services all >stateid's. > >lets futher say that a lockowner is defined as the clientid and the pid, or >from the clients perspective, a lockowner = pid. > >is there an assumption that all file access's are serialized per lockowner? or >does the protocol allow for per lock owner async file access? The client must serialize on a per nfs_lockowner basis all accesses that involve a sequence number. So if the client sends what it thinks is a valid stateid and sequence number pair, and the server say, no, something very bad has occurred on the client or server or both, e.g. a bug or a skilled attacker. I believe every operation that takes a seqid and stateid as an argument returns a new stateid (though I haven't made an exhaustive check ... if there is an exception, then this might be a protocol bug). It should also be the case that every opersation that takes a stateid but not a seqid, does not return a new stateid. So in fact there are not many stateids associated with a nfs_lockowner, there's only one active at one time, plus the stateid argument of the request in the lock manager replay cache. >for example, a userlevel pthread application running in the process could have >serveral files opened, and could spawn 2 threads that each try to lock a byte >range of two different files. in this case, one thread could get a bad stateid >status, andit would not be true that the next operation requiring a stateid > would fail if it came from the other thread. The client code has to synchronize the accesses. For the conventional in-kernel NFS file system model, this is straightforward. For use-levle models, it is probably best that each thread be assigned a unique nfs_lockowner. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:17 AM Z CST