Re: [RFC PATCH v2 0/5] Add buffered write-through support to iomap & xfs

[Ojaswin Mujoo]

On Tue, Jun 02, 2026 at 07:47:43AM +0200, Christoph Hellwig wrote:
> On Mon, Jun 01, 2026 at 10:19:18PM +0530, Ojaswin Mujoo wrote:
> > 
> > So this week I spent some time looking into the failure of g/457. 
> > I was able to replicate it in my setup and after analysing it, this is
> > actually an issue in my xfstests patch. The issue is that to verify
> > RWF_WRITETHROUGH support I do a 4kb write on the fd during the test prep
> > phase. However "out-of-band" write makes the actual contents of the file
> > different from what fsx expected (It reads it in before the problematic
> > write), causing the test failure. 
> 
> Why does this get out of sync?  One of the arguments for RWF_WRITETHROUGH
> vs direct I/O was that it avoids the content getting out of sync.
> 

Hey Christoph, I think I was a bit vague in my explanation. So this
issue is not in the kernel but in fsx. Basically fsx does something
like:

1. Read in the file contents and store it in a local good_buffer
2. Detect support for various IO types (writethrough, dontcache etc)
  2.1 To detect writethrough support, I perform a 
	pwrite("4kb of 0s", file, flag=RWF_WRITETHROUGH) and look out for
	EOPNOTSUPP.
3. Start running the test
  3.1 Whenever we perform a write operation in fsx we use fsx write
	wrappers which also update the good_buffer before writing to file.
4. During fsync, we write the good_buffer to a golden output file and
   also set a dm_logwrite mark. Later, we replay the dm_logwrites mark
	 and then check if the file matches the golden o/p file.

The issue here is that fsx's golden output was not correct cause in step
2.1 I was using pwritev2() directly instead of using fsx wrappers to do
the write which was not updating the good_buffer. Hence, good_buffer
went out of sync from what was actually supposed to be in the file.
g/457 thought this was a corruption however it was a bug in my fsx
writethrough support patch.

Regards,
ojaswin