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

[Ojaswin Mujoo]

On Tue, Jun 16, 2026 at 03:57:21PM +0200, Daniel Gomez wrote:
> On 01/06/2026 18.49, Ojaswin Mujoo wrote:
> > On Wed, May 13, 2026 at 11:14:21AM +0530, Ojaswin Mujoo wrote:
> >> On Mon, May 04, 2026 at 09:54:49AM +0200, Daniel Gomez wrote:
> >>> On 08/04/2026 20.45, Ojaswin Mujoo wrote:
> > diff --git a/ltp/fsx.c b/ltp/fsx.c
> > index 720bca83..1c76634b 100644
> > --- a/ltp/fsx.c
> > +++ b/ltp/fsx.c
> > @@ -2077,16 +2077,34 @@ test_dontcache_io(void)
> >         return 1;
> >  }
> > 
> > +/*
> > + * Use a temporary file to test RWF_WRITETHROUGH so as to not modify the
> > + * original. This is so that fsx expected contents and the actual contents
> > + * of the original file don't go out of sync
> > + */
> >  int
> >  test_writethrough_io(void)
> >  {
> >         char buf[4096];
> > +       char tmpname[PATH_MAX];
> > +       int tmp_fd;
> >         struct iovec iov = { .iov_base = buf, .iov_len = sizeof(buf) };
> >         int ret, e;
> > 
> > +       snprintf(tmpname, sizeof(tmpname), "%s.fsx.XXXXXX", fname);
> > +
> > +       tmp_fd = mkstemp(tmpname);
> > +       if (fd < 0) {
> > +               perror("test_writethrough_io: mkstemp() failed\n");
> > +               exit(132);
> > +       }
> > +
> >         memset(buf, '\0', sizeof(buf));
> > -       ret = pwritev2(fd, &iov, 1, 0, RWF_WRITETHROUGH);
> > +       ret = pwritev2(tmp_fd, &iov, 1, 0, RWF_WRITETHROUGH);
> >         e = ret < 0 ? errno : 0;
> > +
> > +       close(tmp_fd);
> > +
> >         if (e == EOPNOTSUPP) {
> >                 if (!quiet)
> >                         fprintf(stderr,
> > 
> 
> 
> I think this is missing:
> 
> @@ -2158,12 +2175,6 @@ test_writethrough_io(void)
>                 return 0;
>         }
> 
> -       if (ftruncate(fd, file_size) != 0) {
> -               perror("test_writethrough_io: failed to ftruncate to 0\n");
> -               exit(132);
> -       }
> -
> -
> 
> The fix works for me after a stress loop test on generic/457.

Awesome! and yes since we use a different file now, we can remove the
ftruncate() call.

> 
> > 
> > Im unable to replicate the 415 failure, but this one is strange because it
> > doesn't involve any writethrough IO. In you previous runs have you seen
> > this be flaky?
> 
> I couldn't confirm back then, so I think we can ignore it. Also, unrelated.

Okay.

> 
> > 
> > Admittedly, I've not yet started thorough testing since this is in early
> > RFC and the design is still getting finalized but I appriciate the help
> > in testing this.
> 
> 
> No problem. IMHO, testing makes a design more robust, once the path is
> agreed on. That said, do you think the path needs changing? Reading LWN
> and the patch series threads, I don't see any blocker. You can cc me for
> the next iteration and I'll follow up with more testing.

Yes definitely and really appreciate your help in testing this. As for
the design, the current design suffer when many writers are writing to
the same file, because the inode lock critical section is increased. So
I'm trying out a few optimizations that will lead to some non-trivial
design changes (like deferring the IO to outside the inode lock). 

I'm in process of preparing and benchmarking the new design and would
hopefully post it soon. I'll keep you in loop, thanks.

Regards,
ojaswin