On 05/20/11 10:26, Dr. J. Bruce Fields wrote:
On Fri, May 20, 2011 at 09:20:47AM -0700, Harry Edmon wrote:
On 05/16/11 13:53, Dr. J. Bruce Fields wrote:
Hm, so the renews all have clid 465ccc4d09000000, and the reads all have
a stateid (0, 465ccc4dc24c0a0000000000).
So the first 4 bytes matching just tells me both were handed out by the
same server instance (so there was no server reboot in between); there's
no way for me to tell whether they really belong to the same client.
The server does assume that any stateid from the current server instance
that no longer exists in its table is expired. I believe that's
correct, given a correctly functioning client, but perhaps I'm missing a
case.
--b.
I am very appreciative of the quick initial comments I receive from
all of you on my NFS problem. I notice that there has been silence
on the problem since the 16th, so I assume that either this is a
hard bug to track down or you have been busy with higher priority
tasks. Is there anything I can do to help develop a solution to
this problem?
Well, the only candidate explanation for the problem is that my
assumption--that any time the server gets a stateid from the current
boot instance that it doesn't recognize as an active stateid, it is safe
for the server to return EXPIRED--is wrong.
I don't immediately see why it's wrong, and based on the silence nobody
else does either, but I'm not 100% convinced I'm right either.
So one approach might be to add server code that makes a better effort
to return EXPIRED only when we're sure it's a stateid from an expired
client, and see if that solves your problem.
Remind me, did you have an easy way to reproduce your problem?
--b.
It is somewhat random. Sometimes it gets better after a client
reboot. The current case I have given you does not get better with a
client reboot.
--
Dr. Harry Edmon E-MAIL: harry@xxxxxx
206-543-0547 FAX: 206-543-0308 harry@xxxxxxxxxxxxxxxxxxxx
Director of IT, College of the Environment and
Director of Computing, Dept of Atmospheric Sciences
University of Washington, Box 351640, Seattle, WA 98195-1640
--
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
