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