[PATCH] ext4: set awu_max_opt to awu_max

[PATCH] ext4: set awu_max_opt to awu_max

[Pankaj Raghav]

commit 5d894321c49e ("fs: add atomic write unit max opt to statx")
added atomic write max optimal to statx. As XFS can support large atomic
writes through SW, max_opt exposes the value that will be HW accelerated
atomics.

As ext4 does not support SW atomics, set awu_max_opt to awu_max.

Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
---
 fs/ext4/inode.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 26f0f9714f03..93056c971e74 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -6304,7 +6304,8 @@ int ext4_getattr(struct mnt_idmap *idmap, const struct path *path,
 			awu_max = sbi->s_awu_max;
 		}
 
-		generic_fill_statx_atomic_writes(stat, awu_min, awu_max, 0);
+		generic_fill_statx_atomic_writes(stat, awu_min, awu_max,
+						 awu_max);
 	}
 
 	flags = ei->i_flags & EXT4_FL_USER_VISIBLE;

base-commit: d5ba62a0b130441bcabca59c2fd2d59e65360234
-- 
2.51.2

Re: [PATCH] ext4: set awu_max_opt to awu_max

[sashiko-bot]

> commit 5d894321c49e ("fs: add atomic write unit max opt to statx")
> added atomic write max optimal to statx. As XFS can support large atomic
> writes through SW, max_opt exposes the value that will be HW accelerated
> atomics.
> 
> As ext4 does not support SW atomics, set awu_max_opt to awu_max.
> 
> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910100829.2532894-1-p.raghav@samsung.com?part=1

Re: [PATCH] ext4: set awu_max_opt to awu_max

[Jan Kara]

On Thu 10-09-26 12:08:29, Pankaj Raghav wrote:
> commit 5d894321c49e ("fs: add atomic write unit max opt to statx")
> added atomic write max optimal to statx. As XFS can support large atomic
> writes through SW, max_opt exposes the value that will be HW accelerated
> atomics.
> 
> As ext4 does not support SW atomics, set awu_max_opt to awu_max.
> 
> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>

Yes, I guess it's better to report it than not and let userspace guess. Feel
free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/ext4/inode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 26f0f9714f03..93056c971e74 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -6304,7 +6304,8 @@ int ext4_getattr(struct mnt_idmap *idmap, const struct path *path,
>  			awu_max = sbi->s_awu_max;
>  		}
>  
> -		generic_fill_statx_atomic_writes(stat, awu_min, awu_max, 0);
> +		generic_fill_statx_atomic_writes(stat, awu_min, awu_max,
> +						 awu_max);
>  	}
>  
>  	flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
> 
> base-commit: d5ba62a0b130441bcabca59c2fd2d59e65360234
> -- 
> 2.51.2
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] ext4: set awu_max_opt to awu_max

[Ritesh Harjani]

Pankaj Raghav <p.raghav@samsung.com> writes:

> commit 5d894321c49e ("fs: add atomic write unit max opt to statx")
> added atomic write max optimal to statx. As XFS can support large atomic
> writes through SW, max_opt exposes the value that will be HW accelerated
> atomics.
>
> As ext4 does not support SW atomics, set awu_max_opt to awu_max.
>

As per the man page the awu_max_opt=0 means:

    A value of zero indicates that stx_atomic_write_unit_max is the
    optimised limit.

[1]: https://man7.org/linux/man-pages/man2/statx.2.html

But the value of 0 isn't wrong either. Jan, added that it might be more
clear to report awu_max there instead of 0. So, if are going to do it -
let's add this info to the commit msg. So it doesn't look like we were
trying to fix anything here ;)

btw note that bdev_statx() still reports 0 for awu_max_opt.

With that please feel free to add:

Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
> ---
>  fs/ext4/inode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 26f0f9714f03..93056c971e74 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -6304,7 +6304,8 @@ int ext4_getattr(struct mnt_idmap *idmap, const struct path *path,
>  			awu_max = sbi->s_awu_max;
>  		}
>  
> -		generic_fill_statx_atomic_writes(stat, awu_min, awu_max, 0);
> +		generic_fill_statx_atomic_writes(stat, awu_min, awu_max,
> +						 awu_max);
>  	}
>  
>  	flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
>
> base-commit: d5ba62a0b130441bcabca59c2fd2d59e65360234
> -- 
> 2.51.2

Re: [PATCH] ext4: set awu_max_opt to awu_max

[Ojaswin Mujoo]

On Thu, Sep 10, 2026 at 12:08:29PM +0200, Pankaj Raghav wrote:
> commit 5d894321c49e ("fs: add atomic write unit max opt to statx")
> added atomic write max optimal to statx. As XFS can support large atomic
> writes through SW, max_opt exposes the value that will be HW accelerated
> atomics.
> 
> As ext4 does not support SW atomics, set awu_max_opt to awu_max.
> 
> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>

Hey Pankaj, I think 0 is allowed for backward compatibility as
highlighted in the commit you mentioned:
	...
	Masks STATX{_ATTR}_WRITE_ATOMIC can be used to get this new field. This is
  ok for older kernels which don't support this new field, as they would
  report 0 in this field (from zeroing in cp_statx()) already.
	...
	
But yeah sure, advertising it as awu_max is more clearer. 

Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>

Regards,
ojaswin


> ---
>  fs/ext4/inode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 26f0f9714f03..93056c971e74 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -6304,7 +6304,8 @@ int ext4_getattr(struct mnt_idmap *idmap, const struct path *path,
>  			awu_max = sbi->s_awu_max;
>  		}
>  
> -		generic_fill_statx_atomic_writes(stat, awu_min, awu_max, 0);
> +		generic_fill_statx_atomic_writes(stat, awu_min, awu_max,
> +						 awu_max);
>  	}
>  
>  	flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
> 
> base-commit: d5ba62a0b130441bcabca59c2fd2d59e65360234
> -- 
> 2.51.2
> 

Re: [PATCH] ext4: set awu_max_opt to awu_max

[Pankaj Raghav]

Sorry for the late reply.

On 9/10/26 17:15, Ritesh Harjani (IBM) wrote:
> Pankaj Raghav <p.raghav@samsung.com> writes:
> 
>> commit 5d894321c49e ("fs: add atomic write unit max opt to statx")
>> added atomic write max optimal to statx. As XFS can support large atomic
>> writes through SW, max_opt exposes the value that will be HW accelerated
>> atomics.
>>
>> As ext4 does not support SW atomics, set awu_max_opt to awu_max.
>>
> 
> As per the man page the awu_max_opt=0 means:
> 
>     A value of zero indicates that stx_atomic_write_unit_max is the
>     optimised limit.
> 
> [1]: https://man7.org/linux/man-pages/man2/statx.2.html
> 
> But the value of 0 isn't wrong either. Jan, added that it might be more

Yes.

> clear to report awu_max there instead of 0. So, if are going to do it -
> let's add this info to the commit msg. So it doesn't look like we were
> trying to fix anything here ;)
> 

That is why I did not put any fixes tag, as 0 just indicates awu_max is the supported value.

I can update the commit message to make this more explicit.

I guess this is not a problem for ext4, but for XFS, is there a way for the applications to reliably
know whether the atomic command will be HW accelerated or not?

For normal SSDs:
ext4: awu_min and awu_max = 0, awu_max_opt = 0
XFS: awu_min = fs block size, awu_max = SW atomic max, awu_max_opt = 0

For Atomic SSDs:
ext4 with bigalloc (without these patches): awu_min = fs block size, awu_max= HW atomic limit
awu_max_opt = 0
XFS: awu_min = fs block size, awu_max = SW atomic max, awu_max_opt = HW atomic limit


As a user who would only like HW atomic path, it is very hard to know which value to use unless
they know what each filesystem does.

Even though statx says zero to indicate stx_atomic_write_unit_max is the optimized limit, I think
it is better for all the filesystems who support HW atomics to set the max_opt to the HW optimized
limit to make life easier for the users.


> btw note that bdev_statx() still reports 0 for awu_max_opt.
> 

I will send a separate patch for this as well. Thanks.


--
Pankaj