Re: [PATCH v7 2/2] Return bytes transferred for partial direct I/O
From: Goldwyn Rodrigues <hidden>
Date: 2018-05-20 13:55:02
Also in:
linux-block, linux-fsdevel
Subsystem:
the rest · Maintainer:
Linus Torvalds
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:quoted
From: Goldwyn Rodrigues <redacted> 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 <redacted>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 performing. 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.) +.PP +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. .SH BUGS According to POSIX.1-2008/SUSv4 Section XSI 2.9.7 ("Thread Interactions with Regular File Operations"):
--
Goldwyn