Re: [PATCH v2 1/2] iomap: fix zero padding data issue in concurrent append writes

[Brian Foster <bfoster@redhat.com>]

On Fri, Nov 15, 2024 at 07:53:17PM +0800, Long Li wrote:
> On Thu, Nov 14, 2024 at 01:04:31PM -0500, Brian Foster wrote:
> > On Thu, Nov 14, 2024 at 10:34:26AM +0800, Long Li wrote:
> > > On Wed, Nov 13, 2024 at 11:13:49AM -0500, Brian Foster wrote:
> > > > FYI, you probably want to include linux-fsdevel on iomap patches.
> > > > 
> > > > On Wed, Nov 13, 2024 at 05:19:06PM +0800, Long Li wrote:
> > > > > During concurrent append writes to XFS filesystem, zero padding data
> > > > > may appear in the file after power failure. This happens due to imprecise
> > > > > disk size updates when handling write completion.
> > > > > 
> > > > > Consider this scenario with concurrent append writes same file:
> > > > > 
> > > > >   Thread 1:                  Thread 2:
> > > > >   ------------               -----------
> > > > >   write [A, A+B]
> > > > >   update inode size to A+B
> > > > >   submit I/O [A, A+BS]
> > > > >                              write [A+B, A+B+C]
> > > > >                              update inode size to A+B+C
> > > > >   <I/O completes, updates disk size to A+B+C>
> > > > >   <power failure>
> > > > > 
> > > > > After reboot, file has zero padding in range [A+B, A+B+C]:
> > > > > 
> > > > >   |<         Block Size (BS)      >|
> > > > >   |DDDDDDDDDDDDDDDD0000000000000000|
> > > > >   ^               ^        ^
> > > > >   A              A+B      A+B+C (EOF)
> > > > > 
> > > > 
> > > > Thanks for the diagram. FWIW, I found the description a little confusing
> > > > because A+B+C to me implies that we'd update i_size to the end of the
> > > > write from thread 2, but it seems that is only true up to the end of the
> > > > block.
> > > > 
> > > > I.e., with 4k FSB and if thread 1 writes [0, 2k], then thread 2 writes
> > > > from [2, 16k], the write completion from the thread 1 write will set
> > > > i_size to 4k, not 16k, right?
> > > > 
> > > 
> > > Not right, the problem I'm trying to describe is:
> > > 
> > >   1) thread 1 writes [0, 2k]
> > >   2) thread 2 writes [2k, 3k]
> > >   3) write completion from the thread 1 write set i_size to 3K
> > >   4) power failure
> > >   5) after reboot,  [2k, 3K] of the file filled with zero and the file size is 3k
> > >      
> > 
> > Yeah, I get the subblock case. What I am saying above is it seems like
> > "update inode size to A+B+C" is only true for certain, select values
> > that describe the subblock case. I.e., what is the resulting i_size if
> > we replace C=1k in the example above with something >= FSB size, like
> > C=4k?
> > 
> > Note this isn't all that important. I was just trying to say that the
> > overly general description made this a little more confusing to grok at
> > first than it needed to be, because to me it subtly implies there is
> > logic around somewhere that explicitly writes in-core i_size to disk,
> > when that is not actually what is happening.
> > 
> > > 
> 
> Sorry for my previous misunderstanding. You are correct - my commit
> message description didn't cover the case where A+B+C > block size.
> In such scenarios, the final file size might end up being 4K, which
> is not what we would expect. Initially, I incorrectly thought this
> wasn't a significant issue and thus overlooked this case. Let me
> update the diagram to address this.
> 

Ok no problem.. like I said, just a minor nit. ;)

>   Thread 1:                  Thread 2:
>   ------------               -----------
>   write [A, A+B]
>   update inode size to A+B
>   submit I/O [A, A+BS]
>                              write [A+B, A+B+C]
>                              update inode size to A+B+C
>   <I/O completes, updates disk size to A+B+C>
>   <power failure>
> 
> After reboot:
>   1) The file has zero padding in the range [A+B, A+BS]
>   2) The file size is unexpectedly set to A+BS
> 
>   |<         Block Size (BS)      >|<           Block Size (BS)    >|
>   |DDDDDDDDDDDDDDDD0000000000000000|00000000000000000000000000000000|
>   ^               ^                ^               ^
>   A              A+B              A+BS (EOF)     A+B+C
> 
> 
> It will be update in the next version.
> 

The text above still says "updates disk size to A+B+C." I'm not sure if
you intended to change that to A+BS as well, but regardless LGTM.
Thanks.

Brian

> 
> Thanks,
> Long Li
>