All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Bobrowski <mbobrowski@mbobrowski.org>
To: tytso@mit.edu, jack@suse.cz, adilger.kernel@dilger.ca
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	hch@infradead.org, david@fromorbit.com, darrick.wong@oracle.com
Subject: [PATCH v5 02/12] ext4: iomap that extends beyond EOF should be marked dirty
Date: Mon, 21 Oct 2019 20:17:46 +1100	[thread overview]
Message-ID: <995387be9841bde2151c85880555c18bec68a641.1571647179.git.mbobrowski@mbobrowski.org> (raw)
In-Reply-To: <cover.1571647178.git.mbobrowski@mbobrowski.org>

This patch is effectively addressed what Dave Chinner had found and
fixed within this commit: 8a23414ee345. Justification for needing this
modification has been provided below:

When doing a direct IO that spans the current EOF, and there are
written blocks beyond EOF that extend beyond the current write, the
only metadata update that needs to be done is a file size extension.

However, we don't mark such iomaps as IOMAP_F_DIRTY to indicate that
there is IO completion metadata updates required, and hence we may
fail to correctly sync file size extensions made in IO completion when
O_DSYNC writes are being used and the hardware supports FUA.

Hence when setting IOMAP_F_DIRTY, we need to also take into account
whether the iomap spans the current EOF. If it does, then we need to
mark it dirty so that IO completion will call generic_write_sync() to
flush the inode size update to stable storage correctly.

Signed-off-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
---
 fs/ext4/inode.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 158eea9a1944..0dd29ae5cc8c 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3412,8 +3412,14 @@ static void ext4_set_iomap(struct inode *inode, struct iomap *iomap,
 {
 	u8 blkbits = inode->i_blkbits;
 
+	/*
+	 * Writes that span EOF might trigger an I/O size update on completion,
+	 * so consider them to be dirty for the purposes of O_DSYNC, even if
+	 * there is no other metadata changes being made or are pending here.
+	 */
 	iomap->flags = 0;
-	if (ext4_inode_datasync_dirty(inode))
+	if (ext4_inode_datasync_dirty(inode) ||
+	    offset + length > i_size_read(inode))
 		iomap->flags |= IOMAP_F_DIRTY;
 
 	if (map->m_flags & EXT4_MAP_NEW)
-- 
2.20.1

--<M>--

  parent reply	other threads:[~2019-10-21  9:17 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21  9:17 [PATCH v5 00/12] ext4: port direct I/O to iomap infrastructure Matthew Bobrowski
2019-10-21  9:17 ` [PATCH v5 01/12] ext4: move set iomap routines into separate helper ext4_set_iomap() Matthew Bobrowski
2019-10-21 13:23   ` Jan Kara
2019-10-23  6:31   ` Ritesh Harjani
2019-10-23 10:14     ` Matthew Bobrowski
2019-10-21  9:17 ` Matthew Bobrowski [this message]
2019-10-21 13:28   ` [PATCH v5 02/12] ext4: iomap that extends beyond EOF should be marked dirty Jan Kara
2019-10-22  1:49     ` Matthew Bobrowski
2019-10-23  6:35   ` Ritesh Harjani
2019-10-23 10:20     ` Matthew Bobrowski
2019-10-21  9:18 ` [PATCH v5 03/12] ext4: split IOMAP_WRITE branch in ext4_iomap_begin() into helper Matthew Bobrowski
2019-10-21 13:31   ` Jan Kara
2019-10-23  6:37   ` Ritesh Harjani
2019-10-21  9:18 ` [PATCH v5 04/12] ext4: introduce new callback for IOMAP_REPORT Matthew Bobrowski
2019-10-21 13:37   ` Jan Kara
2019-10-22  1:55     ` Matthew Bobrowski
2019-10-23  6:39       ` Ritesh Harjani
2019-10-23 10:35         ` Matthew Bobrowski
2019-10-21  9:18 ` [PATCH v5 05/12] iomap: Allow forcing of waiting for running DIO in iomap_dio_rw() mbobrowski
2019-10-24  1:41   ` Christoph Hellwig
2019-10-24 11:17     ` Matthew Bobrowski
2019-10-21  9:18 ` [PATCH v5 06/12] xfs: Use iomap_dio_rw_wait() mbobrowski
2019-10-21 13:38   ` Jan Kara
2019-10-21  9:18 ` [PATCH v5 07/12] ext4: introduce direct I/O read using iomap infrastructure Matthew Bobrowski
2019-10-21 13:41   ` Jan Kara
2019-10-22  1:58     ` Matthew Bobrowski
2019-10-23  6:40   ` Ritesh Harjani
2019-10-21  9:18 ` [PATCH v5 08/12] ext4: update direct I/O read to do trylock in IOCB_NOWAIT cases Matthew Bobrowski
2019-10-21 13:48   ` Jan Kara
2019-10-22  2:04     ` Matthew Bobrowski
2019-10-22  7:50       ` Jan Kara
2019-10-23  6:51   ` Ritesh Harjani
2019-10-21  9:18 ` [PATCH v5 09/12] ext4: move inode extension/truncate code out from ->iomap_end() callback Matthew Bobrowski
2019-10-21 13:53   ` Jan Kara
2019-10-22  2:07     ` Matthew Bobrowski
2019-10-21  9:20 ` [PATCH v5 12/12] ext4: introduce direct I/O write using iomap infrastructure Matthew Bobrowski
2019-10-21 16:18   ` Jan Kara
2019-10-22  3:02     ` Matthew Bobrowski
2019-10-22  7:55       ` Jan Kara
2019-10-21  9:20 ` [PATCH v5 11/12] ext4: reorder map->m_flags checks in ext4_set_iomap() Matthew Bobrowski
2019-10-21  9:20 ` [PATCH v5 10/12] ext4: move inode extension check out from ext4_iomap_alloc() Matthew Bobrowski
2019-10-21 13:31 ` [PATCH v5 00/12] ext4: port direct I/O to iomap infrastructure Theodore Y. Ts'o
2019-10-21 19:43   ` Jan Kara
2019-10-21 22:38     ` Dave Chinner
2019-10-22  8:01       ` Jan Kara
2019-10-23  2:35     ` Matthew Bobrowski
2019-10-23 10:01       ` Jan Kara
2019-10-23 10:11         ` Matthew Bobrowski
2019-10-24  1:58           ` Christoph Hellwig
2019-10-24 11:09             ` Matthew Bobrowski

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=995387be9841bde2151c85880555c18bec68a641.1571647179.git.mbobrowski@mbobrowski.org \
    --to=mbobrowski@mbobrowski.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.