[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230417112006.3bzzitsxy67jpviq@quack3>
Date: Mon, 17 Apr 2023 13:20:06 +0200
From: Jan Kara <jack@...e.cz>
To: "Ritesh Harjani (IBM)" <ritesh.list@...il.com>
Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
Jan Kara <jack@...e.cz>, Christoph Hellwig <hch@...radead.org>,
"Darrick J . Wong" <djwong@...nel.org>,
Ojaswin Mujoo <ojaswin@...ux.ibm.com>,
Disha Goel <disgoel@...ux.ibm.com>,
Christoph Hellwig <hch@....de>
Subject: Re: [PATCHv5 5/9] ext2: Move direct-io to use iomap
On Sun 16-04-23 15:38:40, Ritesh Harjani (IBM) wrote:
> This patch converts ext2 direct-io path to iomap interface.
> - This also takes care of DIO_SKIP_HOLES part in which we return -ENOTBLK
> from ext2_iomap_begin(), in case if the write is done on a hole.
> - This fallbacks to buffered-io in case of DIO_SKIP_HOLES or in case of
> a partial write or if any error is detected in ext2_iomap_end().
> We try to return -ENOTBLK in such cases.
> - For any unaligned or extending DIO writes, we pass
> IOMAP_DIO_FORCE_WAIT flag to ensure synchronous writes.
> - For extending writes we set IOMAP_F_DIRTY in ext2_iomap_begin because
> otherwise with dsync writes on devices that support FUA, generic_write_sync
> won't be called and we might miss inode metadata updates.
> - Since ext2 already now uses _nolock vartiant of sync write. Hence
> there is no inode lock problem with iomap in this patch.
> - ext2_iomap_ops are now being shared by DIO, DAX & fiemap path
>
> Tested-by: Disha Goel <disgoel@...ux.ibm.com>
> Reviewed-by: Christoph Hellwig <hch@....de>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@...il.com>
One comment below:
> @@ -844,6 +868,13 @@ static int
> ext2_iomap_end(struct inode *inode, loff_t offset, loff_t length,
> ssize_t written, unsigned flags, struct iomap *iomap)
> {
> + /*
> + * Switch to buffered-io in case of any error.
> + * Blocks allocated can be used by the buffered-io path.
> + */
> + if ((flags & IOMAP_DIRECT) && (flags & IOMAP_WRITE) && written == 0)
> + return -ENOTBLK;
> +
> if (iomap->type == IOMAP_MAPPED &&
> written < length &&
> (flags & IOMAP_WRITE))
Is this really needed? What for?
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists