Re: HEADS-UP: nearing nfs-utils 1.1.0 and statd changes.

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Mar 20, 2007 at 10:49:15AM -0400, Talpey, Thomas wrote:
> At 10:26 AM 3/20/2007, J. Bruce Fields wrote:
> >On Tue, Mar 20, 2007 at 07:24:00AM -0400, William A. (Andy) Adamson wrote:
> >> No. The stale stateid check is before the bad stateid check
> >> (fs/nfsd/nfs4state.c:nfs4_preprocess_stateid_op) - stale stateid is
> >> returned, which is the correct behavior past reclaim processing.
> >
> >Yeah, note that the necessary information is in the stateid itself--we
> >embed the current boot time in every stateid we hand out--so we don't
> >need to keep around any memory of the client in order to hand out the
> >correct error.
> 
> Yeah, after Andy's pointer I did notice that all non-0, non-1,
> non-current-server-boot-time stateids from the client will result in
> a "stale" return from STALE_STATEID(). ;-)
> 
> I might argue on that "correct" adjective, but yes, it does encourage
> reclaim/recovery.

Is there a particular case you're worried about?

> If the client is truly full of garbage, then the clientid
> will probably fail too anyway.

Yeah, I don't see any reason to care about a client that hands us random
stateid's that weren't given out by us. 

--b.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs