From: walter harms <wharms-fPG8STNUNVg@public.gmane.org>
To: NeilBrown <neilb-IBi9RG/b67k@public.gmane.org>
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH manpages] write.2, fsync.2, close.2: update description of error codes
Date: Thu, 14 Sep 2017 09:59:01 +0200 [thread overview]
Message-ID: <59BA36C5.9000506@bfs.de> (raw)
In-Reply-To: <87ingm9n04.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
Am 14.09.2017 01:50, schrieb NeilBrown:
>
> Since 4.13, errors from writeback are more reliably reported
> to all file descriptors that might be relevant.
>
> Add notes to this effect, and also add details about ENOSPC and EDQUOT
> which can be delayed in a similar manner to EIO - for NFS in particular.
>
I never read EDQUOT before but it is real:
see:
http://elixir.free-electrons.com/linux/latest/source/security/keys/request_key.c
-EDQUOT
* if insufficient key quota was available to create a new key
> Signed-off-by: NeilBrown <neilb-IBi9RG/b67k@public.gmane.org>
> ---
>
> This is my summary of recent changes, and details that have been made
> clear during the exploration of those changes.
>
> I haven't mentioned the fact that EPERM can be returned by
> write/fsync/close on NFS if the permissions on the server are changed.
> We probably should ... are there other errors that are worth mentioning
> along with EPERM, ENOSPC, EDQUOT ??
>
> Thanks,
> NeilBronw
>
>
> man2/close.2 | 9 +++++++++
> man2/fsync.2 | 19 ++++++++++++++++++-
> man2/write.2 | 20 +++++++++++++++++---
> 3 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/man2/close.2 b/man2/close.2
> index 751ec322b1f1..9776c839b8b6 100644
> --- a/man2/close.2
> +++ b/man2/close.2
> @@ -82,6 +82,15 @@ call was interrupted by a signal; see
> .TP
> .B EIO
> An I/O error occurred.
> +.TP
> +.BR ENOSPC ", " EDQUOT
> +On NFS, these errors are not normally reported against the first write
> +which exceeds the available storage space, but instead against a
> +subsequent
> +.BR write (2),
> +.BR fsync (2),
> +or
> +.BR close (2).
> .PP
> See NOTES for a discussion of why
> .BR close ()
> diff --git a/man2/fsync.2 b/man2/fsync.2
> index f1a01301da0f..e706a08d360d 100644
> --- a/man2/fsync.2
> +++ b/man2/fsync.2
> @@ -120,12 +120,29 @@ is set appropriately.
> is not a valid open file descriptor.
> .TP
> .B EIO
> -An error occurred during synchronization.
> +An error occurred during synchronization. This error may relate
> +to data written to some other file descriptor on the same file.
> +.\" commit 088737f44bbf6378745f5b57b035e57ee3dc4750
> +Since Linux 4.13 errors from write-back will be reported to
> +all file descriptors that might have written the data which triggered
> +the error, and which are still open. Some filesystems (e.g. NFS)
> +keep close track of which data came through which file descriptor,
> +and give more precise reporting. Other filesystems (e.g. most local
> +filesystems) will report errors to all file descriptors on the same
> +file.
> .TP
> .BR EROFS ", " EINVAL
> .I fd
> is bound to a special file (e.g., a pipe, FIFO, or socket)
> which does not support synchronization.
> +.TP
> +.BR ENOSPC ", " EDQUOT
> +.I fd
> +is bound to a file on NFS or another filesystem which does not allocate
> +space at the time of a
> +.BR write (2)
> +system call, and some previous write failed due to insufficient
> +storage space.
> .SH CONFORMING TO
> POSIX.1-2001, POSIX.1-2008, 4.3BSD.
> .SH AVAILABILITY
> diff --git a/man2/write.2 b/man2/write.2
> index 6a39b5b5541d..1a9a86b03b04 100644
> --- a/man2/write.2
> +++ b/man2/write.2
> @@ -47,7 +47,7 @@ write \- write to a file descriptor
> .BR write ()
> writes up to
> .I count
> -bytes from the buffer pointed
> +bytes from the buffer starting at
> .I buf
> to the file referred to by the file descriptor
> .IR fd .
> @@ -181,6 +181,14 @@ or the file offset is not suitably aligned.
> .TP
> .B EIO
> A low-level I/O error occurred while modifying the inode.
> +This error may relate to data written by an earlier
> +.BR write (2),
> +which may have been issued to a different file descriptor on
> +the same file. Since Linux 4.13 errors from write-back will
> +be reported to all file descriptors that might have
> +written the data which triggered the error, and which are still
> +open.
> +.\" commit 088737f44bbf6378745f5b57b035e57ee3dc4750
> .TP
> .B ENOSPC
> The device containing the file referred to by
> @@ -222,8 +230,14 @@ unsigned and signed integer data types specified by POSIX.1.
> A successful return from
> .BR write ()
> does not make any guarantee that data has been committed to disk.
> -In fact, on some buggy implementations, it does not even guarantee
> -that space has successfully been reserved for the data.
> +On some filesystems, including NFS, it does not even guarantee
> +that space has successfully been reserved for the data. In the case,
> +some errors might be delayed to a future
> +.BR write (2)
> +or to
> +.BR fsync (2)
> +or even
> +.BR close (2).
> The only way to be sure is to call
> .BR fsync (2)
> after you are done writing all your data.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-09-14 7:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-20 19:42 [PATCH] nfs: track writeback errors with errseq_t Jeff Layton
2017-08-25 17:59 ` Jeff Layton
2017-08-27 23:24 ` NeilBrown
2017-08-28 11:47 ` Jeff Layton
2017-08-29 1:23 ` NeilBrown
2017-08-29 10:54 ` Jeff Layton
2017-09-07 3:37 ` NeilBrown
2017-09-07 11:35 ` Jeff Layton
2017-09-07 14:54 ` Trond Myklebust
2017-09-07 14:54 ` Trond Myklebust
2017-09-11 3:24 ` NeilBrown
2017-09-11 10:46 ` Jeff Layton
2017-09-11 21:52 ` NeilBrown
2017-09-12 15:20 ` Jeff Layton
2017-09-12 21:47 ` NeilBrown
2017-09-13 12:23 ` Jeff Layton
2017-09-13 23:50 ` [RFC PATCH manpages] write.2, fsync.2, close.2: update description of error codes NeilBrown
2017-09-13 23:50 ` NeilBrown
[not found] ` <87ingm9n04.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-09-14 7:59 ` walter harms [this message]
[not found] ` <59BA36C5.9000506-fPG8STNUNVg@public.gmane.org>
2017-09-14 22:36 ` NeilBrown
2017-09-14 10:48 ` Jeff Layton
2017-09-14 10:48 ` Jeff Layton
2017-09-15 7:50 ` Michael Kerrisk (man-pages)
[not found] ` <28da8888-e8f9-31d5-a3dd-d3c2a5e9037a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-09-15 8:25 ` NeilBrown
2017-09-15 8:25 ` NeilBrown
[not found] ` <1505386139.4870.10.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-09-28 3:01 ` NeilBrown
2017-09-28 3:01 ` NeilBrown
[not found] ` <87fub75xxr.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-09-28 12:20 ` Jeff Layton
2017-09-28 12:20 ` Jeff Layton
2017-09-28 16:19 ` Michael Kerrisk (man-opages)
2017-09-12 2:24 ` [PATCH] nfs: track writeback errors with errseq_t Trond Myklebust
2017-09-12 2:24 ` Trond Myklebust
2017-09-12 5:29 ` NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59BA36C5.9000506@bfs.de \
--to=wharms-fpg8stnunvg@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=neilb-IBi9RG/b67k@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.