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

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

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.

  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.


Thanks,
Long Li