Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1638221 > unrolled thread

[PATCH v4 16/27] fs: adapt sync_file_range to new reporting infrastructure

Started byJeff Layton <jlayton@redhat.com>
First post2017-05-09 18:00 +0200
Last post2017-05-09 18:00 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v4 16/27] fs: adapt sync_file_range to new reporting infrastructure Jeff Layton <jlayton@redhat.com> - 2017-05-09 18:00 +0200

#1638221 — [PATCH v4 16/27] fs: adapt sync_file_range to new reporting infrastructure

FromJeff Layton <jlayton@redhat.com>
Date2017-05-09 18:00 +0200
Subject[PATCH v4 16/27] fs: adapt sync_file_range to new reporting infrastructure
Message-ID<tFfIm-3IS-31@gated-at.bofh.it>
Since it returns errors in a way similar to fsync, have it use the same
method for returning previously-reported writeback errors.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
 fs/sync.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/fs/sync.c b/fs/sync.c
index 11ba023434b1..89a03b5252d2 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -271,8 +271,11 @@ SYSCALL_DEFINE1(fdatasync, unsigned int, fd)
  *
  *
  * SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
- * I/O errors or ENOSPC conditions and will return those to the caller, after
- * clearing the EIO and ENOSPC flags in the address_space.
+ * error condition that occurred prior to or after writeback, and will return
+ * that to the caller, while advancing the file's errseq_t cursor. Note that
+ * any errors returned here may have occurred in an area of the file that is
+ * not covered by the given range as most filesystems track writeback errors
+ * on a per-address_space basis
  *
  * It should be noted that none of these operations write out the file's
  * metadata.  So unless the application is strictly performing overwrites of
@@ -282,7 +285,7 @@ SYSCALL_DEFINE1(fdatasync, unsigned int, fd)
 SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, loff_t, nbytes,
 				unsigned int, flags)
 {
-	int ret;
+	int ret, ret2;
 	struct fd f;
 	struct address_space *mapping;
 	loff_t endbyte;			/* inclusive */
@@ -356,7 +359,9 @@ SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, loff_t, nbytes,
 
 	if (flags & SYNC_FILE_RANGE_WAIT_AFTER)
 		ret = filemap_fdatawait_range(mapping, offset, endbyte);
-
+	ret2 = filemap_report_wb_error(f.file);
+	if (!ret)
+		ret = ret2;
 out_put:
 	fdput(f);
 out:
-- 
2.9.3

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web