On Mon, Oct 02, 2023 at 10:51:36AM +0100, John Garry wrote:
> On 01/10/2023 14:23, Bart Van Assche wrote:
> > On 9/29/23 15:49, Eric Biggers wrote:
> > > On Fri, Sep 29, 2023 at 10:27:08AM +0000, John Garry wrote:
> > > > 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
>
> > >
> > > > +#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@xxxxxxxxxxxxx
