On Tue, Nov 22, 2011 at 03:14:03PM -0500, Chuck Lever wrote: > > On Nov 22, 2011, at 2:36 PM, J. Bruce Fields wrote: > > > On Tue, Nov 22, 2011 at 12:52:53PM -0500, Chuck Lever wrote: > >> Servers have a finite amount of memory to store NFSv4 open and lock > >> owners. Moreover, servers may have a difficult time determining when > >> they can reap their state owner table, thanks to gray areas in the > >> NFSv4 protocol specification. > > > > What's the gray area? > > > > Reminding myself: OK, I guess it's the NFSv4.0 close-replay problem. > > You have to keep around enough information about a closed stateid to > > handle a replay. If a client reuses the stateowner than you can purge > > that as soon as you bump the sequence number, otherwise you have to keep > > it around a while (how long is unclear). > > ^^^^^^^^^^^^^^^^^^^^ > That's the problem. > > When the server can't store any more state owners, it has to use heuristics to reap unused state owners, or it can have the client perform state recovery to determine which state owners the client wants to keep around. Or, it can return NFS4ERR_RESOURCE and hope for the best. Yeah. All the Linux server currently does is keep them around for a lease period, then purge them. That strikes me as too short a time to catch a lot of replays, but possibly too long in the face of a client creating a lot of new openowners. Anyway, making the client less agressive seems like the most important thing, thanks. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
