On Mon, Jan 25, 2010 at 10:30:49AM -0500, Steve Dickson wrote: > Hey Bruce, > > During our Fedora Testing effort we have identified the following > pynfs failures when testing with a kernel-2.6.33 and a very current > nfs-utils... At one point I thought there was a list of known pynfs > failures. Did you see the mail I sent you last week? Especially: http://linux-nfs.org/pipermail/pnfs/2010-January/010008.html > If so, how does this list match up? any thing new? > Anything jumping out that we really should fix? Personally I've been ignoring the tests that don't pass and just rerunning the rest regularly to spot regressions. I think that's the best use of pynfs for now. Some of the failures are unimportant or questionable, so "this patch fixes pynfs test XXXYYY" is never enough to justify applying anything--we also need to check the spec and/or consider the effect on client-side behavior. Anyway, may still be worth another look at the results, so here goes: > [root@ibm-hs21-01 pynfs]# ./testserver.py localhost:/nfs --maketree all > CID1 st_setclientid.testClientReboot : WARNING > Trying to use old stateid after SETCLIENTID_CONFIRM > purges state should return NFS4ERR_OLD_STATEID, > instead got NFS4ERR_BAD_STATEID > CID6 st_setclientid.testNoConfirm : FAILURE > OPEN using clientid that was never confirmed should > return NFS4ERR_STALE_CLIENTID, instead got > NFS4ERR_EXPIRED > CIDCF2 st_setclientidconfirm.testBadConfirm : FAILURE > SETCLIENTID_CONFIRM with case not covered in RFC, > seems most likely should do nothing and should return > NFS4_OK, instead got NFS4ERR_CLID_INUSE Medium priority to fix. > COMP3 st_compound.testBadTags : FAILURE > Compound with invalid utf8 tag '\xc0\xc1' should > return NFS4ERR_INVAL, instead got NFS4_OK UTF8 failures are by design; ignore. Omitting similar results in the following. > COMP6 st_compound.testLongCompound : FAILURE > COMPOUND with len=150 argarry got RPCError: > MSG_ACCEPTED: GARBAGE_ARGS, expected NFS4ERR_RESOURCE Low priority to fix. > CR13 st_create.testDots : FAILURE > Trying to CREATE a dir named '.' should return NFS4_OK > or NFS4ERR_BADNAME, instead got NFS4ERR_INVAL > CR14 st_create.testSlash : FAILURE > Creation of dir named 'CR14/foo' should return > NFS4ERR_BADNAME or NFS4ERR_BADCHAR, instead got > NFS4ERR_INVAL Medium priority to fix. Omitting similar failures in the following. > LINK4a st_link.testCfhLink : FAILURE > LINK with <cfh> not a directory should return > NFS4ERR_NOTDIR, instead got NFS4ERR_SYMLINK I think current behavior may actually be correct; check the spec and behavior on other filesystems. Low priority. Omitting similar failures in the following. > LOCK8c st_lock.testNonzeroLockSeqid : WARNING > LOCK with newlockowner's lockseqid=1 should return > NFS4ERR_BAD_SEQID, instead got NFS4_OK The spec doesn't require this; we should probably remove this test. > LOCK18 st_lock.testFairness : WARNING > Locking is not fair > LOCK19 st_lock.testBlockPoll : WARNING > Locking is not fair > LOCK21 st_lock.testBlockingQueue : WARNING > Locking is not fair > LOCK22 st_lock.testLongPoll : WARNING > Locking is not fair Medium priority to fix. I have patches that would need updating. > LOOK6 st_lookup.testNonAccessable : FAILURE > LOOKUP object in a dir with mode=000 should return > NFS4ERR_ACCESS, instead got NFS4_OK This happens when tests are run with root and root-squashing is disabled: http://linux-nfs.org/pipermail/nfsv4/2006-January/thread.html#3305 I believe current behavior is correct, but it might be worth another look. Low priority. Omitting similar results in the following. > OPDG9a st_opendowngrade.testLink : WARNING > OPENDOWNGRADE with nonfile object should return > NFS4ERR_INVAL, instead got NFS4ERR_BAD_STATEID > OPDG9b st_opendowngrade.testBlock : WARNING > OPENDOWNGRADE with nonfile object should return > NFS4ERR_INVAL, instead got NFS4ERR_BAD_STATEID > OPDG9c st_opendowngrade.testChar : WARNING > OPENDOWNGRADE with nonfile object should return > NFS4ERR_INVAL, instead got NFS4ERR_BAD_STATEID > OPDG9d st_opendowngrade.testDir : WARNING > OPENDOWNGRADE with nonfile object should return > NFS4ERR_INVAL, instead got NFS4ERR_BAD_STATEID > OPDG9f st_opendowngrade.testFifo : WARNING > OPENDOWNGRADE with nonfile object should return > NFS4ERR_INVAL, instead got NFS4ERR_BAD_STATEID > OPDG9s st_opendowngrade.testSocket : WARNING > OPENDOWNGRADE with nonfile object should return > NFS4ERR_INVAL, instead got NFS4ERR_BAD_STATEID Not sure if that's worth fixing. Very low priority. > OPEN16 st_open.testClaimPrev : WARNING > Trying to OPEN with CLAIM_PREVIOUS should return > NFS4ERR_RECLAIM_BAD, instead got NFS4ERR_NO_GRACE Current behavior probably correct. > OPEN19 st_open.testShareConflict2 : FAILURE > Trying to deny write permissions to others when don't > have write permissions should return NFS4ERR_ACCESS, > instead got NFS4_OK Test is wrong; patch submitted to Fred. > OPEN23b st_open.testDenyRead3a : FAILURE > Read an access_write file should return NFS4_OK, > instead got NFS4ERR_IO Might be worth investigating. > RD4 st_read.testLargeCount : WARNING > READ returned 1048576 characters, expected 9000000 Ignore. > RD12 st_read.testOpenMode : FAILURE > READ with file opened in WRITE mode should return > NFS4ERR_OPENMODE, instead got NFS4ERR_IO Eh, maybe should be fixed. Low priority. > RNM16 st_rename.testDirToFullDir : FAILURE > RENAME dir1 into existing, nonempty dir2 should return > NFS4ERR_EXIST, instead got NFS4ERR_NOTEMPTY Might be worth checking. Low priority. > SATT1a st_setattr.testLink : FAILURE > Set attrs {33: 480} not equal to got attrs {33: 511} Probably worth investigating. Medium priority. > SEC7 st_secinfo.testRPCSEC_GSS : FAILURE > SECINFO returned mechanism list without RPCSEC_GSS Configure krb5 on your test client and server if you want to run those tests. > WRT5 st_write.testLargeData : FAILURE > error: [Errno 32] Broken pipe Ignore. --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
