| |||||||||||||
Throwing one awayThrowing one awayPosted Sep 20, 2012 20:38 UTC (Thu) by bfields (subscriber, #19510)In reply to: Throwing one away by khim Parent article: Throwing one away
NFS is completely stateless protocol. NFSv4 isn't stateless, and in practice though NFSv3 itself may have been stateful, it was usually run alongside NLM. And I don't see why you couldn't in theory add a little more state to the protocol and make seekdir/telldir. Whether that would actually be a practical solution to anyone's problem, I don't know....
(Log in to post comments)
Throwing one away Posted Sep 20, 2012 21:43 UTC (Thu) by neilbrown (subscriber, #359) [Link]
I was always amused by the term "stateless" as applied to NFS, because I always thought the content of files was "state"...
Obviously "state" and "stateless" are relative terms which we need to be careful with.
NFSv4 certainly has a lot of state, but for much of this state (not including the files!) the server it allowed to drop the state - on a reboot. NFSv4 has a whole sub-protocol for recovering that state which essentially involves the server saying "If forgot everything, tell me what you know" and the clients saying "I had this file locked and this one open etc etc". I.e. the clients also store the state and feed it back to the server (Bruce of course knows all of this).
Were "current directory pointer" to be part of the "state" of an open file (when that file was a directory) ... how would the client reinstate that state when the server lost it? It would need a stable cookie!
I think the NFSv4 protocol does mention the possibility of the server saving some of its state to "stable storage" - there are times (particularly relating to extended partial network partitions) where that is needed and so the cost would be justified. (a bit like /var/lib/nfs/sm).
Throwing one away Posted Sep 21, 2012 15:17 UTC (Fri) by bfields (subscriber, #19510) [Link]
Yeah, so I had only the two obvious ideas:
1. Directory-modifying operations could be blocked during the grace period, during which clients could reclaim their previous cursors. (Is that enough to help?)
2. The existence of a directory-open might make it practical to keep readdir cursors in stable storage (since now you have to remember a limited amount of state for open directories, as opposed to remembering every cookie you've ever handed out.)
I dunno.
Throwing one away Posted Sep 21, 2012 22:57 UTC (Fri) by nix (subscriber, #2304) [Link]
Your first option brings back horrible memories of servers locking solid blocking on downed NFS servers. Anything that blocks fs operations is dancing with the deadlock fairy. (I'd say that if someone modifies a directory on which a cookie is held, that cookie is invalidated. It's not like there are meaningful guarantees for readdir() on directories under modification even in the local case.)
I don't see why the client doesn't just remember 'the last filename we readdir()ed' and hand that back, probably in addition with a crude, random, non-stable cookie generated by the server in *its* last response in the same opendir() loop. I suppose it would make the readdir request a bit bigger... but in the common case of readdir()s following each other in quick succession it need be no slower: the server could keep a bit of extremely temporary local-only state (basically a readdir() handle and the random cookie we sent back with the last response) for recently received readdir() requests, compare the incoming request with the random cookie and filename, and now we know the next name to use, expiring the pair when we hit the end of the directory. If we expire the cookie/filename pair (which should be rare enough), we just need to opendir() the directory and readdir() through it until we find the filename again.
What am I missing? (Other than the fact that we can't change NFS because it's already there and doesn't work this way.)
Throwing one away Posted Sep 21, 2012 22:40 UTC (Fri) by nix (subscriber, #2304) [Link]
I was thinking mostly of 'core' NFSv3. NLM/lockd was always a bolt-on: suggesting that a stateful subsystem be used for something like readdir would never have flown. (A bit silly, really, because readdir(), locally, is about as stateful as anything can get.)
|
|||||||||||||