On Mon, Oct 02, 2023 at 10:51:36AM +0100, John Garry wrote:

On 01/10/2023 14:23, Bart Van Assche wrote:

quoted

On 9/29/23 15:49, Eric Biggers wrote:

quoted

On Fri, Sep 29, 2023 at 10:27:08AM +0000, John Garry wrote:

quoted

diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
index 7cab2c65d3d7..c99d7cac2aa6 100644
--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h

@@ -127,7 +127,10 @@ struct statx {

      __u32    stx_dio_mem_align;    /* Memory buffer alignment
for direct I/O */
      __u32    stx_dio_offset_align;    /* File offset alignment
for direct I/O */
      /* 0xa0 */
-    __u64    __spare3[12];    /* Spare space for future expansion */
+    __u32    stx_atomic_write_unit_max;
+    __u32    stx_atomic_write_unit_min;

Maybe min first and then max?  That seems a bit more natural, and a
lot of the
code you've written handle them in that order.

ok, I think it's fine to reorder

quoted

quoted

quoted

+#define STATX_ATTR_WRITE_ATOMIC        0x00400000 /* File
supports atomic write operations */

How would this differ from stx_atomic_write_unit_min != 0?

Yeah, I suppose that we can just not set this for the case of
stx_atomic_write_unit_min == 0.

Please use the STATX_ATTR_WRITE_ATOMIC flag to indicate that the
filesystem, file and underlying device support atomic writes when
the values are non-zero. The whole point of the attribute mask is
that the caller can check the mask for supported functionality
without having to read every field in the statx structure to
determine if the functionality it wants is present.

-Dave.
-- 
Dave Chinner
david@fromorbit.com