lkml.org 
[lkml]   [2006]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [patch] call truncate_inode_pages in the DIO fallback to buffered I/O path
On Wed, 11 Oct 2006 12:48:57 -0400
jmoyer@redhat.com wrote:

> ==> Regarding Re: [patch] call truncate_inode_pages in the DIO fallback to buffered I/O path; Andrew Morton <akpm@osdl.org> adds:
>
> akpm> Patch is below. The end result looks like:
>
>
> akpm> /* coalesce the iovecs and go direct-to-BIO for O_DIRECT */
> akpm> if (unlikely(file->f_flags & O_DIRECT)) {
> akpm> loff_t endbyte;
> akpm> ssize_t written_buffered;
>
> akpm> written = generic_file_direct_write(iocb, iov, &nr_segs, pos,
> akpm> ppos, count, ocount);
> akpm> if (written < 0 || written == count)
> akpm> goto out;
> akpm> /*
> akpm> * direct-io write to a hole: fall through to buffered I/O
> akpm> * for completing the rest of the request.
> akpm> */
> akpm> pos += written;
> akpm> count -= written;
> akpm> written_buffered = generic_file_buffered_write(iocb, iov,
> akpm> nr_segs, pos, ppos, count,
> akpm> written);
>
> akpm> /*
> akpm> * We need to ensure that the page cache pages are written to
> akpm> * disk and invalidated to preserve the expected O_DIRECT
> akpm> * semantics.
> akpm> */
> akpm> endbyte = pos + written_buffered - 1;
>
> We probably want to handle the case where generic_file_buffered_write
> returns an error or nothing written.

If generic_file_buffered_write() returned an error, we want to save that
error code somewhere.

If generic_file_buffered_write() didn't actually write anything then that's
pretty weird, but the following code should handle that correctly and do
the right thing. So perhaps that case is so rare it isn't worth the
test-n-branch to optimise for it?


> akpm> err = do_sync_file_range(file, pos, endbyte,
> akpm> SYNC_FILE_RANGE_WAIT_BEFORE|
> akpm> SYNC_FILE_RANGE_WRITE|
> akpm> SYNC_FILE_RANGE_WAIT_AFTER);
> akpm> if (err == 0) {
> akpm> written += written_buffered;
> akpm> invalidate_mapping_pages(mapping,
> akpm> pos >> PAGE_CACHE_SHIFT,
> akpm> endbyte >> PAGE_CACHE_SHIFT);
>
> generic_file_buffered_write takes written as an argument, and returns that
> amount plus whatever it managed to write.

How weird.

> As such, you don't want to add
> written_buffered to written. Instead, you want written = written_buffered.
> The endbyte calculation has to be altered in kind.

OK.

> Incremental, locally tested patch attached. Comments are welcome as
> always. Once there is consensus, I'll send this off for testing with
> Oracle again.


So I'd propose:

diff -puN mm/filemap.c~direct-io-sync-and-invalidate-file-region-when-falling-back-to-buffered-write-fix mm/filemap.c
--- a/mm/filemap.c~direct-io-sync-and-invalidate-file-region-when-falling-back-to-buffered-write-fix
+++ a/mm/filemap.c
@@ -2291,19 +2291,30 @@ __generic_file_aio_write_nolock(struct k
written_buffered = generic_file_buffered_write(iocb, iov,
nr_segs, pos, ppos, count,
written);
+ /*
+ * If generic_file_buffered_write() retuned a synchronous error
+ * then we want to return the number of bytes which were
+ * direct-written, or the error code if that was zero. Note
+ * that this differs from normal direct-io semantics, which
+ * will return -EFOO even if some bytes were written.
+ */
+ if (written_buffered < 0) {
+ err = written_buffered;
+ goto out;
+ }

/*
* We need to ensure that the page cache pages are written to
* disk and invalidated to preserve the expected O_DIRECT
* semantics.
*/
- endbyte = pos + written_buffered - 1;
+ endbyte = pos + written_buffered - written - 1;
err = do_sync_file_range(file, pos, endbyte,
SYNC_FILE_RANGE_WAIT_BEFORE|
SYNC_FILE_RANGE_WRITE|
SYNC_FILE_RANGE_WAIT_AFTER);
if (err == 0) {
- written += written_buffered;
+ written = written_buffered;
invalidate_mapping_pages(mapping,
pos >> PAGE_CACHE_SHIFT,
endbyte >> PAGE_CACHE_SHIFT);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-10-11 20:41    [W:0.084 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site