[PATCHSET] fstests: more random fixes for v2025.10.05

[PATCHSET] fstests: more random fixes for v2025.10.05

[Darrick J. Wong]

Hi all,

Here's the usual odd fixes for fstests.

If you're going to start using this code, I strongly recommend pulling
from my git trees, which are linked below.

With a bit of luck, this should all go splendidly.
Comments and questions are, as always, welcome.

--D

kernel git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=random-fixes

xfsprogs git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=random-fixes

fstests git tree:
https://git.kernel.org/cgit/linux/kernel/git/djwong/xfstests-dev.git/log/?h=random-fixes
---
Commits in this patchset:
 * generic/427: try to ensure there's some free space before we do the aio test
 * common/rc: fix _require_xfs_io_shutdown
 * generic/742: avoid infinite loop if no fiemap results
 * generic/{482,757}: skip test if there are no FUA writes
 * generic/772: actually check for file_getattr special file support
 * common/filter: fix _filter_file_attributes to handle xfs file flags
 * common/attr: fix _require_noattr2
 * common: fix _require_xfs_io_command pwrite -A for various blocksizes
---
 common/attr        |    4 ++++
 common/filter      |    3 ++-
 common/rc          |   21 +++++++++++++++++----
 src/fiemap-fault.c |   14 +++++++++++++-
 tests/generic/427  |    3 +++
 tests/generic/482  |    2 +-
 tests/generic/757  |    2 +-
 tests/generic/772  |    3 +++
 tests/xfs/648      |    3 +++
 9 files changed, 47 insertions(+), 8 deletions(-)

[PATCH 1/8] generic/427: try to ensure there's some free space before we do the aio test

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

On a filesystem configured like this:
MKFS_OPTIONS="-m metadir=1,autofsck=1,uquota,gquota,pquota -d rtinherit=1 -r zoned=1"

This test fails like this:

--- a/tests/generic/427.out      2025-04-30 16:20:44.584246582 -0700
+++ b/tests/generic/427.out.bad        2025-07-14 10:47:07.605377287 -0700
@@ -1,2 +1,2 @@
 QA output created by 427
-Success, all done.
+pwrite: No space left on device

The pwrite failure comes from the aio-dio-eof-race.c program because the
filesystem ran out of space.  There are no speculative posteof
preallocations on a zoned filesystem, so let's skip this test on those
setups.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 tests/generic/427 |    3 +++
 1 file changed, 3 insertions(+)


diff --git a/tests/generic/427 b/tests/generic/427
index bddfdb8714e9a7..bb20d9f44a2b5a 100755
--- a/tests/generic/427
+++ b/tests/generic/427
@@ -28,6 +28,9 @@ _require_no_compress
 _scratch_mkfs_sized $((256 * 1024 * 1024)) >>$seqres.full 2>&1
 _scratch_mount
 
+# Zoned filesystems don't support speculative preallocations
+_require_inplace_writes $SCRATCH_MNT
+
 # try to write more bytes than filesystem size to fill the filesystem,
 # then remove all these data. If we still can find these stale data in
 # a file' eofblock, then it's a bug

Re: [PATCH 1/8] generic/427: try to ensure there's some free space before we do the aio test

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 1/8] generic/427: try to ensure there's some free space before we do the aio test

[Zorro Lang]

On Wed, Oct 15, 2025 at 09:36:58AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> On a filesystem configured like this:
> MKFS_OPTIONS="-m metadir=1,autofsck=1,uquota,gquota,pquota -d rtinherit=1 -r zoned=1"
> 
> This test fails like this:
> 
> --- a/tests/generic/427.out      2025-04-30 16:20:44.584246582 -0700
> +++ b/tests/generic/427.out.bad        2025-07-14 10:47:07.605377287 -0700
> @@ -1,2 +1,2 @@
>  QA output created by 427
> -Success, all done.
> +pwrite: No space left on device

Hahah, I just felt weird, why g/427 failed as:

   QA output created by 427
  -pwrite: No space left on device
  +Success, all done.

then I found `git am` treats above commit log as part of the patch :-D Please add
some blanks to above fail messages.

BTW, I decided not to merge this patchset in today's release, due to I haven't gotten
time to give it enough test. I'll try to merge it (or part of it) in next release .
Sorry for the late.

Thanks,
Zorro

> 
> The pwrite failure comes from the aio-dio-eof-race.c program because the
> filesystem ran out of space.  There are no speculative posteof
> preallocations on a zoned filesystem, so let's skip this test on those
> setups.
> 
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  tests/generic/427 |    3 +++
>  1 file changed, 3 insertions(+)
> 
> 
> diff --git a/tests/generic/427 b/tests/generic/427
> index bddfdb8714e9a7..bb20d9f44a2b5a 100755
> --- a/tests/generic/427
> +++ b/tests/generic/427
> @@ -28,6 +28,9 @@ _require_no_compress
>  _scratch_mkfs_sized $((256 * 1024 * 1024)) >>$seqres.full 2>&1
>  _scratch_mount
>  
> +# Zoned filesystems don't support speculative preallocations
> +_require_inplace_writes $SCRATCH_MNT
> +
>  # try to write more bytes than filesystem size to fill the filesystem,
>  # then remove all these data. If we still can find these stale data in
>  # a file' eofblock, then it's a bug
> 

Re: [PATCH 1/8] generic/427: try to ensure there's some free space before we do the aio test

[Darrick J. Wong]

On Mon, Oct 20, 2025 at 10:16:39PM +0800, Zorro Lang wrote:
> On Wed, Oct 15, 2025 at 09:36:58AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > On a filesystem configured like this:
> > MKFS_OPTIONS="-m metadir=1,autofsck=1,uquota,gquota,pquota -d rtinherit=1 -r zoned=1"
> > 
> > This test fails like this:
> > 
> > --- a/tests/generic/427.out      2025-04-30 16:20:44.584246582 -0700
> > +++ b/tests/generic/427.out.bad        2025-07-14 10:47:07.605377287 -0700
> > @@ -1,2 +1,2 @@
> >  QA output created by 427
> > -Success, all done.
> > +pwrite: No space left on device
> 
> Hahah, I just felt weird, why g/427 failed as:
> 
>    QA output created by 427
>   -pwrite: No space left on device
>   +Success, all done.
> 
> then I found `git am` treats above commit log as part of the patch :-D Please add
> some blanks to above fail messages.
> 
> BTW, I decided not to merge this patchset in today's release, due to I haven't gotten
> time to give it enough test. I'll try to merge it (or part of it) in next release .
> Sorry for the late.

Will clean up and push out.  Though now that there's an xfsprogs 6.17
release I guess I'll rerun everything with that and push out the
bugfixes tomorrow instead of today.

--D

> Thanks,
> Zorro
> 
> > 
> > The pwrite failure comes from the aio-dio-eof-race.c program because the
> > filesystem ran out of space.  There are no speculative posteof
> > preallocations on a zoned filesystem, so let's skip this test on those
> > setups.
> > 
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  tests/generic/427 |    3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > 
> > diff --git a/tests/generic/427 b/tests/generic/427
> > index bddfdb8714e9a7..bb20d9f44a2b5a 100755
> > --- a/tests/generic/427
> > +++ b/tests/generic/427
> > @@ -28,6 +28,9 @@ _require_no_compress
> >  _scratch_mkfs_sized $((256 * 1024 * 1024)) >>$seqres.full 2>&1
> >  _scratch_mount
> >  
> > +# Zoned filesystems don't support speculative preallocations
> > +_require_inplace_writes $SCRATCH_MNT
> > +
> >  # try to write more bytes than filesystem size to fill the filesystem,
> >  # then remove all these data. If we still can find these stale data in
> >  # a file' eofblock, then it's a bug
> > 
> 

[PATCH 2/8] common/rc: fix _require_xfs_io_shutdown

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Capturing the output of _scratch_shutdown_handle requires one to enclose
the callsite with $(), otherwise you're comparing the literal string
"_scratch_shutdown_handle" to $SCRATCH_MNT, which always fails.

Also fix _require_xfs_io_command to handle testing the shutdown command
correctly.

Cc: <fstests@vger.kernel.org> # v2025.06.22
Fixes: 4b1cf3df009b22 ("fstests: add helper _require_xfs_io_shutdown")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 common/rc |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)


diff --git a/common/rc b/common/rc
index 1ec84263c917c0..1b78cd0c358bb9 100644
--- a/common/rc
+++ b/common/rc
@@ -619,7 +619,7 @@ _scratch_shutdown_and_syncfs()
 # requirement down to _require_scratch_shutdown.
 _require_xfs_io_shutdown()
 {
-	if [ _scratch_shutdown_handle != $SCRATCH_MNT ]; then
+	if [ $(_scratch_shutdown_handle) != $SCRATCH_MNT ]; then
 		# Most likely overlayfs
 		_notrun "xfs_io -c shutdown not supported on $FSTYP"
 	fi
@@ -3073,6 +3073,11 @@ _require_xfs_io_command()
 		rm -f $testfile.1
 		param_checked="$param"
 		;;
+	"shutdown")
+		testio=$($XFS_IO_PROG -f -x -c "$command $param" $testfile 2>&1)
+		param_checked="$param"
+		_test_cycle_mount
+		;;
 	"utimes" )
 		testio=`$XFS_IO_PROG -f -c "utimes 0 0 0 0" $testfile 2>&1`
 		;;

Re: [PATCH 2/8] common/rc: fix _require_xfs_io_shutdown

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 2/8] common/rc: fix _require_xfs_io_shutdown

[Nirjhar Roy (IBM)]

On Wed, 2025-10-15 at 09:37 -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Capturing the output of _scratch_shutdown_handle requires one to enclose
> the callsite with $(), otherwise you're comparing the literal string
> "_scratch_shutdown_handle" to $SCRATCH_MNT, which always fails.
> 
> Also fix _require_xfs_io_command to handle testing the shutdown command
> correctly.
> 
> Cc: <fstests@vger.kernel.org> # v2025.06.22
> Fixes: 4b1cf3df009b22 ("fstests: add helper _require_xfs_io_shutdown")
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  common/rc |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/common/rc b/common/rc
> index 1ec84263c917c0..1b78cd0c358bb9 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -619,7 +619,7 @@ _scratch_shutdown_and_syncfs()
>  # requirement down to _require_scratch_shutdown.
>  _require_xfs_io_shutdown()
>  {
> -	if [ _scratch_shutdown_handle != $SCRATCH_MNT ]; then
> +	if [ $(_scratch_shutdown_handle) != $SCRATCH_MNT ]; then
Yeah, right. _scratch_shutdown_handle is a function call and should be placed in a $() or ``. 
>  		# Most likely overlayfs
>  		_notrun "xfs_io -c shutdown not supported on $FSTYP"
>  	fi
> @@ -3073,6 +3073,11 @@ _require_xfs_io_command()
>  		rm -f $testfile.1
>  		param_checked="$param"
>  		;;
> +	"shutdown")
> +		testio=$($XFS_IO_PROG -f -x -c "$command $param" $testfile 2>&1)
> +		param_checked="$param"
> +		_test_cycle_mount
> +		;;
Looks good to me. Just curious, any reason why we are testing with TEST_DIR and not with
SCRATCH_MNT? 
Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
>  	"utimes" )
>  		testio=`$XFS_IO_PROG -f -c "utimes 0 0 0 0" $testfile 2>&1`
>  		;;
> 

Re: [PATCH 2/8] common/rc: fix _require_xfs_io_shutdown

[Darrick J. Wong]

On Fri, Oct 24, 2025 at 01:01:50PM +0530, Nirjhar Roy (IBM) wrote:
> On Wed, 2025-10-15 at 09:37 -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Capturing the output of _scratch_shutdown_handle requires one to enclose
> > the callsite with $(), otherwise you're comparing the literal string
> > "_scratch_shutdown_handle" to $SCRATCH_MNT, which always fails.
> > 
> > Also fix _require_xfs_io_command to handle testing the shutdown command
> > correctly.
> > 
> > Cc: <fstests@vger.kernel.org> # v2025.06.22
> > Fixes: 4b1cf3df009b22 ("fstests: add helper _require_xfs_io_shutdown")
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  common/rc |    7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > 
> > diff --git a/common/rc b/common/rc
> > index 1ec84263c917c0..1b78cd0c358bb9 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -619,7 +619,7 @@ _scratch_shutdown_and_syncfs()
> >  # requirement down to _require_scratch_shutdown.
> >  _require_xfs_io_shutdown()
> >  {
> > -	if [ _scratch_shutdown_handle != $SCRATCH_MNT ]; then
> > +	if [ $(_scratch_shutdown_handle) != $SCRATCH_MNT ]; then
> Yeah, right. _scratch_shutdown_handle is a function call and should be placed in a $() or ``. 
> >  		# Most likely overlayfs
> >  		_notrun "xfs_io -c shutdown not supported on $FSTYP"
> >  	fi
> > @@ -3073,6 +3073,11 @@ _require_xfs_io_command()
> >  		rm -f $testfile.1
> >  		param_checked="$param"
> >  		;;
> > +	"shutdown")
> > +		testio=$($XFS_IO_PROG -f -x -c "$command $param" $testfile 2>&1)
> > +		param_checked="$param"
> > +		_test_cycle_mount
> > +		;;
> Looks good to me. Just curious, any reason why we are testing with TEST_DIR and not with
> SCRATCH_MNT? 

$TEST_DIR is always available and mounted, whereas SCRATCH_* are
optional.

> Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>

Thanks!

--D

> >  	"utimes" )
> >  		testio=`$XFS_IO_PROG -f -c "utimes 0 0 0 0" $testfile 2>&1`
> >  		;;
> > 
> 

Re: [PATCH 2/8] common/rc: fix _require_xfs_io_shutdown

[Nirjhar Roy (IBM)]

On 10/25/25 03:38, Darrick J. Wong wrote:
> On Fri, Oct 24, 2025 at 01:01:50PM +0530, Nirjhar Roy (IBM) wrote:
>> On Wed, 2025-10-15 at 09:37 -0700, Darrick J. Wong wrote:
>>> From: Darrick J. Wong <djwong@kernel.org>
>>>
>>> Capturing the output of _scratch_shutdown_handle requires one to enclose
>>> the callsite with $(), otherwise you're comparing the literal string
>>> "_scratch_shutdown_handle" to $SCRATCH_MNT, which always fails.
>>>
>>> Also fix _require_xfs_io_command to handle testing the shutdown command
>>> correctly.
>>>
>>> Cc: <fstests@vger.kernel.org> # v2025.06.22
>>> Fixes: 4b1cf3df009b22 ("fstests: add helper _require_xfs_io_shutdown")
>>> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
>>> ---
>>>   common/rc |    7 ++++++-
>>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>>
>>> diff --git a/common/rc b/common/rc
>>> index 1ec84263c917c0..1b78cd0c358bb9 100644
>>> --- a/common/rc
>>> +++ b/common/rc
>>> @@ -619,7 +619,7 @@ _scratch_shutdown_and_syncfs()
>>>   # requirement down to _require_scratch_shutdown.
>>>   _require_xfs_io_shutdown()
>>>   {
>>> -	if [ _scratch_shutdown_handle != $SCRATCH_MNT ]; then
>>> +	if [ $(_scratch_shutdown_handle) != $SCRATCH_MNT ]; then
>> Yeah, right. _scratch_shutdown_handle is a function call and should be placed in a $() or ``.
>>>   		# Most likely overlayfs
>>>   		_notrun "xfs_io -c shutdown not supported on $FSTYP"
>>>   	fi
>>> @@ -3073,6 +3073,11 @@ _require_xfs_io_command()
>>>   		rm -f $testfile.1
>>>   		param_checked="$param"
>>>   		;;
>>> +	"shutdown")
>>> +		testio=$($XFS_IO_PROG -f -x -c "$command $param" $testfile 2>&1)
>>> +		param_checked="$param"
>>> +		_test_cycle_mount
>>> +		;;
>> Looks good to me. Just curious, any reason why we are testing with TEST_DIR and not with
>> SCRATCH_MNT?
> $TEST_DIR is always available and mounted, whereas SCRATCH_* are
> optional.

Okay, thank you.

--NR

>
>> Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
> Thanks!
>
> --D
>
>>>   	"utimes" )
>>>   		testio=`$XFS_IO_PROG -f -c "utimes 0 0 0 0" $testfile 2>&1`
>>>   		;;
>>>
-- 
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore

[PATCH 3/8] generic/742: avoid infinite loop if no fiemap results

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

The fiemap-fault program employed this program looks for deadlocks
between FIEMAP and file page faults by calling the FIEMAP ioctl with a
buffer pointer that is mmaped file range.  Unfortunately, the FIEMAP
loop can enter an infinite loop if FIEMAP reports zero extents because
it never changes the last variable.

This shouldn't happen if the filesystem is working correctly, but it
turns out that there's a bug in libext2fs' punch-range code that causes
punch-alternating to unmap all the double-indirect blocks in the file.
This causes the while loop to run forever because last never increases,
which then means that testing fuse2fs with ext2/ext3 grinds to a halt
because fstests doesn't enforce a per-testcase time limit.

Avoid this situation by bailing out if the loop doesn't make forward
progress.

Cc: <fstests@vger.kernel.org> # v2024.03.31
Fixes: 34cdaf0831ee42 ("generic: add a regression test for fiemap into an mmap range")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 src/fiemap-fault.c |   14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)


diff --git a/src/fiemap-fault.c b/src/fiemap-fault.c
index 73260068054ede..2bb474c083986d 100644
--- a/src/fiemap-fault.c
+++ b/src/fiemap-fault.c
@@ -55,17 +55,29 @@ int main(int argc, char *argv[])
 				  sizeof(struct fiemap_extent);
 
 	while (last < sz) {
+		size_t old_start;
 		int i;
 
-		fiemap->fm_start = last;
+		fiemap->fm_start = old_start = last;
 		fiemap->fm_length = sz - last;
 
 		ret = ioctl(fd, FS_IOC_FIEMAP, (unsigned long)fiemap);
 		if (ret < 0)
 			err(1, "fiemap failed %d", errno);
+		if (fiemap->fm_mapped_extents == 0) {
+			fprintf(stderr, "%s: fiemap returned 0 extents!\n",
+				argv[0]);
+			return 1;
+		}
 		for (i = 0; i < fiemap->fm_mapped_extents; i++)
 		       last = fiemap->fm_extents[i].fe_logical +
 			       fiemap->fm_extents[i].fe_length;
+
+		if (last <= old_start) {
+			fprintf(stderr, "%s: fiemap made no progress!\n",
+				argv[0]);
+			return 1;
+		}
 	}
 
 	munmap(buf, sz);

Re: [PATCH 3/8] generic/742: avoid infinite loop if no fiemap results

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH 4/8] generic/{482,757}: skip test if there are no FUA writes

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Both of these tests fail if the filesystem doesn't issue a FUA write to
a device, but ... there's no requirement that filesystems actually use
FUA at all.  For example, a fuse filesystem that writes to the block
device's page cache and issues fsync() will not cause the block layer to
issue FUA writes for the dirty pages.  Change that to _notrun.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 tests/generic/482 |    2 +-
 tests/generic/757 |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/tests/generic/482 b/tests/generic/482
index 8c114ee03058c6..25e05d7cdb1c0d 100755
--- a/tests/generic/482
+++ b/tests/generic/482
@@ -82,7 +82,7 @@ _log_writes_remove
 prev=$(_log_writes_mark_to_entry_number mkfs)
 [ -z "$prev" ] && _fail "failed to locate entry mark 'mkfs'"
 cur=$(_log_writes_find_next_fua $prev)
-[ -z "$cur" ] && _fail "failed to locate next FUA write"
+[ -z "$cur" ] && _notrun "failed to locate next FUA write"
 
 while [ ! -z "$cur" ]; do
 	_log_writes_replay_log_range $cur $DMTHIN_VOL_DEV >> $seqres.full
diff --git a/tests/generic/757 b/tests/generic/757
index 6c13c6af41c57c..725f3a5cc6da3a 100755
--- a/tests/generic/757
+++ b/tests/generic/757
@@ -71,7 +71,7 @@ _log_writes_remove
 prev=$(_log_writes_mark_to_entry_number mkfs)
 [ -z "$prev" ] && _fail "failed to locate entry mark 'mkfs'"
 cur=$(_log_writes_find_next_fua $prev)
-[ -z "$cur" ] && _fail "failed to locate next FUA write"
+[ -z "$cur" ] && _notrun "failed to locate next FUA write"
 
 while _soak_loop_running $((100 * TIME_FACTOR)); do
 	_log_writes_replay_log_range $cur $DMTHIN_VOL_DEV >> $seqres.full

Re: [PATCH 4/8] generic/{482,757}: skip test if there are no FUA writes

[Christoph Hellwig]

On Wed, Oct 15, 2025 at 09:37:45AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Both of these tests fail if the filesystem doesn't issue a FUA write to
> a device, but ... there's no requirement that filesystems actually use
> FUA at all.  For example, a fuse filesystem that writes to the block
> device's page cache and issues fsync() will not cause the block layer to
> issue FUA writes for the dirty pages.  Change that to _notrun.

Hmm, zoned ZXFS never issues FUA and didn't fail.  Oh, these use dm thin
and thus are _notrun. 

> index 8c114ee03058c6..25e05d7cdb1c0d 100755
> --- a/tests/generic/482
> +++ b/tests/generic/482
> @@ -82,7 +82,7 @@ _log_writes_remove
>  prev=$(_log_writes_mark_to_entry_number mkfs)
>  [ -z "$prev" ] && _fail "failed to locate entry mark 'mkfs'"
>  cur=$(_log_writes_find_next_fua $prev)
> -[ -z "$cur" ] && _fail "failed to locate next FUA write"
> +[ -z "$cur" ] && _notrun "failed to locate next FUA write"

This isn't really the last but the first FUA write we're looking for
here, right?

>  
> -[ -z "$cur" ] && _fail "failed to locate next FUA write"
> +[ -z "$cur" ] && _notrun "failed to locate next FUA write"

Same here.

The only reason I'm asking is because if we did this for every write
we'd kinda defeat the purpose of the test.  But we're only doing it
to see if any FUA writes exists as far as I can tell, so we should
be ok.  But it might be worth changing the messages.

Re: [PATCH 4/8] generic/{482,757}: skip test if there are no FUA writes

[Darrick J. Wong]

On Thu, Oct 16, 2025 at 09:22:49PM -0700, Christoph Hellwig wrote:
> On Wed, Oct 15, 2025 at 09:37:45AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Both of these tests fail if the filesystem doesn't issue a FUA write to
> > a device, but ... there's no requirement that filesystems actually use
> > FUA at all.  For example, a fuse filesystem that writes to the block
> > device's page cache and issues fsync() will not cause the block layer to
> > issue FUA writes for the dirty pages.  Change that to _notrun.
> 
> Hmm, zoned ZXFS never issues FUA and didn't fail.  Oh, these use dm thin
> and thus are _notrun. 

Yep.

> > index 8c114ee03058c6..25e05d7cdb1c0d 100755
> > --- a/tests/generic/482
> > +++ b/tests/generic/482
> > @@ -82,7 +82,7 @@ _log_writes_remove
> >  prev=$(_log_writes_mark_to_entry_number mkfs)
> >  [ -z "$prev" ] && _fail "failed to locate entry mark 'mkfs'"
> >  cur=$(_log_writes_find_next_fua $prev)
> > -[ -z "$cur" ] && _fail "failed to locate next FUA write"
> > +[ -z "$cur" ] && _notrun "failed to locate next FUA write"
> 
> This isn't really the last but the first FUA write we're looking for
> here, right?

Yes, it's looking for the first FUA write after mkfs, which is
(presumably) the first directio O_SYNC write or (more likely) journal
commit.

> >  
> > -[ -z "$cur" ] && _fail "failed to locate next FUA write"
> > +[ -z "$cur" ] && _notrun "failed to locate next FUA write"
> 
> Same here.
> 
> The only reason I'm asking is because if we did this for every write
> we'd kinda defeat the purpose of the test.  But we're only doing it
> to see if any FUA writes exists as far as I can tell, so we should
> be ok.  But it might be worth changing the messages.

"could not locate any FUA write" ?

--D

Re: [PATCH 4/8] generic/{482,757}: skip test if there are no FUA writes

[Christoph Hellwig]

On Fri, Oct 17, 2025 at 09:24:26AM -0700, Darrick J. Wong wrote:
> > The only reason I'm asking is because if we did this for every write
> > we'd kinda defeat the purpose of the test.  But we're only doing it
> > to see if any FUA writes exists as far as I can tell, so we should
> > be ok.  But it might be worth changing the messages.
> 
> "could not locate any FUA write" ?

Sounds good.

[PATCH 5/8] generic/772: actually check for file_getattr special file support

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

On XFS in 6.17, this test fails with:

 --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
 +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
 @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
  Can not set fsxattr on ./foo: Invalid argument
  Initial attributes state
  ----------------- SCRATCH_MNT/prj
 ------------------ ./fifo
 ------------------ ./chardev
 ------------------ ./blockdev
 ------------------ ./socket
 ------------------ ./foo
 ------------------ ./symlink
 +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
 +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
 +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
 +Can not get fsxattr on ./socket: Inappropriate ioctl for device

This is a result of XFS' file_getattr implementation rejecting special
files prior to 6.18.  Therefore, skip this new test on old kernels.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 tests/generic/772 |    3 +++
 tests/xfs/648     |    3 +++
 2 files changed, 6 insertions(+)


diff --git a/tests/generic/772 b/tests/generic/772
index cc1a1bb5bf655c..e68a6724654450 100755
--- a/tests/generic/772
+++ b/tests/generic/772
@@ -43,6 +43,9 @@ touch $projectdir/bar
 ln -s $projectdir/bar $projectdir/broken-symlink
 rm -f $projectdir/bar
 
+file_attr --get $projectdir ./fifo &>/dev/null || \
+	_notrun "file_getattr not supported on $FSTYP"
+
 echo "Error codes"
 # wrong AT_ flags
 file_attr --get --invalid-at $projectdir ./foo
diff --git a/tests/xfs/648 b/tests/xfs/648
index 215c809887b609..e3c2fbe00b666a 100755
--- a/tests/xfs/648
+++ b/tests/xfs/648
@@ -47,6 +47,9 @@ touch $projectdir/bar
 ln -s $projectdir/bar $projectdir/broken-symlink
 rm -f $projectdir/bar
 
+$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
+	_notrun "file_getattr not supported on $FSTYP"
+
 $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
 	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
 $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Zorro Lang]

On Wed, Oct 15, 2025 at 09:38:01AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> On XFS in 6.17, this test fails with:
> 
>  --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
>  +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
>  @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
>   Can not set fsxattr on ./foo: Invalid argument
>   Initial attributes state
>   ----------------- SCRATCH_MNT/prj
>  ------------------ ./fifo
>  ------------------ ./chardev
>  ------------------ ./blockdev
>  ------------------ ./socket
>  ------------------ ./foo
>  ------------------ ./symlink
>  +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
>  +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
>  +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
>  +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> 
> This is a result of XFS' file_getattr implementation rejecting special
> files prior to 6.18.  Therefore, skip this new test on old kernels.
> 
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  tests/generic/772 |    3 +++
>  tests/xfs/648     |    3 +++
>  2 files changed, 6 insertions(+)
> 
> 
> diff --git a/tests/generic/772 b/tests/generic/772
> index cc1a1bb5bf655c..e68a6724654450 100755
> --- a/tests/generic/772
> +++ b/tests/generic/772
> @@ -43,6 +43,9 @@ touch $projectdir/bar
>  ln -s $projectdir/bar $projectdir/broken-symlink
>  rm -f $projectdir/bar
>  
> +file_attr --get $projectdir ./fifo &>/dev/null || \
> +	_notrun "file_getattr not supported on $FSTYP"

I'm wondering if a _require_file_attr() is better?

Thanks,
Zorro

> +
>  echo "Error codes"
>  # wrong AT_ flags
>  file_attr --get --invalid-at $projectdir ./foo
> diff --git a/tests/xfs/648 b/tests/xfs/648
> index 215c809887b609..e3c2fbe00b666a 100755
> --- a/tests/xfs/648
> +++ b/tests/xfs/648
> @@ -47,6 +47,9 @@ touch $projectdir/bar
>  ln -s $projectdir/bar $projectdir/broken-symlink
>  rm -f $projectdir/bar
>  
> +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> +	_notrun "file_getattr not supported on $FSTYP"
> +
>  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
>  	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
>  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> 

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Darrick J. Wong]

On Sat, Oct 18, 2025 at 01:46:33AM +0800, Zorro Lang wrote:
> On Wed, Oct 15, 2025 at 09:38:01AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > On XFS in 6.17, this test fails with:
> > 
> >  --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
> >  +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
> >  @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
> >   Can not set fsxattr on ./foo: Invalid argument
> >   Initial attributes state
> >   ----------------- SCRATCH_MNT/prj
> >  ------------------ ./fifo
> >  ------------------ ./chardev
> >  ------------------ ./blockdev
> >  ------------------ ./socket
> >  ------------------ ./foo
> >  ------------------ ./symlink
> >  +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
> >  +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
> >  +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
> >  +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> > 
> > This is a result of XFS' file_getattr implementation rejecting special
> > files prior to 6.18.  Therefore, skip this new test on old kernels.
> > 
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  tests/generic/772 |    3 +++
> >  tests/xfs/648     |    3 +++
> >  2 files changed, 6 insertions(+)
> > 
> > 
> > diff --git a/tests/generic/772 b/tests/generic/772
> > index cc1a1bb5bf655c..e68a6724654450 100755
> > --- a/tests/generic/772
> > +++ b/tests/generic/772
> > @@ -43,6 +43,9 @@ touch $projectdir/bar
> >  ln -s $projectdir/bar $projectdir/broken-symlink
> >  rm -f $projectdir/bar
> >  
> > +file_attr --get $projectdir ./fifo &>/dev/null || \
> > +	_notrun "file_getattr not supported on $FSTYP"
> 
> I'm wondering if a _require_file_attr() is better?

It's checking specifically that the new getattr syscall works on special
files.  I suppose you could wrap that in a helper, but I think this is a
lot more direct about what it's looking for.

--D

> Thanks,
> Zorro
> 
> > +
> >  echo "Error codes"
> >  # wrong AT_ flags
> >  file_attr --get --invalid-at $projectdir ./foo
> > diff --git a/tests/xfs/648 b/tests/xfs/648
> > index 215c809887b609..e3c2fbe00b666a 100755
> > --- a/tests/xfs/648
> > +++ b/tests/xfs/648
> > @@ -47,6 +47,9 @@ touch $projectdir/bar
> >  ln -s $projectdir/bar $projectdir/broken-symlink
> >  rm -f $projectdir/bar
> >  
> > +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> > +	_notrun "file_getattr not supported on $FSTYP"
> > +
> >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> >  	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
> >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > 
> 
> 

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Zorro Lang]

On Fri, Oct 17, 2025 at 03:54:48PM -0700, Darrick J. Wong wrote:
> On Sat, Oct 18, 2025 at 01:46:33AM +0800, Zorro Lang wrote:
> > On Wed, Oct 15, 2025 at 09:38:01AM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > 
> > > On XFS in 6.17, this test fails with:
> > > 
> > >  --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
> > >  +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
> > >  @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
> > >   Can not set fsxattr on ./foo: Invalid argument
> > >   Initial attributes state
> > >   ----------------- SCRATCH_MNT/prj
> > >  ------------------ ./fifo
> > >  ------------------ ./chardev
> > >  ------------------ ./blockdev
> > >  ------------------ ./socket
> > >  ------------------ ./foo
> > >  ------------------ ./symlink
> > >  +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
> > >  +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
> > >  +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
> > >  +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> > > 
> > > This is a result of XFS' file_getattr implementation rejecting special
> > > files prior to 6.18.  Therefore, skip this new test on old kernels.
> > > 
> > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > ---
> > >  tests/generic/772 |    3 +++
> > >  tests/xfs/648     |    3 +++
> > >  2 files changed, 6 insertions(+)
> > > 
> > > 
> > > diff --git a/tests/generic/772 b/tests/generic/772
> > > index cc1a1bb5bf655c..e68a6724654450 100755
> > > --- a/tests/generic/772
> > > +++ b/tests/generic/772
> > > @@ -43,6 +43,9 @@ touch $projectdir/bar
> > >  ln -s $projectdir/bar $projectdir/broken-symlink
> > >  rm -f $projectdir/bar
> > >  
> > > +file_attr --get $projectdir ./fifo &>/dev/null || \
> > > +	_notrun "file_getattr not supported on $FSTYP"
> > 
> > I'm wondering if a _require_file_attr() is better?
> 
> It's checking specifically that the new getattr syscall works on special
> files.  I suppose you could wrap that in a helper, but I think this is a
> lot more direct about what it's looking for.

Please correct me if I'm wrong. The new syscall is created for setting extended
attributes on special files, therefore I suppose if there's file_setattr syscall
and it can work on regular file, then it can work on any other files the fs supports.
If this's correct, _require_file_attr can use file_attr to try to set and get
attr on a regular file in $TEST_DIR, to make sure the whole file_set/getattr
feature is supported. Is that right?

Thanks,
Zorro

> 
> --D
> 
> > Thanks,
> > Zorro
> > 
> > > +
> > >  echo "Error codes"
> > >  # wrong AT_ flags
> > >  file_attr --get --invalid-at $projectdir ./foo
> > > diff --git a/tests/xfs/648 b/tests/xfs/648
> > > index 215c809887b609..e3c2fbe00b666a 100755
> > > --- a/tests/xfs/648
> > > +++ b/tests/xfs/648
> > > @@ -47,6 +47,9 @@ touch $projectdir/bar
> > >  ln -s $projectdir/bar $projectdir/broken-symlink
> > >  rm -f $projectdir/bar
> > >  
> > > +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> > > +	_notrun "file_getattr not supported on $FSTYP"
> > > +
> > >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > >  	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
> > >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > > 
> > 
> > 
> 

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Darrick J. Wong]

On Sat, Oct 18, 2025 at 03:57:08PM +0800, Zorro Lang wrote:
> On Fri, Oct 17, 2025 at 03:54:48PM -0700, Darrick J. Wong wrote:
> > On Sat, Oct 18, 2025 at 01:46:33AM +0800, Zorro Lang wrote:
> > > On Wed, Oct 15, 2025 at 09:38:01AM -0700, Darrick J. Wong wrote:
> > > > From: Darrick J. Wong <djwong@kernel.org>
> > > > 
> > > > On XFS in 6.17, this test fails with:
> > > > 
> > > >  --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
> > > >  +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
> > > >  @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
> > > >   Can not set fsxattr on ./foo: Invalid argument
> > > >   Initial attributes state
> > > >   ----------------- SCRATCH_MNT/prj
> > > >  ------------------ ./fifo
> > > >  ------------------ ./chardev
> > > >  ------------------ ./blockdev
> > > >  ------------------ ./socket
> > > >  ------------------ ./foo
> > > >  ------------------ ./symlink
> > > >  +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
> > > >  +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
> > > >  +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
> > > >  +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> > > > 
> > > > This is a result of XFS' file_getattr implementation rejecting special
> > > > files prior to 6.18.  Therefore, skip this new test on old kernels.
> > > > 
> > > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > > ---
> > > >  tests/generic/772 |    3 +++
> > > >  tests/xfs/648     |    3 +++
> > > >  2 files changed, 6 insertions(+)
> > > > 
> > > > 
> > > > diff --git a/tests/generic/772 b/tests/generic/772
> > > > index cc1a1bb5bf655c..e68a6724654450 100755
> > > > --- a/tests/generic/772
> > > > +++ b/tests/generic/772
> > > > @@ -43,6 +43,9 @@ touch $projectdir/bar
> > > >  ln -s $projectdir/bar $projectdir/broken-symlink
> > > >  rm -f $projectdir/bar
> > > >  
> > > > +file_attr --get $projectdir ./fifo &>/dev/null || \
> > > > +	_notrun "file_getattr not supported on $FSTYP"
> > > 
> > > I'm wondering if a _require_file_attr() is better?
> > 
> > It's checking specifically that the new getattr syscall works on special
> > files.  I suppose you could wrap that in a helper, but I think this is a
> > lot more direct about what it's looking for.
> 
> Please correct me if I'm wrong. The new syscall is created for setting extended
> attributes on special files, therefore I suppose if there's file_setattr syscall
> and it can work on regular file, then it can work on any other files the fs supports.
> If this's correct, _require_file_attr can use file_attr to try to set and get
> attr on a regular file in $TEST_DIR, to make sure the whole file_set/getattr
> feature is supported. Is that right?

No.  The new new syscall allows programs to specify a {dir fd, path}
input that points to a special file, but it uses the existing per-fs
get/setattr implementations.  All of those implementations have to
remove their copy-pasta'd code:

	if (d_is_special(dentry))
		return -ENOTTY;

before the new syscall will return non-error for special files.  This
wasn't done for all of the filesystems before 6.18, which means that
6.17 has the syscall but none of the filesystems support accessing
special files.  As of 6.18-rc2, gfs, jfs, and ubifs still have that
code.

TLDR: You can't assume that the new syscall works with special files.

--D

> Thanks,
> Zorro
> 
> > 
> > --D
> > 
> > > Thanks,
> > > Zorro
> > > 
> > > > +
> > > >  echo "Error codes"
> > > >  # wrong AT_ flags
> > > >  file_attr --get --invalid-at $projectdir ./foo
> > > > diff --git a/tests/xfs/648 b/tests/xfs/648
> > > > index 215c809887b609..e3c2fbe00b666a 100755
> > > > --- a/tests/xfs/648
> > > > +++ b/tests/xfs/648
> > > > @@ -47,6 +47,9 @@ touch $projectdir/bar
> > > >  ln -s $projectdir/bar $projectdir/broken-symlink
> > > >  rm -f $projectdir/bar
> > > >  
> > > > +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> > > > +	_notrun "file_getattr not supported on $FSTYP"
> > > > +
> > > >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > > >  	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
> > > >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > > > 
> > > 
> > > 
> > 
> 
> 

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Nirjhar Roy (IBM)]

On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> On XFS in 6.17, this test fails with:
> 
>  --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
>  +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
>  @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
>   Can not set fsxattr on ./foo: Invalid argument
>   Initial attributes state
>   ----------------- SCRATCH_MNT/prj
>  ------------------ ./fifo
>  ------------------ ./chardev
>  ------------------ ./blockdev
>  ------------------ ./socket
>  ------------------ ./foo
>  ------------------ ./symlink
>  +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
>  +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
>  +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
>  +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> 
> This is a result of XFS' file_getattr implementation rejecting special
> files prior to 6.18.  Therefore, skip this new test on old kernels.
> 
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  tests/generic/772 |    3 +++
>  tests/xfs/648     |    3 +++
>  2 files changed, 6 insertions(+)
> 
> 
> diff --git a/tests/generic/772 b/tests/generic/772
> index cc1a1bb5bf655c..e68a6724654450 100755
> --- a/tests/generic/772
> +++ b/tests/generic/772
> @@ -43,6 +43,9 @@ touch $projectdir/bar
>  ln -s $projectdir/bar $projectdir/broken-symlink
>  rm -f $projectdir/bar
>  
> +file_attr --get $projectdir ./fifo &>/dev/null || \
> +	_notrun "file_getattr not supported on $FSTYP"
> +
Shouldn't we use $here/src/file_attr like we have done later (maybe just for consistency)?
Also, I am wondering if we can have something like
_require_get_attr_for_special_files() helper kind of a thing?
--NR
>  echo "Error codes"
>  # wrong AT_ flags
>  file_attr --get --invalid-at $projectdir ./foo
> diff --git a/tests/xfs/648 b/tests/xfs/648
> index 215c809887b609..e3c2fbe00b666a 100755
> --- a/tests/xfs/648
> +++ b/tests/xfs/648
> @@ -47,6 +47,9 @@ touch $projectdir/bar
>  ln -s $projectdir/bar $projectdir/broken-symlink
>  rm -f $projectdir/bar
>  
> +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> +	_notrun "file_getattr not supported on $FSTYP"
> +
>  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
>  	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
>  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> 

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Darrick J. Wong]

On Fri, Oct 24, 2025 at 01:14:29PM +0530, Nirjhar Roy (IBM) wrote:
> On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > On XFS in 6.17, this test fails with:
> > 
> >  --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
> >  +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
> >  @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
> >   Can not set fsxattr on ./foo: Invalid argument
> >   Initial attributes state
> >   ----------------- SCRATCH_MNT/prj
> >  ------------------ ./fifo
> >  ------------------ ./chardev
> >  ------------------ ./blockdev
> >  ------------------ ./socket
> >  ------------------ ./foo
> >  ------------------ ./symlink
> >  +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
> >  +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
> >  +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
> >  +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> > 
> > This is a result of XFS' file_getattr implementation rejecting special
> > files prior to 6.18.  Therefore, skip this new test on old kernels.
> > 
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  tests/generic/772 |    3 +++
> >  tests/xfs/648     |    3 +++
> >  2 files changed, 6 insertions(+)
> > 
> > 
> > diff --git a/tests/generic/772 b/tests/generic/772
> > index cc1a1bb5bf655c..e68a6724654450 100755
> > --- a/tests/generic/772
> > +++ b/tests/generic/772
> > @@ -43,6 +43,9 @@ touch $projectdir/bar
> >  ln -s $projectdir/bar $projectdir/broken-symlink
> >  rm -f $projectdir/bar
> >  
> > +file_attr --get $projectdir ./fifo &>/dev/null || \
> > +	_notrun "file_getattr not supported on $FSTYP"
> > +
> Shouldn't we use $here/src/file_attr like we have done later (maybe just for consistency)?

Probably, but this test has (for now) a wrapper so I used that.

> Also, I am wondering if we can have something like
> _require_get_attr_for_special_files() helper kind of a thing?

Andrey's working on that.

--D

> --NR
> >  echo "Error codes"
> >  # wrong AT_ flags
> >  file_attr --get --invalid-at $projectdir ./foo
> > diff --git a/tests/xfs/648 b/tests/xfs/648
> > index 215c809887b609..e3c2fbe00b666a 100755
> > --- a/tests/xfs/648
> > +++ b/tests/xfs/648
> > @@ -47,6 +47,9 @@ touch $projectdir/bar
> >  ln -s $projectdir/bar $projectdir/broken-symlink
> >  rm -f $projectdir/bar
> >  
> > +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> > +	_notrun "file_getattr not supported on $FSTYP"
> > +
> >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> >  	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
> >  $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > 
> 
> 

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Nirjhar Roy (IBM)]

On 10/25/25 03:40, Darrick J. Wong wrote:
> On Fri, Oct 24, 2025 at 01:14:29PM +0530, Nirjhar Roy (IBM) wrote:
>> On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
>>> From: Darrick J. Wong <djwong@kernel.org>
>>>
>>> On XFS in 6.17, this test fails with:
>>>
>>>   --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
>>>   +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
>>>   @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
>>>    Can not set fsxattr on ./foo: Invalid argument
>>>    Initial attributes state
>>>    ----------------- SCRATCH_MNT/prj
>>>   ------------------ ./fifo
>>>   ------------------ ./chardev
>>>   ------------------ ./blockdev
>>>   ------------------ ./socket
>>>   ------------------ ./foo
>>>   ------------------ ./symlink
>>>   +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
>>>   +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
>>>   +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
>>>   +Can not get fsxattr on ./socket: Inappropriate ioctl for device
>>>
>>> This is a result of XFS' file_getattr implementation rejecting special
>>> files prior to 6.18.  Therefore, skip this new test on old kernels.
>>>
>>> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
>>> ---
>>>   tests/generic/772 |    3 +++
>>>   tests/xfs/648     |    3 +++
>>>   2 files changed, 6 insertions(+)
>>>
>>>
>>> diff --git a/tests/generic/772 b/tests/generic/772
>>> index cc1a1bb5bf655c..e68a6724654450 100755
>>> --- a/tests/generic/772
>>> +++ b/tests/generic/772
>>> @@ -43,6 +43,9 @@ touch $projectdir/bar
>>>   ln -s $projectdir/bar $projectdir/broken-symlink
>>>   rm -f $projectdir/bar
>>>   
>>> +file_attr --get $projectdir ./fifo &>/dev/null || \
>>> +	_notrun "file_getattr not supported on $FSTYP"
>>> +
>> Shouldn't we use $here/src/file_attr like we have done later (maybe just for consistency)?
> Probably, but this test has (for now) a wrapper so I used that.

Sorry, which wrapper are you referring to?

>
>> Also, I am wondering if we can have something like
>> _require_get_attr_for_special_files() helper kind of a thing?
> Andrey's working on that.

Okay, thanks.

--NR

>
> --D
>
>> --NR
>>>   echo "Error codes"
>>>   # wrong AT_ flags
>>>   file_attr --get --invalid-at $projectdir ./foo
>>> diff --git a/tests/xfs/648 b/tests/xfs/648
>>> index 215c809887b609..e3c2fbe00b666a 100755
>>> --- a/tests/xfs/648
>>> +++ b/tests/xfs/648
>>> @@ -47,6 +47,9 @@ touch $projectdir/bar
>>>   ln -s $projectdir/bar $projectdir/broken-symlink
>>>   rm -f $projectdir/bar
>>>   
>>> +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
>>> +	_notrun "file_getattr not supported on $FSTYP"
>>> +
>>>   $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
>>>   	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
>>>   $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
>>>
>>
-- 
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore

Re: [PATCH 5/8] generic/772: actually check for file_getattr special file support

[Darrick J. Wong]

On Thu, Oct 30, 2025 at 11:35:33AM +0530, Nirjhar Roy (IBM) wrote:
> 
> On 10/25/25 03:40, Darrick J. Wong wrote:
> > On Fri, Oct 24, 2025 at 01:14:29PM +0530, Nirjhar Roy (IBM) wrote:
> > > On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> > > > From: Darrick J. Wong <djwong@kernel.org>
> > > > 
> > > > On XFS in 6.17, this test fails with:
> > > > 
> > > >   --- /run/fstests/bin/tests/generic/772.out	2025-10-06 08:27:10.834318149 -0700
> > > >   +++ /var/tmp/fstests/generic/772.out.bad	2025-10-08 18:00:34.713388178 -0700
> > > >   @@ -9,29 +9,34 @@ Can not get fsxattr on ./foo: Invalid ar
> > > >    Can not set fsxattr on ./foo: Invalid argument
> > > >    Initial attributes state
> > > >    ----------------- SCRATCH_MNT/prj
> > > >   ------------------ ./fifo
> > > >   ------------------ ./chardev
> > > >   ------------------ ./blockdev
> > > >   ------------------ ./socket
> > > >   ------------------ ./foo
> > > >   ------------------ ./symlink
> > > >   +Can not get fsxattr on ./fifo: Inappropriate ioctl for device
> > > >   +Can not get fsxattr on ./chardev: Inappropriate ioctl for device
> > > >   +Can not get fsxattr on ./blockdev: Inappropriate ioctl for device
> > > >   +Can not get fsxattr on ./socket: Inappropriate ioctl for device
> > > > 
> > > > This is a result of XFS' file_getattr implementation rejecting special
> > > > files prior to 6.18.  Therefore, skip this new test on old kernels.
> > > > 
> > > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > > ---
> > > >   tests/generic/772 |    3 +++
> > > >   tests/xfs/648     |    3 +++
> > > >   2 files changed, 6 insertions(+)
> > > > 
> > > > 
> > > > diff --git a/tests/generic/772 b/tests/generic/772
> > > > index cc1a1bb5bf655c..e68a6724654450 100755
> > > > --- a/tests/generic/772
> > > > +++ b/tests/generic/772
> > > > @@ -43,6 +43,9 @@ touch $projectdir/bar
> > > >   ln -s $projectdir/bar $projectdir/broken-symlink
> > > >   rm -f $projectdir/bar
> > > > +file_attr --get $projectdir ./fifo &>/dev/null || \
> > > > +	_notrun "file_getattr not supported on $FSTYP"
> > > > +
> > > Shouldn't we use $here/src/file_attr like we have done later (maybe just for consistency)?
> > Probably, but this test has (for now) a wrapper so I used that.
> 
> Sorry, which wrapper are you referring to?

Look about 10 lines up, there's a file_attr() function that calls
$here/src/file_attr "$@"

--D

> > 
> > > Also, I am wondering if we can have something like
> > > _require_get_attr_for_special_files() helper kind of a thing?
> > Andrey's working on that.
> 
> Okay, thanks.
> 
> --NR
> 
> > 
> > --D
> > 
> > > --NR
> > > >   echo "Error codes"
> > > >   # wrong AT_ flags
> > > >   file_attr --get --invalid-at $projectdir ./foo
> > > > diff --git a/tests/xfs/648 b/tests/xfs/648
> > > > index 215c809887b609..e3c2fbe00b666a 100755
> > > > --- a/tests/xfs/648
> > > > +++ b/tests/xfs/648
> > > > @@ -47,6 +47,9 @@ touch $projectdir/bar
> > > >   ln -s $projectdir/bar $projectdir/broken-symlink
> > > >   rm -f $projectdir/bar
> > > > +$here/src/file_attr --get $projectdir ./fifo &>/dev/null || \
> > > > +	_notrun "file_getattr not supported on $FSTYP"
> > > > +
> > > >   $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > > >   	-c "project -sp $projectdir $id" $SCRATCH_DEV | filter_quota
> > > >   $XFS_QUOTA_PROG -D $tmp.projects -P $tmp.projid -x \
> > > > 
> > > 
> -- 
> Nirjhar Roy
> Linux Kernel Developer
> IBM, Bangalore
> 
> 

[PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

Currently, _filter_file_attributes can only filter ext4 lsattr flags.
Update it to handle XFS lsattr flags as well.

Cc: <fstests@vger.kernel.org> # v2025.10.05
Fixes: 4eb40174d77c1b ("generic: introduce test to test file_getattr/file_setattr syscalls")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 common/filter |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


diff --git a/common/filter b/common/filter
index b330b27827d005..c3a751dd0c398c 100644
--- a/common/filter
+++ b/common/filter
@@ -688,10 +688,11 @@ _filter_sysfs_error()
 # 	... | _filter_file_attributes X
 # Or to filter all except X
 # 	... | _filter_file_attributes ~X
+# Be careful, we're filtering lsattr or xfs_io -c lsattr flags.
 _filter_file_attributes()
 {
 	if [[ $1 == ~* ]]; then
-		regex=$(echo "[aAcCdDeEFijmNPsStTuxVX]" | tr -d "$1")
+		regex=$(echo "[aAcCdDeEfFijmNpPsrStTuxVX]" | tr -d "$1")
 	else
 		regex="$1"
 	fi

Re: [PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags

[Christoph Hellwig]

On Wed, Oct 15, 2025 at 09:38:16AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Currently, _filter_file_attributes can only filter ext4 lsattr flags.
> Update it to handle XFS lsattr flags as well.

What XFS flags end up in lsattr?  Is this coordinated with the official
registry in ext4?

Re: [PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags

[Darrick J. Wong]

On Thu, Oct 16, 2025 at 09:23:44PM -0700, Christoph Hellwig wrote:
> On Wed, Oct 15, 2025 at 09:38:16AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Currently, _filter_file_attributes can only filter ext4 lsattr flags.
> > Update it to handle XFS lsattr flags as well.
> 
> What XFS flags end up in lsattr?

Assuming you're asking which XFS flags are reported by ext4 lsattr...

append, noatime, nodump, immutable, projinherit, fsdax

Unless you meant src/file_attr.c?  In which case theyr'e

> Is this coordinated with the official
> registry in ext4?

Only informally by Ted and I talking on Thursdays.

The problem here is that _filter_file_attributes ... probably ought to
say which domain (ext4 lsattr or xfs_io lsattr) it's actually filtering.

Right now the only users of this helper are using it to filter
src/file_attr.c output (aka xfs_io lsattr) so I think I should change
the patch to document that.

--D

Re: [PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags

[Christoph Hellwig]

On Fri, Oct 17, 2025 at 09:22:18AM -0700, Darrick J. Wong wrote:
> > What XFS flags end up in lsattr?
> 
> Assuming you're asking which XFS flags are reported by ext4 lsattr...
> 
> append, noatime, nodump, immutable, projinherit, fsdax
> 
> Unless you meant src/file_attr.c?  In which case theyr'e

I'm actually not sure.  I was just surprised about the flags showing
up.

> 
> > Is this coordinated with the official
> > registry in ext4?
> 
> Only informally by Ted and I talking on Thursdays.
> 
> The problem here is that _filter_file_attributes ... probably ought to
> say which domain (ext4 lsattr or xfs_io lsattr) it's actually filtering.

Oooh.  That explains my confusion.

> Right now the only users of this helper are using it to filter
> src/file_attr.c output (aka xfs_io lsattr) so I think I should change
> the patch to document that.

Yes, please.  And we really need to figure out central authoritisied
to document the lsattr and fsxattr domain flags.

Re: [PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags

[Darrick J. Wong]

On Mon, Oct 20, 2025 at 12:01:21AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 17, 2025 at 09:22:18AM -0700, Darrick J. Wong wrote:
> > > What XFS flags end up in lsattr?
> > 
> > Assuming you're asking which XFS flags are reported by ext4 lsattr...
> > 
> > append, noatime, nodump, immutable, projinherit, fsdax
> > 
> > Unless you meant src/file_attr.c?  In which case theyr'e
> 
> I'm actually not sure.  I was just surprised about the flags showing
> up.
> 
> > 
> > > Is this coordinated with the official
> > > registry in ext4?
> > 
> > Only informally by Ted and I talking on Thursdays.
> > 
> > The problem here is that _filter_file_attributes ... probably ought to
> > say which domain (ext4 lsattr or xfs_io lsattr) it's actually filtering.
> 
> Oooh.  That explains my confusion.
> 
> > Right now the only users of this helper are using it to filter
> > src/file_attr.c output (aka xfs_io lsattr) so I think I should change
> > the patch to document that.
> 
> Yes, please.  And we really need to figure out central authoritisied
> to document the lsattr and fsxattr domain flags.

[add tytso and linux-ext4]

I think we should standardize on the VFS (aka file_getattr) flag values,
which means the xfs version more or less wins.

The only problem there of course is that file_getattr doesn't know about
the ext-specific flags, which are:

	{ EXT2_SECRM_FL, "s", "Secure_Deletion" },
	{ EXT2_UNRM_FL, "u" , "Undelete" },
	{ EXT2_DIRSYNC_FL, "D", "Synchronous_Directory_Updates" },
	{ EXT2_COMPR_FL, "c", "Compression_Requested" },
	{ EXT4_ENCRYPT_FL, "E", "Encrypted" },
	{ EXT3_JOURNAL_DATA_FL, "j", "Journaled_Data" },
	{ EXT2_INDEX_FL, "I", "Indexed_directory" },
	{ EXT2_NOTAIL_FL, "t", "No_Tailmerging" },
	{ EXT2_TOPDIR_FL, "T", "Top_of_Directory_Hierarchies" },
	{ EXT4_EXTENTS_FL, "e", "Extents" },
	{ FS_NOCOW_FL, "C", "No_COW" },
	{ EXT4_CASEFOLD_FL, "F", "Casefold" },
	{ EXT4_INLINE_DATA_FL, "N", "Inline_Data" },
	{ EXT4_VERITY_FL, "V", "Verity" },
	{ EXT2_NOCOMPR_FL, "m", "Dont_Compress" },

Not sure what we want to do about that, since some of those flags like
the ones related to deletion, compression, and tailmerging aren't
implemented.

Other things like extents/topdir seem too ext4-specific to put in a vfs
interface....?

--D

Re: [PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags

[Christoph Hellwig]

On Mon, Oct 20, 2025 at 09:37:13AM -0700, Darrick J. Wong wrote:
> [add tytso and linux-ext4]
> 
> I think we should standardize on the VFS (aka file_getattr) flag values,
> which means the xfs version more or less wins.

Ok, I'm more than confused than before.  Shouldn't we simply use
separate filters for FS_IOC_GETFLAGS vs FS_IOC_FSGETXATTR?

Re: [PATCH 6/8] common/filter: fix _filter_file_attributes to handle xfs file flags

[Darrick J. Wong]

On Mon, Oct 20, 2025 at 10:30:29PM -0700, Christoph Hellwig wrote:
> On Mon, Oct 20, 2025 at 09:37:13AM -0700, Darrick J. Wong wrote:
> > [add tytso and linux-ext4]
> > 
> > I think we should standardize on the VFS (aka file_getattr) flag values,
> > which means the xfs version more or less wins.
> 
> Ok, I'm more than confused than before.  Shouldn't we simply use
> separate filters for FS_IOC_GETFLAGS vs FS_IOC_FSGETXATTR?

Yeah.  I was going to just provide both versions, but then I went down
the rabbithole of navelgazing about "Is upstream going to accept a
helper for the ext4 lsattr flags even though there are no users?" and
then wandered off to tackle actual useful things like mount/unmount
races in fuse. :P

--D

[PATCH 7/8] common/attr: fix _require_noattr2

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

attr2/noattr2 doesn't do anything anymore and aren't reported in
/proc/mounts, so we need to check /proc/mounts and _notrun as a result.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 common/attr |    4 ++++
 1 file changed, 4 insertions(+)


diff --git a/common/attr b/common/attr
index 1c1de63e9d5465..35e0bee4e3aa53 100644
--- a/common/attr
+++ b/common/attr
@@ -241,7 +241,11 @@ _require_noattr2()
 		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
 	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
 		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
+	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
+	local res=${PIPESTATUS[2]}
 	_scratch_unmount
+	test $res -eq 0 \
+		|| _notrun "noattr2 mount option no longer functional"
 }
 
 # getfattr -R returns info in readdir order which varies from fs to fs.

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Christoph Hellwig]

On Wed, Oct 15, 2025 at 09:38:32AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> attr2/noattr2 doesn't do anything anymore and aren't reported in
> /proc/mounts, so we need to check /proc/mounts and _notrun as a result.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Zorro Lang]

On Wed, Oct 15, 2025 at 09:38:32AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> attr2/noattr2 doesn't do anything anymore and aren't reported in
> /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
> 
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  common/attr |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> 
> diff --git a/common/attr b/common/attr
> index 1c1de63e9d5465..35e0bee4e3aa53 100644
> --- a/common/attr
> +++ b/common/attr
> @@ -241,7 +241,11 @@ _require_noattr2()
>  		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
>  	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
>  		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
> +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2

How about use findmnt? e.g.

    grep -qw noattr2 <(findmnt -rncv -M / -o OPTIONS)

> +	local res=${PIPESTATUS[2]}

Then the PIPESTATUS isn't needed either.

I can help to do this change if you agree.

Thanks,
Zorro

>  	_scratch_unmount
> +	test $res -eq 0 \
> +		|| _notrun "noattr2 mount option no longer functional"
>  }
>  
>  # getfattr -R returns info in readdir order which varies from fs to fs.
> 

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Darrick J. Wong]

On Sat, Oct 18, 2025 at 01:13:25AM +0800, Zorro Lang wrote:
> On Wed, Oct 15, 2025 at 09:38:32AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > attr2/noattr2 doesn't do anything anymore and aren't reported in
> > /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
> > 
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  common/attr |    4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > 
> > diff --git a/common/attr b/common/attr
> > index 1c1de63e9d5465..35e0bee4e3aa53 100644
> > --- a/common/attr
> > +++ b/common/attr
> > @@ -241,7 +241,11 @@ _require_noattr2()
> >  		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
> >  	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
> >  		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
> > +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
> 
> How about use findmnt? e.g.
> 
>     grep -qw noattr2 <(findmnt -rncv -M / -o OPTIONS)
> 
> > +	local res=${PIPESTATUS[2]}
> 
> Then the PIPESTATUS isn't needed either.
> 
> I can help to do this change if you agree.

Yes, that works!  Excellent suggestion.

--D

> Thanks,
> Zorro
> 
> >  	_scratch_unmount
> > +	test $res -eq 0 \
> > +		|| _notrun "noattr2 mount option no longer functional"
> >  }
> >  
> >  # getfattr -R returns info in readdir order which varies from fs to fs.
> > 
> 
> 

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Zorro Lang]

On Fri, Oct 17, 2025 at 03:55:46PM -0700, Darrick J. Wong wrote:
> On Sat, Oct 18, 2025 at 01:13:25AM +0800, Zorro Lang wrote:
> > On Wed, Oct 15, 2025 at 09:38:32AM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <djwong@kernel.org>
> > > 
> > > attr2/noattr2 doesn't do anything anymore and aren't reported in
> > > /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
> > > 
> > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > ---
> > >  common/attr |    4 ++++
> > >  1 file changed, 4 insertions(+)
> > > 
> > > 
> > > diff --git a/common/attr b/common/attr
> > > index 1c1de63e9d5465..35e0bee4e3aa53 100644
> > > --- a/common/attr
> > > +++ b/common/attr
> > > @@ -241,7 +241,11 @@ _require_noattr2()
> > >  		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
> > >  	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
> > >  		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
> > > +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
> > 
> > How about use findmnt? e.g.
> > 
> >     grep -qw noattr2 <(findmnt -rncv -M / -o OPTIONS)

Sorry, the "/" should be $SCRATCH_MNT.

> > 
> > > +	local res=${PIPESTATUS[2]}
> > 
> > Then the PIPESTATUS isn't needed either.
> > 
> > I can help to do this change if you agree.
> 
> Yes, that works!  Excellent suggestion.

The patch 1,2,3,5,7,8 has been acked/reviewed, do you need I merge these patches
in the release of this weekend at first, as this's a random fixes patchset. Or
I can wait your next version, then merge the whole patchset when it's all get
reviewed ?

Thanks,
Zorro

> 
> --D
> 
> > Thanks,
> > Zorro
> > 
> > >  	_scratch_unmount
> > > +	test $res -eq 0 \
> > > +		|| _notrun "noattr2 mount option no longer functional"
> > >  }
> > >  
> > >  # getfattr -R returns info in readdir order which varies from fs to fs.
> > > 
> > 
> > 
> 

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Darrick J. Wong]

On Sat, Oct 18, 2025 at 10:43:18PM +0800, Zorro Lang wrote:
> On Fri, Oct 17, 2025 at 03:55:46PM -0700, Darrick J. Wong wrote:
> > On Sat, Oct 18, 2025 at 01:13:25AM +0800, Zorro Lang wrote:
> > > On Wed, Oct 15, 2025 at 09:38:32AM -0700, Darrick J. Wong wrote:
> > > > From: Darrick J. Wong <djwong@kernel.org>
> > > > 
> > > > attr2/noattr2 doesn't do anything anymore and aren't reported in
> > > > /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
> > > > 
> > > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > > ---
> > > >  common/attr |    4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > 
> > > > diff --git a/common/attr b/common/attr
> > > > index 1c1de63e9d5465..35e0bee4e3aa53 100644
> > > > --- a/common/attr
> > > > +++ b/common/attr
> > > > @@ -241,7 +241,11 @@ _require_noattr2()
> > > >  		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
> > > >  	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
> > > >  		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
> > > > +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
> > > 
> > > How about use findmnt? e.g.
> > > 
> > >     grep -qw noattr2 <(findmnt -rncv -M / -o OPTIONS)
> 
> Sorry, the "/" should be $SCRATCH_MNT.
> 
> > > 
> > > > +	local res=${PIPESTATUS[2]}
> > > 
> > > Then the PIPESTATUS isn't needed either.
> > > 
> > > I can help to do this change if you agree.
> > 
> > Yes, that works!  Excellent suggestion.
> 
> The patch 1,2,3,5,7,8 has been acked/reviewed, do you need I merge these patches
> in the release of this weekend at first, as this's a random fixes patchset. Or
> I can wait your next version, then merge the whole patchset when it's all get
> reviewed ?

Well I guess you didn't take any of them yet, so I'll republish them in
a little bit.

--D

> Thanks,
> Zorro
> 
> > 
> > --D
> > 
> > > Thanks,
> > > Zorro
> > > 
> > > >  	_scratch_unmount
> > > > +	test $res -eq 0 \
> > > > +		|| _notrun "noattr2 mount option no longer functional"
> > > >  }
> > > >  
> > > >  # getfattr -R returns info in readdir order which varies from fs to fs.
> > > > 
> > > 
> > > 
> > 
> 
> 

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Nirjhar Roy (IBM)]

On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> attr2/noattr2 doesn't do anything anymore and aren't reported in
> /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
> 
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  common/attr |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> 
> diff --git a/common/attr b/common/attr
> index 1c1de63e9d5465..35e0bee4e3aa53 100644
> --- a/common/attr
> +++ b/common/attr
> @@ -241,7 +241,11 @@ _require_noattr2()
>  		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
>  	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
>  		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
> +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
If noatrr2 doesn't do anything, then in that case _try_scratch_mount will ignore noattr2 and mount
will succeed. With the above change, we are just checking if noattr2 appears in /proc/mounts(after
the mount), if yes then the preconditions returns true, else the test using this precondition is
notrun. Right?

This looks okay to me.
Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>

--NR
> +	local res=${PIPESTATUS[2]}
>  	_scratch_unmount
> +	test $res -eq 0 \
> +		|| _notrun "noattr2 mount option no longer functional"
>  }
>  
>  # getfattr -R returns info in readdir order which varies from fs to fs.
> 

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Darrick J. Wong]

On Fri, Oct 24, 2025 at 02:31:16PM +0530, Nirjhar Roy (IBM) wrote:
> On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > attr2/noattr2 doesn't do anything anymore and aren't reported in
> > /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
> > 
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  common/attr |    4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > 
> > diff --git a/common/attr b/common/attr
> > index 1c1de63e9d5465..35e0bee4e3aa53 100644
> > --- a/common/attr
> > +++ b/common/attr
> > @@ -241,7 +241,11 @@ _require_noattr2()
> >  		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
> >  	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
> >  		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
> > +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
> If noatrr2 doesn't do anything, then in that case _try_scratch_mount will ignore noattr2 and mount
> will succeed. With the above change, we are just checking if noattr2 appears in /proc/mounts(after
> the mount), if yes then the preconditions returns true, else the test using this precondition is
> notrun. Right?

Right.

On a pre-6.18 kernel where noattr2 did something, the following will
happen:

a) V4 filesystem, noattr2 actually matters for the mount, and it should
show up in /proc/mounts.  If it doesn't, then the test should not run.

b) V5 filesystem, noattr2 is impossible so the mount fails.  Test will
not run.

With 6.18 the behavior changes:

a) V4 filesystem, noattr2 doesn't do anything, the mount succeeds, but
noattr2 does not show up in /proc/mounts.  The test should not run.

b) V5 filesystem, noattr2 now no longer fails the mount but it doesn't
show up in /proc/mounts either.  The test still should not run.

> This looks okay to me.
> Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>

Thanks!

--D

> --NR
> > +	local res=${PIPESTATUS[2]}
> >  	_scratch_unmount
> > +	test $res -eq 0 \
> > +		|| _notrun "noattr2 mount option no longer functional"
> >  }
> >  
> >  # getfattr -R returns info in readdir order which varies from fs to fs.
> > 
> 
> 

Re: [PATCH 7/8] common/attr: fix _require_noattr2

[Nirjhar Roy (IBM)]

On 10/25/25 03:45, Darrick J. Wong wrote:
> On Fri, Oct 24, 2025 at 02:31:16PM +0530, Nirjhar Roy (IBM) wrote:
>> On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
>>> From: Darrick J. Wong <djwong@kernel.org>
>>>
>>> attr2/noattr2 doesn't do anything anymore and aren't reported in
>>> /proc/mounts, so we need to check /proc/mounts and _notrun as a result.
>>>
>>> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
>>> ---
>>>   common/attr |    4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>>
>>> diff --git a/common/attr b/common/attr
>>> index 1c1de63e9d5465..35e0bee4e3aa53 100644
>>> --- a/common/attr
>>> +++ b/common/attr
>>> @@ -241,7 +241,11 @@ _require_noattr2()
>>>   		|| _fail "_try_scratch_mkfs_xfs failed on $SCRATCH_DEV"
>>>   	_try_scratch_mount -o noattr2 > /dev/null 2>&1 \
>>>   		|| _notrun "noattr2 mount option not supported on $SCRATCH_DEV"
>>> +	grep -w "$SCRATCH_MNT" /proc/mounts | awk '{print $4}' | grep -q -w noattr2
>> If noatrr2 doesn't do anything, then in that case _try_scratch_mount will ignore noattr2 and mount
>> will succeed. With the above change, we are just checking if noattr2 appears in /proc/mounts(after
>> the mount), if yes then the preconditions returns true, else the test using this precondition is
>> notrun. Right?
> Right.
>
> On a pre-6.18 kernel where noattr2 did something, the following will
> happen:
>
> a) V4 filesystem, noattr2 actually matters for the mount, and it should
> show up in /proc/mounts.  If it doesn't, then the test should not run.
>
> b) V5 filesystem, noattr2 is impossible so the mount fails.  Test will
> not run.
>
> With 6.18 the behavior changes:
>
> a) V4 filesystem, noattr2 doesn't do anything, the mount succeeds, but
> noattr2 does not show up in /proc/mounts.  The test should not run.
>
> b) V5 filesystem, noattr2 now no longer fails the mount but it doesn't
> show up in /proc/mounts either.  The test still should not run.

Okay, makes sense. Thank you for the explanation.

--NR

>
>> This looks okay to me.
>> Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
> Thanks!
>
> --D
>
>> --NR
>>> +	local res=${PIPESTATUS[2]}
>>>   	_scratch_unmount
>>> +	test $res -eq 0 \
>>> +		|| _notrun "noattr2 mount option no longer functional"
>>>   }
>>>   
>>>   # getfattr -R returns info in readdir order which varies from fs to fs.
>>>
>>
-- 
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore

[PATCH 8/8] common: fix _require_xfs_io_command pwrite -A for various blocksizes

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

In this predicate, we should test an atomic write of the minimum
supported size, not just 4k.  This fixes a problem where none of the
atomic write tests actually run on a 32k-fsblock xfs because you can't
do a sub-fsblock atomic write.

Cc: <fstests@vger.kernel.org> # v2025.04.13
Fixes: d90ee3b6496346 ("generic: add a test for atomic writes")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 common/rc |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)


diff --git a/common/rc b/common/rc
index 1b78cd0c358bb9..dcae5bc33b19ce 100644
--- a/common/rc
+++ b/common/rc
@@ -3030,16 +3030,24 @@ _require_xfs_io_command()
 	"pwrite")
 		# -N (RWF_NOWAIT) only works with direct vectored I/O writes
 		local pwrite_opts=" "
+		local write_size="4k"
 		if [ "$param" == "-N" ]; then
 			opts+=" -d"
-			pwrite_opts+="-V 1 -b 4k"
+			pwrite_opts+="-V 1 -b $write_size"
 		fi
 		if [ "$param" == "-A" ]; then
 			opts+=" -d"
-			pwrite_opts+="-V 1 -b 4k"
+			# try to write the minimum supported atomic write size
+			write_size="$($XFS_IO_PROG -f -c "statx -r -m $STATX_WRITE_ATOMIC" $testfile 2>/dev/null | \
+				grep atomic_write_unit_min | \
+				grep -o '[0-9]\+')"
+			if [ -z "$write_size" ] || [ "$write_size" = "0" ]; then
+				write_size="0 --not-supported"
+			fi
+			pwrite_opts+="-V 1 -b $write_size"
 		fi
 		testio=`$XFS_IO_PROG -f $opts -c \
-		        "pwrite $pwrite_opts $param 0 4k" $testfile 2>&1`
+		        "pwrite $pwrite_opts $param 0 $write_size" $testfile 2>&1`
 		param_checked="$pwrite_opts $param"
 		;;
 	"scrub"|"repair")

Re: [PATCH 8/8] common: fix _require_xfs_io_command pwrite -A for various blocksizes

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 8/8] common: fix _require_xfs_io_command pwrite -A for various blocksizes

[Nirjhar Roy (IBM)]

On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> In this predicate, we should test an atomic write of the minimum
> supported size, not just 4k.  This fixes a problem where none of the
> atomic write tests actually run on a 32k-fsblock xfs because you can't
> do a sub-fsblock atomic write.
> 
> Cc: <fstests@vger.kernel.org> # v2025.04.13
> Fixes: d90ee3b6496346 ("generic: add a test for atomic writes")
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  common/rc |   14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> 
> diff --git a/common/rc b/common/rc
> index 1b78cd0c358bb9..dcae5bc33b19ce 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -3030,16 +3030,24 @@ _require_xfs_io_command()
>  	"pwrite")
>  		# -N (RWF_NOWAIT) only works with direct vectored I/O writes
>  		local pwrite_opts=" "
> +		local write_size="4k"
>  		if [ "$param" == "-N" ]; then
>  			opts+=" -d"
> -			pwrite_opts+="-V 1 -b 4k"
> +			pwrite_opts+="-V 1 -b $write_size"
Nit: We can still keep this to 4k (or any random size and not necessarily a size = fsblocksize),
right?
>  		fi
>  		if [ "$param" == "-A" ]; then
>  			opts+=" -d"
> -			pwrite_opts+="-V 1 -b 4k"
> +			# try to write the minimum supported atomic write size
> +			write_size="$($XFS_IO_PROG -f -c "statx -r -m $STATX_WRITE_ATOMIC" $testfile 2>/dev/null | \
> +				grep atomic_write_unit_min | \
> +				grep -o '[0-9]\+')"
> +			if [ -z "$write_size" ] || [ "$write_size" = "0" ]; then
> +				write_size="0 --not-supported"
> +			fi
> +			pwrite_opts+="-V 1 -b $write_size"
>  		fi
>  		testio=`$XFS_IO_PROG -f $opts -c \
> -		        "pwrite $pwrite_opts $param 0 4k" $testfile 2>&1`
> +		        "pwrite $pwrite_opts $param 0 $write_size" $testfile 2>&1`
This looks good to me:

Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
>  		param_checked="$pwrite_opts $param"
>  		;;
>  	"scrub"|"repair")
> 

Re: [PATCH 8/8] common: fix _require_xfs_io_command pwrite -A for various blocksizes

[Darrick J. Wong]

On Fri, Oct 24, 2025 at 02:48:00PM +0530, Nirjhar Roy (IBM) wrote:
> On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > In this predicate, we should test an atomic write of the minimum
> > supported size, not just 4k.  This fixes a problem where none of the
> > atomic write tests actually run on a 32k-fsblock xfs because you can't
> > do a sub-fsblock atomic write.
> > 
> > Cc: <fstests@vger.kernel.org> # v2025.04.13
> > Fixes: d90ee3b6496346 ("generic: add a test for atomic writes")
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > ---
> >  common/rc |   14 +++++++++++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > 
> > 
> > diff --git a/common/rc b/common/rc
> > index 1b78cd0c358bb9..dcae5bc33b19ce 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -3030,16 +3030,24 @@ _require_xfs_io_command()
> >  	"pwrite")
> >  		# -N (RWF_NOWAIT) only works with direct vectored I/O writes
> >  		local pwrite_opts=" "
> > +		local write_size="4k"
> >  		if [ "$param" == "-N" ]; then
> >  			opts+=" -d"
> > -			pwrite_opts+="-V 1 -b 4k"
> > +			pwrite_opts+="-V 1 -b $write_size"
> Nit: We can still keep this to 4k (or any random size and not necessarily a size = fsblocksize),
> right?

Well, yes, the default will still be 4k on an old kernel that doesn't
support STATX_WRITE_ATOMIC.  For kernels that do support that flag,
write_size will now be whatever the filesystem claims is the minimum
write unit.

> >  		fi
> >  		if [ "$param" == "-A" ]; then
> >  			opts+=" -d"
> > -			pwrite_opts+="-V 1 -b 4k"
> > +			# try to write the minimum supported atomic write size
> > +			write_size="$($XFS_IO_PROG -f -c "statx -r -m $STATX_WRITE_ATOMIC" $testfile 2>/dev/null | \
> > +				grep atomic_write_unit_min | \
> > +				grep -o '[0-9]\+')"
> > +			if [ -z "$write_size" ] || [ "$write_size" = "0" ]; then
> > +				write_size="0 --not-supported"
> > +			fi
> > +			pwrite_opts+="-V 1 -b $write_size"
> >  		fi
> >  		testio=`$XFS_IO_PROG -f $opts -c \
> > -		        "pwrite $pwrite_opts $param 0 4k" $testfile 2>&1`
> > +		        "pwrite $pwrite_opts $param 0 $write_size" $testfile 2>&1`
> This looks good to me:
> 
> Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>

Thanks!

--D

> >  		param_checked="$pwrite_opts $param"
> >  		;;
> >  	"scrub"|"repair")
> > 
> 
> 

Re: [PATCH 8/8] common: fix _require_xfs_io_command pwrite -A for various blocksizes

[Nirjhar Roy (IBM)]

On 10/25/25 03:46, Darrick J. Wong wrote:
> On Fri, Oct 24, 2025 at 02:48:00PM +0530, Nirjhar Roy (IBM) wrote:
>> On Wed, 2025-10-15 at 09:38 -0700, Darrick J. Wong wrote:
>>> From: Darrick J. Wong <djwong@kernel.org>
>>>
>>> In this predicate, we should test an atomic write of the minimum
>>> supported size, not just 4k.  This fixes a problem where none of the
>>> atomic write tests actually run on a 32k-fsblock xfs because you can't
>>> do a sub-fsblock atomic write.
>>>
>>> Cc: <fstests@vger.kernel.org> # v2025.04.13
>>> Fixes: d90ee3b6496346 ("generic: add a test for atomic writes")
>>> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
>>> ---
>>>   common/rc |   14 +++++++++++---
>>>   1 file changed, 11 insertions(+), 3 deletions(-)
>>>
>>>
>>> diff --git a/common/rc b/common/rc
>>> index 1b78cd0c358bb9..dcae5bc33b19ce 100644
>>> --- a/common/rc
>>> +++ b/common/rc
>>> @@ -3030,16 +3030,24 @@ _require_xfs_io_command()
>>>   	"pwrite")
>>>   		# -N (RWF_NOWAIT) only works with direct vectored I/O writes
>>>   		local pwrite_opts=" "
>>> +		local write_size="4k"
>>>   		if [ "$param" == "-N" ]; then
>>>   			opts+=" -d"
>>> -			pwrite_opts+="-V 1 -b 4k"
>>> +			pwrite_opts+="-V 1 -b $write_size"
>> Nit: We can still keep this to 4k (or any random size and not necessarily a size = fsblocksize),
>> right?
> Well, yes, the default will still be 4k on an old kernel that doesn't
> support STATX_WRITE_ATOMIC.  For kernels that do support that flag,
> write_size will now be whatever the filesystem claims is the minimum
> write unit.

Okay.

--NR

>
>>>   		fi
>>>   		if [ "$param" == "-A" ]; then
>>>   			opts+=" -d"
>>> -			pwrite_opts+="-V 1 -b 4k"
>>> +			# try to write the minimum supported atomic write size
>>> +			write_size="$($XFS_IO_PROG -f -c "statx -r -m $STATX_WRITE_ATOMIC" $testfile 2>/dev/null | \
>>> +				grep atomic_write_unit_min | \
>>> +				grep -o '[0-9]\+')"
>>> +			if [ -z "$write_size" ] || [ "$write_size" = "0" ]; then
>>> +				write_size="0 --not-supported"
>>> +			fi
>>> +			pwrite_opts+="-V 1 -b $write_size"
>>>   		fi
>>>   		testio=`$XFS_IO_PROG -f $opts -c \
>>> -		        "pwrite $pwrite_opts $param 0 4k" $testfile 2>&1`
>>> +		        "pwrite $pwrite_opts $param 0 $write_size" $testfile 2>&1`
>> This looks good to me:
>>
>> Reviewed-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
> Thanks!
>
> --D
>
>>>   		param_checked="$pwrite_opts $param"
>>>   		;;
>>>   	"scrub"|"repair")
>>>
>>
-- 
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore