diff mbox series

[02/13] iomap: treat inline data in iomap_writepage_map as an I/O error

Message ID 20231126124720.1249310-3-hch@lst.de (mailing list archive)
State New, archived
Headers show
Series [01/13] iomap: clear the per-folio dirty bits on all writeback failures | expand

Commit Message

Christoph Hellwig Nov. 26, 2023, 12:47 p.m. UTC
iomap_writepage_map aready warns about inline data, but then just ignores
it.  Treat it as an error and return -EIO.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/iomap/buffered-io.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Comments

Ritesh Harjani (IBM) Nov. 27, 2023, 5:01 a.m. UTC | #1
Christoph Hellwig <hch@lst.de> writes:

> iomap_writepage_map aready warns about inline data, but then just ignores
> it.  Treat it as an error and return -EIO.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/iomap/buffered-io.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

The code change looks very obvious. But sorry that I have some queries
which I would like to clarify - 

The dirty page we are trying to write can always belong to the dirty
inode with inline data in it right? 
So it is then the FS responsibility to un-inline the inode in the
->map_blocks call is it?

Looking at the gfs2 code, it might as well return iomap->type as
IOMAP_INLINE for IOMAP_WRITE request in it's iomap_writeback_ops no?
    iomap_writeback_ops -> gfs2_map_blocks -> __gfs2_iomap_get

>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 98d52feb220f0a..b1bcc43baf0caf 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1818,8 +1818,10 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc,
>  		if (error)
>  			break;
>  		trace_iomap_writepage_map(inode, &wpc->iomap);
> -		if (WARN_ON_ONCE(wpc->iomap.type == IOMAP_INLINE))
> -			continue;
> +		if (WARN_ON_ONCE(wpc->iomap.type == IOMAP_INLINE)) {
> +			error = -EIO;
> +			break;
> +		}
>  		if (wpc->iomap.type == IOMAP_HOLE)
>  			continue;
>  		iomap_add_to_ioend(inode, pos, folio, ifs, wpc, wbc,
> -- 
> 2.39.2

-ritesh
Christoph Hellwig Nov. 27, 2023, 6:33 a.m. UTC | #2
On Mon, Nov 27, 2023 at 10:31:31AM +0530, Ritesh Harjani wrote:
> The code change looks very obvious. But sorry that I have some queries
> which I would like to clarify - 
> 
> The dirty page we are trying to write can always belong to the dirty
> inode with inline data in it right? 

Yes.

> So it is then the FS responsibility to un-inline the inode in the
> ->map_blocks call is it?

I think they way it currently works for gfs2 is that writeback from the
page cache never goes back into the inline area.  

If we ever have a need to actually write back inline data we could
change this code to support it, but right now I just want to make the
assert more consistent.
Darrick J. Wong Nov. 29, 2023, 4:40 a.m. UTC | #3
On Mon, Nov 27, 2023 at 07:33:25AM +0100, Christoph Hellwig wrote:
> On Mon, Nov 27, 2023 at 10:31:31AM +0530, Ritesh Harjani wrote:
> > The code change looks very obvious. But sorry that I have some queries
> > which I would like to clarify - 
> > 
> > The dirty page we are trying to write can always belong to the dirty
> > inode with inline data in it right? 
> 
> Yes.
> 
> > So it is then the FS responsibility to un-inline the inode in the
> > ->map_blocks call is it?
> 
> I think they way it currently works for gfs2 is that writeback from the
> page cache never goes back into the inline area.  
> 
> If we ever have a need to actually write back inline data we could
> change this code to support it, but right now I just want to make the
> assert more consistent.

Question: Do we even /want/ writeback to be initiating transactions
to log the inline data?  I suppose for ext4/jbd2 that would be the least
inefficient time to do that.

--D
Christoph Hellwig Nov. 29, 2023, 5:39 a.m. UTC | #4
On Tue, Nov 28, 2023 at 08:40:57PM -0800, Darrick J. Wong wrote:
> > I think they way it currently works for gfs2 is that writeback from the
> > page cache never goes back into the inline area.  
> > 
> > If we ever have a need to actually write back inline data we could
> > change this code to support it, but right now I just want to make the
> > assert more consistent.
> 
> Question: Do we even /want/ writeback to be initiating transactions
> to log the inline data?  I suppose for ext4/jbd2 that would be the least
> inefficient time to do that.

I think in general not, but it really depends on the file system
architecture.  In other words:  don't touch the current behavior unless
we have a good reason.  I just want to make the error check a little
saner..
diff mbox series

Patch

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 98d52feb220f0a..b1bcc43baf0caf 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1818,8 +1818,10 @@  iomap_writepage_map(struct iomap_writepage_ctx *wpc,
 		if (error)
 			break;
 		trace_iomap_writepage_map(inode, &wpc->iomap);
-		if (WARN_ON_ONCE(wpc->iomap.type == IOMAP_INLINE))
-			continue;
+		if (WARN_ON_ONCE(wpc->iomap.type == IOMAP_INLINE)) {
+			error = -EIO;
+			break;
+		}
 		if (wpc->iomap.type == IOMAP_HOLE)
 			continue;
 		iomap_add_to_ioend(inode, pos, folio, ifs, wpc, wbc,