Dependency MKFILE failure in pynfs CID1
Fredric Isaman
iisaman at citi.umich.edu
Fri Jan 26 09:42:45 EST 2007
Note that the OMITs are caused by MKFILE failing, so the relevant part of
the log is:
MKFILE st_open.testOpen : FAILURE
operation OP_SETCLIENTID_CONFIRM should return
NFS4_OK, instead got NFS4ERR_CLID_INUSE
In this case, the test has only sent a (successful) SETCLIENTID, then a
SETCLIENTID_CONFIRM, which fails with NFS4ERR_CLID_INUSE.
Fred
On Thu, 25 Jan 2007, Bryce Harrington wrote:
> Bruce,
>
> In reviewing the test runs for the past couple months, I've seen this
> old MKFILE bug has started cropping up again. It had virtually gone
> away at one point last fall, but in the past 100 runs it's shown up 9
> times. I've entered it in bugzilla as bug 139.
>
> I'd like to understand this bug better and see if it can be eliminated
> entirely, as it's what's been causing most of the red in the crucible
> results.
>
> The output from the test is:
>
> CID1 st_setclientid.testClientReboot : OMIT
> Dependency MKFILE st_open.testOpen had status FAILURE.
> CID1b st_setclientid.testClientUpdateCallback : OMIT
> Dependency MKFILE st_open.testOpen had status FAILURE.
> CID2 st_setclientid.testInUse : PASS
> CID3 st_setclientid.testLoseAnswer : FAILURE
> SETCLIENTID case not covered in RFC should return
> NFS4_OK, instead got NFS4ERR_INVAL
>
> Full log is here:
>
> http://crucible.osdl.org/runs/3733/test_output/newpynfs.sys.log
>
> Thanks,
> Bryce
More information about the NFSv4
mailing list