fcntl.2, read.2, write.2: document "Lost locks" as cause for EIO.
Subsystems (4)
PATCH 1/1 fcntl.2, read.2, write.2: document "Lost locks" as cause for EIO.
If an advisory lock is lost, then read/write requests on any affected file descriptor can return EIO - for NFSv4 at least.
--- man2/fcntl.2 | 24 ++++++++++++++++++++++++ man2/read.2 | 9 +++++++++ man2/write.2 | 9 +++++++++ 3 files changed, 42 insertions(+)
man2/fcntl.2 +24 -0
@@ -669,6 +669,30 @@ and Mandatory locking is not specified by POSIX. Some other systems also support mandatory locking, although the details of how to enable it vary across systems. +.SS Lost locks +When an advisory lock is obtained on a networked filesystem such as +NFS it is possible that the lock might get lost. +This may happen due to administrative action on the server, or due to a +network partition which lasts long enough for the server to assume +that the client is no longer functioning. +.PP +When the filesystem determines that a lock has been lost, future +.BR read (2) +or +.BR write (2) +requests may fail with the error +.BR EIO . +This error will persist until the lock is removed or the file +descriptor is closed. +Since Linux 3.12, +.\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d +this happens at least for NFSv4 including all minor versions. +.PP +Some versions of Unix send a signal +.RB ( SIGLOST ) +in this circumstance. +Linux does not define this signal, and does not provide any +asynchronous notification of lost locks. .SS Managing signals .BR F_GETOWN , .BR F_SETOWN ,
man2/read.2 +9 -0
@@ -163,6 +163,15 @@ or its process group is orphaned. It may also occur when there is a low-level I/O error while reading from a disk or tape. +A further possible cause of +.B EIO +on networked filesystems is when an advisory lock had been taken +out on the file descriptor and this lock has been lost. +See the +.I "Lost locks" +section of +.BR fcntl (2) +for further details. .TP .B EISDIR .I fd
man2/write.2 +9 -0
@@ -197,6 +197,15 @@ be reported by a subsequent (whether or not they were also reported by .BR write (2)). .\" commit 088737f44bbf6378745f5b57b035e57ee3dc4750 +An alternate cause of +.B EIO +on networked filesystems is when an advisory lock had been taken out +on the file descriptor and this lock has been lost. +See the +.I "Lost locks" +section of +.BR fcntl (2) +for further details. .TP .B ENOSPC The device containing the file referred to by
Signature · 1 line
2.14.0.rc0.dirty
Hello Neil
There's a piece of your patch I don't understand. Please see below.
Quoted 16 lines · NeilBrown
If an advisory lock is lost, then read/write requests on any affected file descriptor can return EIO - for NFSv4 at least.
Signed-off-by NeilBrown <[email protected]>--- man2/fcntl.2 | 24 ++++++++++++++++++++++++ man2/read.2 | 9 +++++++++ man2/write.2 | 9 +++++++++ 3 files changed, 42 insertions(+)man2/fcntl.2 +0
-0
man2/fcntl.2 and · line 676
Quoted 8 lines
man2/fcntl.2 +5
-0@@ -669,6 +669,30 @@ and Mandatory locking is not specified by POSIX. Some other systems also support mandatory locking, although the details of how to enable it vary across systems. +.SS Lost locks +When an advisory lock is obtained on a networked filesystem such as +NFS it is possible that the lock might get lost. +This may happen due to administrative action on the server, or due to a +network partition which lasts long enough for the server to assume
What does "network partition which lasts long enough" mean? I think this perhaps needs to be clarified a little. At least, I don't understand it.
Cheers,
Michael
Quoted 63 lines
man2/fcntl.2 +19
-0+that the client is no longer functioning. +.PP +When the filesystem determines that a lock has been lost, future +.BR read (2) +or +.BR write (2) +requests may fail with the error +.BR EIO . +This error will persist until the lock is removed or the file +descriptor is closed. +Since Linux 3.12, +.\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d +this happens at least for NFSv4 including all minor versions. +.PP +Some versions of Unix send a signal +.RB ( SIGLOST ) +in this circumstance. +Linux does not define this signal, and does not provide any +asynchronous notification of lost locks. .SS Managing signals .BR F_GETOWN , .BR F_SETOWN ,man2/read.2 +9
-0@@ -163,6 +163,15 @@ or its process group is orphaned. It may also occur when there is a low-level I/O error while reading from a disk or tape. +A further possible cause of +.B EIO +on networked filesystems is when an advisory lock had been taken +out on the file descriptor and this lock has been lost. +See the +.I "Lost locks" +section of +.BR fcntl (2) +for further details. .TP .B EISDIR .I fdman2/write.2 +9
-0@@ -197,6 +197,15 @@ be reported by a subsequent (whether or not they were also reported by .BR write (2)). .\" commit 088737f44bbf6378745f5b57b035e57ee3dc4750 +An alternate cause of +.B EIO +on networked filesystems is when an advisory lock had been taken out +on the file descriptor and this lock has been lost. +See the +.I "Lost locks" +section of +.BR fcntl (2) +for further details. .TP .B ENOSPC The device containing the file referred to by
Signature · 3 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Quoted 25 lines · Michael Kerrisk (man-pages)
Hello Neil
There's a piece of your patch I don't understand. Please see below.
Quoted 20 lines · NeilBrown
If an advisory lock is lost, then read/write requests on any affected file descriptor can return EIO - for NFSv4 at least.
Signed-off-by NeilBrown <neilb-IBi9RG/[email protected]>--- man2/fcntl.2 | 24 ++++++++++++++++++++++++ man2/read.2 | 9 +++++++++ man2/write.2 | 9 +++++++++ 3 files changed, 42 insertions(+)man2/fcntl.2 +1
-0@@ -669,6 +669,30 @@ and Mandatory locking is not specified by POSIX. Some other systems also support mandatory locking, although the details of how to enable it vary across systems. +.SS Lost locks
Quoted 8 lines
man2/fcntl.2 and · line 676
Quoted 4 lines
man2/fcntl.2 +4
-0+When an advisory lock is obtained on a networked filesystem such as +NFS it is possible that the lock might get lost. +This may happen due to administrative action on the server, or due to a +network partition which lasts long enough for the server to assumeWhat does "network partition which lasts long enough" mean? I think this perhaps needs to be clarified a little. At least, I don't understand it.
"network partition" is a term using the NFS RFCs for any situation that that results in the server and client not being able to communicate (that are partitioned, one from the other? There is partition (wall) between them? They are in separate partitions?).
I can see how the meaning might not be obvious if you hadn't come across it before.
If we change "network partition" to "loss of connectivity", would that make it clear. Is "loss of network connectivity with the server" too verbose?
Thanks,
NeilBrown
Quoted 75 lines
Cheers,
Michael
Quoted 63 lines
man2/fcntl.2 +19
-0+that the client is no longer functioning. +.PP +When the filesystem determines that a lock has been lost, future +.BR read (2) +or +.BR write (2) +requests may fail with the error +.BR EIO . +This error will persist until the lock is removed or the file +descriptor is closed. +Since Linux 3.12, +.\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d +this happens at least for NFSv4 including all minor versions. +.PP +Some versions of Unix send a signal +.RB ( SIGLOST ) +in this circumstance. +Linux does not define this signal, and does not provide any +asynchronous notification of lost locks. .SS Managing signals .BR F_GETOWN , .BR F_SETOWN ,man2/read.2 +9
-0@@ -163,6 +163,15 @@ or its process group is orphaned. It may also occur when there is a low-level I/O error while reading from a disk or tape. +A further possible cause of +.B EIO +on networked filesystems is when an advisory lock had been taken +out on the file descriptor and this lock has been lost. +See the +.I "Lost locks" +section of +.BR fcntl (2) +for further details. .TP .B EISDIR .I fdman2/write.2 +9
-0@@ -197,6 +197,15 @@ be reported by a subsequent (whether or not they were also reported by .BR write (2)). .\" commit 088737f44bbf6378745f5b57b035e57ee3dc4750 +An alternate cause of +.B EIO +on networked filesystems is when an advisory lock had been taken out +on the file descriptor and this lock has been lost. +See the +.I "Lost locks" +section of +.BR fcntl (2) +for further details. .TP .B ENOSPC The device containing the file referred to bySignature · 3 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Quoted 43 lines · NeilBrown
Quoted 25 lines · Michael Kerrisk (man-pages)
Hello Neil
There's a piece of your patch I don't understand. Please see below.
Quoted 20 lines · NeilBrown
If an advisory lock is lost, then read/write requests on any affected file descriptor can return EIO - for NFSv4 at least.
Signed-off-by NeilBrown <neilb-IBi9RG/[email protected]>--- man2/fcntl.2 | 24 ++++++++++++++++++++++++ man2/read.2 | 9 +++++++++ man2/write.2 | 9 +++++++++ 3 files changed, 42 insertions(+)man2/fcntl.2 +1
-0@@ -669,6 +669,30 @@ and Mandatory locking is not specified by POSIX. Some other systems also support mandatory locking, although the details of how to enable it vary across systems. +.SS Lost locksQuoted 8 lines
man2/fcntl.2 and · line 676
Quoted 4 lines
man2/fcntl.2 +4
-0+When an advisory lock is obtained on a networked filesystem such as +NFS it is possible that the lock might get lost. +This may happen due to administrative action on the server, or due to a +network partition which lasts long enough for the server to assumeWhat does "network partition which lasts long enough" mean? I think this perhaps needs to be clarified a little. At least, I don't understand it.
"network partition" is a term using the NFS RFCs for any situation that that results in the server and client not being able to communicate (that are partitioned, one from the other? There is partition (wall) between them? They are in separate partitions?).
I can see how the meaning might not be obvious if you hadn't come across it before.
Quoted 3 lines
If we change "network partition" to "loss of connectivity", would that make it clear. Is "loss of network connectivity with the server" too verbose?
Thanks, Neil. I've applied your patch and added the words "loss of network connectivity with the server".
Cheers,
Michael
Signature · 7 lines
Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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 44 lines · Michael Kerrisk (man-pages)
Quoted 43 lines · NeilBrown
Quoted 25 lines · Michael Kerrisk (man-pages)
Hello Neil
There's a piece of your patch I don't understand. Please see below.
Quoted 20 lines · NeilBrown
If an advisory lock is lost, then read/write requests on any affected file descriptor can return EIO - for NFSv4 at least.
Signed-off-by NeilBrown <[email protected]>--- man2/fcntl.2 | 24 ++++++++++++++++++++++++ man2/read.2 | 9 +++++++++ man2/write.2 | 9 +++++++++ 3 files changed, 42 insertions(+)man2/fcntl.2 +1
-0@@ -669,6 +669,30 @@ and Mandatory locking is not specified by POSIX. Some other systems also support mandatory locking, although the details of how to enable it vary across systems. +.SS Lost locksQuoted 8 lines
man2/fcntl.2 and · line 676
Quoted 4 lines
man2/fcntl.2 +4
-0+When an advisory lock is obtained on a networked filesystem such as +NFS it is possible that the lock might get lost. +This may happen due to administrative action on the server, or due to a +network partition which lasts long enough for the server to assumeWhat does "network partition which lasts long enough" mean? I think this perhaps needs to be clarified a little. At least, I don't understand it.
"network partition" is a term using the NFS RFCs for any situation that that results in the server and client not being able to communicate (that are partitioned, one from the other? There is partition (wall) between them? They are in separate partitions?).
I can see how the meaning might not be obvious if you hadn't come across it before.
Quoted 6 lines
Quoted 3 lines
If we change "network partition" to "loss of connectivity", would that make it clear. Is "loss of network connectivity with the server" too verbose?
Thanks, Neil. I've applied your patch and added the words "loss of network connectivity with the server".
Looks good. Thanks!
NeilBrown