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

[Long Li <leo.lilong@huawei.com>]

On Fri, Nov 15, 2024 at 08:46:13AM -0500, Brian Foster wrote:
> 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.
> 

Yes, forgot to update here.

Thanks,
Long Li