Interoperability for lock implementation with macOS client about nfs4j HOT 9 OPEN

I can reproduce the issue. The client/server interaction looks like:

 -> OPEN file1, open_owner1
 <- OPEN fh1, open_stateid1
 -> OPEN_CONFIRM open_stateid1
 <- OPEN_CONFIRM OK
 -> LOCK fh1, new lock owner: true, open_owner1, open_stateid1
 <- LOCK lock_stateid1
 -> LOCKU lock_stateid1
 <- LOCKU OK
 -> CLOSE fh1, open_stateid1
 <- CLOSE OK

so far so good. But then:

 -> OPEN file1, open_owner1
 <- OPEN fh1, open_stateid2
 -> OPEN_CONFIRM open_stateid2
 <- OPEN_CONFIRM OK
 -> LOCK fh1, new lock owner: false, lock_stateid1
 <- LOCK BAD_STATEID

capture file

IOW, client send second LOCK request, but uses lock_stateid1. My reading of https://tools.ietf.org/html/rfc7530#section-16.2.5 tells me, that CLOSE invalidates all locking stats, e.q. old lock_state1 is invalid.

I ask IETF-nfs4 working group to comment on it.

from nfs4j.

@kofemann Can I be of any help to advance the resolution of this issue?

from nfs4j.

@dkocher I have discussed the locking issue with NFS community and conclusion is that osx client is broken. However, I understand, that waiting for fix from apple is not an option. I will check how to a workaround to make osx client happy.

from nfs4j.

@kofemann Let me know if I can be of any help.

from nfs4j.

@dkocher Thanks for the offer. I need to find out a way how to keep expired lock-owners andl treat them as valid. This is orthogonal to the state handling implementation we have in place. But I did not forget this issue. Thinking some times takes longer time than implementing.....

from nfs4j.

@dkocher a shot update on this issue.

bad new: it looks like we can't fix it on the server side as by receiving invalid state id on lock
server has no sufficient information to 'guess' file's open state.

good news: looks like with latest osx update client recovers from the locking issue by itself. If re-sends open+lock with a new lock owner.

I have sent some traces and described the problem to apple. Let see what will happen.
here is a simple python code to trigger the error:

import sys
import os
import fcntl

if len(sys.argv) != 2:
  print('Usage: locktest <file>')
  sys.exit(1)

fname = sys.argv[1]  

f = os.open(fname, os.O_RDONLY)
fcntl.lockf(f, fcntl.LOCK_SH, 0, 100000000)
fcntl.lockf(f, fcntl.LOCK_UN, 0, 100000000)
os.close(f)

f = os.open(fname, os.O_RDONLY)
fcntl.lockf(f, fcntl.LOCK_SH, 0, 100000000)
fcntl.lockf(f, fcntl.LOCK_UN, 0, 100000000)
os.close(f)

from nfs4j.

This ist still a blocker issue. I have tested with macOS 10.13 and applications that depend on locks fail writing to the volume and do not recover.

Reverting aeb7544 would solve the error. Is there any option to introduce some compatibility mode (shudder)?

from nfs4j.

Well, technically, you suggest to keep old lock state-id around to identify lock owner by invalidated state-id. This will introduce state-id leak and eventually you will hit OOM.

Unfortunately osx developers completely ignore broken NFS client. As a workaround, we can put them into some-kind fixed size cache and remove them as needed. Ugly, but can work.

from nfs4j.

Even if fixed in later macOS versions we usually want to support two or more previous major versions. It would be awesome if you could introduce a map that is cleanup up using some deferred algorithm.

from nfs4j.