NFSV4 :All lock operations should be sent to the server for resolution
Subsystems (2)
PATCH 1/1 NFSV4 :All lock operations should be sent to the server for resolution
The RFC3530 describes that the client's all lock operations, including those requesting non-exclusive locks, should be sent to the server for resolution, even if it holds a read open delegation. But the kernel implements like that lock operations can be performed locally when a client holds an open delegation.
The following are the RFC3530 provisions for Open Delegation and File Locks:
9.4.2. Open Delegation and File Locks
When a client holds a write open delegation, lock operations may be performed locally. This includes those required for mandatory file locking. This can be done since the delegation implies that there can be no conflicting locks. Similarly, all of the revalidations that would normally be associated with obtaining locks and the flushing of data associated with the releasing of locks need not be done.
When a client holds a read open delegation, lock operations are not performed locally. All lock operations, including those requesting non-exclusive locks, are sent to the server for resolution.
--- fs/nfs/nfs4proc.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)
fs/nfs/nfs4proc.c +0 -7
@@ -4215,13 +4215,6 @@ static int _nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lockif (status <0 ) goto out;down_read (&nfsi->rwsem); -if (test_bit (NFS_DELEGATED_STATE , &state->flags)) { -/* Yes: cache locks! */ -/* ...but avoid races with delegation recall... */ - request->fl_flags = fl_flags & ~FL_SLEEP ; - status =do_vfs_lock (request->fl_file, request); - goto out_unlock; - } status =_nfs4_do_setlk (state, cmd, request,NFS_LOCK_NEW );if (status !=0 ) goto out_unlock;
Signature · 1 line
1.7.3.1
Quoted 18 lines · Fu Liankun
The RFC3530 describes that the client's all lock operations, including those requesting non-exclusive locks, should be sent to the server for resolution, even if it holds a read open delegation. But the kernel implements like that lock operations can be performed locally when a client holds an open delegation.
The following are the RFC3530 provisions for Open Delegation and File Locks:
9.4.2. Open Delegation and File Locks
When a client holds a write open delegation, lock operations may be performed locally. This includes those required for mandatory file locking. This can be done since the delegation implies that there can be no conflicting locks. Similarly, all of the revalidations that would normally be associated with obtaining locks and the flushing of data associated with the releasing of locks need not be done.
Quoted 3 lines
When a client holds a read open delegation, lock operations are not performed locally. All lock operations, including those requesting non-exclusive locks, are sent to the server for resolution.
Weird. Can the rfc really be right about that?
I guess it does permit servers to allow write-locks on read-open files, but it seems bizarre not to require them to break delegations in that case.
--b.
Quoted 31 lines
Signed-off-by Fu Liankun <[email protected]>--- fs/nfs/nfs4proc.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)fs/nfs/nfs4proc.c +0
-7@@ -4215,13 +4215,6 @@ static int _nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lockif (status <0 ) goto out;down_read (&nfsi->rwsem); -if (test_bit (NFS_DELEGATED_STATE , &state->flags)) { -/* Yes: cache locks! */ -/* ...but avoid races with delegation recall... */ - request->fl_flags = fl_flags & ~FL_SLEEP ; - status =do_vfs_lock (request->fl_file, request); - goto out_unlock; - } status =_nfs4_do_setlk (state, cmd, request,NFS_LOCK_NEW );if (status !=0 ) goto out_unlock;Signature · 6 lines
1.7.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 23 lines · J. Bruce Fields
Quoted 18 lines · Fu Liankun
The RFC3530 describes that the client's all lock operations, including those requesting non-exclusive locks, should be sent to the server for resolution, even if it holds a read open delegation. But the kernel implements like that lock operations can be performed locally when a client holds an open delegation.
The following are the RFC3530 provisions for Open Delegation and File Locks:
9.4.2. Open Delegation and File Locks
When a client holds a write open delegation, lock operations may be performed locally. This includes those required for mandatory file locking. This can be done since the delegation implies that there can be no conflicting locks. Similarly, all of the revalidations that would normally be associated with obtaining locks and the flushing of data associated with the releasing of locks need not be done.
Quoted 3 lines
When a client holds a read open delegation, lock operations are not performed locally. All lock operations, including those requesting non-exclusive locks, are sent to the server for resolution.
Quoted 5 lines
Weird. Can the rfc really be right about that?
I guess it does permit servers to allow write-locks on read-open files, but it seems bizarre not to require them to break delegations in that case.
The ability to cache locks is one of the main reasons for holding delegations in the first place. Sure, the spec allows for non-posix locking, but the Linux client doesn't.
IOW: This patch will not be applied.
Trond
Quoted 37 lines
--b.
Quoted 31 lines
Signed-off-by Fu Liankun <[email protected]>--- fs/nfs/nfs4proc.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)fs/nfs/nfs4proc.c +0
-7@@ -4215,13 +4215,6 @@ static int _nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lockif (status <0 ) goto out;down_read (&nfsi->rwsem); -if (test_bit (NFS_DELEGATED_STATE , &state->flags)) { -/* Yes: cache locks! */ -/* ...but avoid races with delegation recall... */ - request->fl_flags = fl_flags & ~FL_SLEEP ; - status =do_vfs_lock (request->fl_file, request); - goto out_unlock; - } status =_nfs4_do_setlk (state, cmd, request,NFS_LOCK_NEW );if (status !=0 ) goto out_unlock;Signature · 6 lines
1.7.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 6 lines
Trond Myklebust Linux NFS client maintainer NetApp [email protected] www.netapp.com
Hi Trond,
Trond Myklebust:
Quoted 25 lines · J. Bruce Fields
Quoted 24 lines · Fu Liankun
Quoted 18 lines
The RFC3530 describes that the client's all lock operations, including those requesting non-exclusive locks, should be sent to the server for resolution, even if it holds a read open delegation. But the kernel implements like that lock operations can be performed locally when a client holds an open delegation.
The following are the RFC3530 provisions for Open Delegation and File Locks:
9.4.2. Open Delegation and File Locks
When a client holds a write open delegation, lock operations may be performed locally. This includes those required for mandatory file locking. This can be done since the delegation implies that there can be no conflicting locks. Similarly, all of the revalidations that would normally be associated with obtaining locks and the flushing of data associated with the releasing of locks need not be done.
Quoted 3 lines
When a client holds a read open delegation, lock operations are not performed locally. All lock operations, including those requesting non-exclusive locks, are sent to the server for resolution.
Weird. Can the rfc really be right about that?
Quoted 7 lines
Quoted 3 lines
I guess it does permit servers to allow write-locks on read-open files, but it seems bizarre not to require them to break delegations in that case.
The ability to cache locks is one of the main reasons for holding delegations in the first place. Sure, the spec allows for non-posix locking, but the Linux client doesn't.
Would you mind tell me some about why we not support non-posix locking at NFS ?
thanks,
Mi Jinlong
Quoted 42 lines
IOW: This patch will not be applied.
Trond
Quoted 36 lines
--b.
Quoted 30 lines
Signed-off-by Fu Liankun <[email protected]>--- fs/nfs/nfs4proc.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)fs/nfs/nfs4proc.c +0
-7@@ -4215,13 +4215,6 @@ static int _nfs4_proc_setlk(struct nfs4_state *state, int cmd, struct file_lockif (status <0 ) goto out;down_read (&nfsi->rwsem); -if (test_bit (NFS_DELEGATED_STATE , &state->flags)) { -/* Yes: cache locks! */ -/* ...but avoid races with delegation recall... */ - request->fl_flags = fl_flags & ~FL_SLEEP ; - status =do_vfs_lock (request->fl_file, request); - goto out_unlock; - } status =_nfs4_do_setlk (state, cmd, request,NFS_LOCK_NEW );if (status !=0 ) goto out_unlock;Signature · 6 lines
1.7.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Mi Jinlong
Hi Trond,
Trond Myklebust:
Quoted 3 lines
The ability to cache locks is one of the main reasons for holding delegations in the first place. Sure, the spec allows for non-posix locking, but the Linux client doesn't.
Would you mind tell me some about why we not support non-posix locking at NFS ?
For the very obvious reason that Linux applications are coded under the assumption that the kernel implements POSIX locking semantics. Why would we want to implement support for NFS features that can cause perfectly correctly coded applications to hang and crash?
Trond
Signature · 6 lines
Trond Myklebust Linux NFS client maintainer NetApp [email protected] www.netapp.com