On Tue, Apr 28, 2015 at 04:44:55PM -0400, J. Bruce Fields wrote:
> This causes a failure on pynfs OPEN23b.
I've once again tried to run pynfs, but I'm still errors out with weird
python backtraces for any of the examples from the readme I copy
and pasted, e.g.:
root@vm:~/pynfs/nfs4.0# ./testserver.py 127.0.0.1:/mnt/test --maketree all
Initialization failed, no tests run.
Traceback (most recent call last):
File "./testserver.py", line 379, in <module>
main()
File "./testserver.py", line 342, in main
env.init()
File "/root/pynfs/nfs4.0/servertests/environment.py", line 140, in init
self._maketree()
File "/root/pynfs/nfs4.0/servertests/environment.py", line 159, in _maketree
"Could not LOOKUP /%s," % '/'.join(path))
File "/root/pynfs/nfs4.0/servertests/environment.py", line 274, in checklist
raise testmod.FailureException(msg)
testmod.FailureException: Could not LOOKUP /mnt, should return NFS4_OK or NFS4ERR_NOENT, instead got NFS4ERR_PERM
root@vm:~/pynfs/nfs4.1# ./testserver.py 127.0.0.1:/mnt/test --maketree all
Could not find gssapi module, proceeding without
INFO :rpc.poll:got connection from ('127.0.0.1', 37715), assigned to fd=5
INFO :rpc.thread:Called connect(('127.0.0.1', 2049))
INFO :rpc.poll:Adding 6 generated by another thread
INFO :test.env:Created client to 127.0.0.1, 2049
INFO :nfs.client.cb:********************
INFO :nfs.client.cb:Handling CB_NULL
Initialization failed, no tests run.
Traceback (most recent call last):
File "./testserver.py", line 359, in <module>
main()
File "./testserver.py", line 322, in main
env.init()
File "/root/pynfs/nfs4.1/server41tests/environment.py", line 150, in init
self._maketree(sess)
File "/root/pynfs/nfs4.1/server41tests/environment.py", line 166, in _maketree
"LOOKUP /%s," % '/'.join(path))
File "/root/pynfs/nfs4.1/server41tests/environment.py", line 304, in checklist
raise testmod.FailureException(msg)
testmod.FailureException: LOOKUP /mnt, should return NFS4_OK or NFS4ERR_NOENT, instead got NFS4ERR_PERM
> It's doing a READ using a stateid from a write open. We previously
> returned NFS_OK, taking the "may" option from:
>
> http://tools.ietf.org/html/rfc7530#page-111
>
> In the case of READ, the server may perform the corresponding
> check on the access mode, or it may choose to allow READ on
> opens for WRITE only, to accommodate clients whose write
> implementation may unavoidably do reads (e.g., due to buffer
> cache constraints).
>
> OPENMODE might also have been OK, but we're returning SERVERFAULT. I
> guess the old code was passing preprocess_stateid_op without returning a
> file, then relying on a temporary open for the read? Ugh.
Looks like it. I can change it to return an OPENMODE, or we could
make it fall back to a temp read open.
--
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
