archive mirror
 help / color / mirror / Atom feed
From: Goldwyn Rodrigues <>
To: "Theodore Y. Ts'o" <>
Subject: Re: [PATCH v7 2/2] Return bytes transferred for partial direct I/O
Date: Sun, 20 May 2018 08:54:58 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 05/19/2018 08:29 PM, Theodore Y. Ts'o wrote:
> On Thu, Feb 08, 2018 at 12:59:48PM -0600, Goldwyn Rodrigues wrote:
>> From: Goldwyn Rodrigues <>
>> In case direct I/O encounters an error midway, it returns the error.
>> Instead it should be returning the number of bytes transferred so far.
>> Test case for filesystems (with ENOSPC):
>> 1. Create an almost full filesystem
>> 2. Create a file, say /mnt/lastfile, until the filesystem is full.
>> 3. Direct write() with count > sizeof /mnt/lastfile.
>> Result: write() returns -ENOSPC. However, file content has data written
>> in step 3.
>> Added a sysctl entry: dio_short_writes which is on by default. This is
>> to support applications which expect either and error or the bytes submitted
>> as a return value for the write calls.
>> This fixes fstest generic/472.
>> Signed-off-by: Goldwyn Rodrigues <>
> Hi,
> I was wondering if you could give an update regarding what's up with
> this patch?
> There doesn't seem to be any movement on this patch in a while, and so
> I still have xfstests generic/472 suppressed in {kvm,gce}-xfstests.

>From earlier discussions, In between errors of a direct I/O cannot be
handled correctly and may need a lot of tracking that it is not worth

It would be better to drop this test case and add in the documentation
that a direct I/O error could mean that the write() may or may not have
occurred and underlying data may be inconsistent. I am proposing:

diff --git a/man2/write.2 b/man2/write.2
index f8a94f3ff..86f655e26 100644
--- a/man2/write.2
+++ b/man2/write.2
@@ -274,6 +274,14 @@ On Linux,
 returning the number of bytes actually transferred.
 .\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
 (This is true on both 32-bit and 64-bit systems.)
+While performing
+.BR write()
+using direct I/O, an error returned does not mean the
+entire write has failed. Partial data may be written
+and the file offset to length on which the
+.BR write()
+was attempted should be considered inconsistent.
 According to POSIX.1-2008/SUSv4 Section XSI 2.9.7
 ("Thread Interactions with Regular File Operations"):


  reply	other threads:[~2018-05-20 13:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08 18:59 [PATCH v7 1/2] xfs: remove assert to check bytes returned Goldwyn Rodrigues
2018-02-08 18:59 ` [PATCH v7 2/2] Return bytes transferred for partial direct I/O Goldwyn Rodrigues
2018-03-08  0:53   ` Darrick J. Wong
2018-03-08 15:35     ` Goldwyn Rodrigues
2018-03-08 17:29       ` Darrick J. Wong
2018-05-20  1:29   ` Theodore Y. Ts'o
2018-05-20 13:54     ` Goldwyn Rodrigues [this message]
2018-02-09  4:52 ` [PATCH v7 1/2] xfs: remove assert to check bytes returned Darrick J. Wong

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).