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
