public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: "Pankaj Raghav (Samsung)" <pankaj.raghav@linux.dev>,
	Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	djwong@kernel.org, john.g.garry@oracle.com, willy@infradead.org,
	hch@lst.de, jack@suse.cz, Luis Chamberlain <mcgrof@kernel.org>,
	dgc@kernel.org, tytso@mit.edu, p.raghav@samsung.com,
	andres@anarazel.de, brauner@kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v2 0/5] Add buffered write-through support to iomap & xfs
Date: Fri, 24 Apr 2026 05:39:23 +0530	[thread overview]
Message-ID: <340lte18.ritesh.list@gmail.com> (raw)
In-Reply-To: <4og3axdvzyfpfx4o2rhcnwdsggha2kfoerausxx52vd6jc2hzq@u72iwxrxxble>

"Pankaj Raghav (Samsung)" <pankaj.raghav@linux.dev> writes:

>> 
>> 
>> * Testing Notes (UPDATED) *
>> 
>> - I've added support for RWF_WRITETHROUGH to fsx and fsstress in
>>   xfstests and these patches survive fsx with integrity verification as
>>   well as fsstress parallel stressing.
>> - -g quick with blocks size == page size and blocksize < pagesize shows
>>   no new regressions.
>
> I am hitting a very strange error in generic/127. I deconstructed it in
> to two commands that can reproduce the issue:
>
> ```
> $ dd if=/dev/zero of=/media/test/fsx_lite_nommap bs=262144 count=1
>
> $ /root/home/xfstests/ltp/fsx -l 262144 -o 65536 -S 191110531 -N 100000 -L -R -W /media/test/fsx_lite_nommap
> mapped writes DISABLED
> Seed set to 191110531
> main: filesystem does not support exchange range, disabling!
> main: atomic writes need O_DIRECT (-Z), disabling!
> short read: 0x0 bytes instead of 0x6c7f
> LOG DUMP (1 total operations):
> 1(  1 mod 256): READ     0x39381 thru 0x3ffff   (0x6c7f bytes)
> Log of operations saved to "/media/test/fsx_lite_nommap.fsxops"; replay with --replay-ops
> fsx: save_buffer: .fsxgood file too short... will save 0x0 bytes instead of 0x40000
> : Operation not supported
> Correct content saved for comparison
> (maybe hexdump "/media/test/fsx_lite_nommap" vs "/media/test/fsx_lite_nommap.fsxgood")
> ```


This looks like fsx has a problem where while testing writethrough
support we ftruncate the file size to 0 instead of file_size.

@Ojaswin,

I think we should have it like this I guess.

diff --git a/ltp/fsx.c b/ltp/fsx.c
index c9901f65..3b11b1b5 100644
--- a/ltp/fsx.c
+++ b/ltp/fsx.c
@@ -2095,7 +2095,7 @@ test_writethrough_io(void)
                return 0;
        }

-       if (ftruncate(fd, 0) != 0) {
+       if (!lite && ftruncate(fd, file_size) != 0) {
                perror("test_writethrough_io: failed to ftruncate to 0\n");
                exit(132);
        }

-ritesh

>
> This is on a bs == ps (4k block size) xfs filesystem.
> ```
> $ xfs_info /media/test/
> meta-data=/dev/nvme1n1           isize=512    agcount=4, agsize=2097152 blks
>          =                       sectsz=4096  attr=2, projid32bit=1
>          =                       crc=1        finobt=1, sparse=1, rmapbt=0
>          =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
> data     =                       bsize=4096   blocks=8388608, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
> log      =internal log           bsize=4096   blocks=16384, version=2
>          =                       sectsz=4096  sunit=1 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> ```
>
> The same test passes if I pass `-G` to fsx parameters(disabling writethrough).
>
> The error is coming when we do a read operation which feels very
> strange. Could you run this in your setup and see if you can reproduce
> them? I still do not know where the issue is coming from or it is
> because of my test setup.
>
> --
> Pankaj

      parent reply	other threads:[~2026-04-24  0:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 18:45 [RFC PATCH v2 0/5] Add buffered write-through support to iomap & xfs Ojaswin Mujoo
2026-04-08 18:45 ` [RFC PATCH v2 1/5] mm: Refactor folio_clear_dirty_for_io() Ojaswin Mujoo
2026-04-15  6:14   ` Christoph Hellwig
2026-04-23 10:12     ` Ojaswin Mujoo
2026-04-08 18:45 ` [RFC PATCH v2 2/5] iomap: Add initial support for buffered RWF_WRITETHROUGH Ojaswin Mujoo
2026-04-16 12:05   ` Jan Kara
2026-04-16 12:34   ` Jan Kara
2026-04-17 19:42     ` Ojaswin Mujoo
2026-04-20 11:28       ` Jan Kara
2026-04-21 18:07         ` Ojaswin Mujoo
2026-04-22 10:00           ` Jan Kara
2026-04-23 10:08             ` Ojaswin Mujoo
2026-04-17  4:13   ` Pankaj Raghav (Samsung)
2026-04-18  7:33     ` Ojaswin Mujoo
2026-04-20 11:56   ` Pankaj Raghav (Samsung)
2026-04-21 18:15     ` Ojaswin Mujoo
2026-04-22  6:19       ` Pankaj Raghav
2026-04-22  6:40         ` Ritesh Harjani
2026-04-08 18:45 ` [RFC PATCH v2 3/5] xfs: Add RWF_WRITETHROUGH support to xfs Ojaswin Mujoo
2026-04-08 18:45 ` [RFC PATCH v2 4/5] iomap: Add aio support to RWF_WRITETHROUGH Ojaswin Mujoo
2026-04-08 18:45 ` [RFC PATCH v2 5/5] iomap: Add DSYNC support to writethrough Ojaswin Mujoo
2026-04-17  3:54 ` [RFC PATCH v2 0/5] Add buffered write-through support to iomap & xfs Pankaj Raghav (Samsung)
2026-04-18  7:26   ` Ojaswin Mujoo
2026-04-23 12:25 ` Pankaj Raghav (Samsung)
2026-04-23 23:53   ` Ojaswin Mujoo
2026-04-24  0:17     ` Ritesh Harjani
2026-04-24 10:44       ` Pankaj Raghav
2026-04-24  0:09   ` Ritesh Harjani [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=340lte18.ritesh.list@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=andres@anarazel.de \
    --cc=brauner@kernel.org \
    --cc=dgc@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=john.g.garry@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=p.raghav@samsung.com \
    --cc=pankaj.raghav@linux.dev \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox