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

[Daniel Gomez <da.gomez@kernel.org>]

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.

> 
> 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.

> 
> 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.