| Message ID | 20220518235011.153058-2-ebiggers@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | make statx() return I/O alignment information | expand |
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > Traditionally, the conditions for when DIO (direct I/O) is supported > were fairly simple: filesystems either supported DIO aligned to the > block device's logical block size, or didn't support DIO at all. > > However, due to filesystem features that have been added over time (e.g, > data journalling, inline data, encryption, verity, compression, > checkpoint disabling, log-structured mode), the conditions for when DIO > is allowed on a file have gotten increasingly complex. Whether a > particular file supports DIO, and with what alignment, can depend on > various file attributes and filesystem mount options, as well as which > block device(s) the file's data is located on. > > XFS has an ioctl XFS_IOC_DIOINFO which exposes this information to > applications. However, as discussed > (https://lore.kernel.org/linux-fsdevel/20220120071215.123274-1-ebiggers@kernel.org/T/#u), > this ioctl is rarely used and not known to be used outside of > XFS-specific code. It also was never intended to indicate when a file > doesn't support DIO at all, and it only exposes the minimum I/O > alignment, not the optimal I/O alignment which has been requested too. > > Therefore, let's expose this information via statx(). Add the > STATX_IOALIGN flag and three fields associated with it: > > * stx_mem_align_dio: the alignment (in bytes) required for user memory > buffers for DIO, or 0 if DIO is not supported on the file. > > * stx_offset_align_dio: the alignment (in bytes) required for file > offsets and I/O segment lengths for DIO, or 0 if DIO is not supported > on the file. This will only be nonzero if stx_mem_align_dio is > nonzero, and vice versa. > > * stx_offset_align_optimal: the alignment (in bytes) suggested for file > offsets and I/O segment lengths to get optimal performance. This > applies to both DIO and buffered I/O. It differs from stx_blocksize > in that stx_offset_align_optimal will contain the real optimum I/O > size, which may be a large value. In contrast, for compatibility > reasons stx_blocksize is the minimum size needed to avoid page cache > read/write/modify cycles, which may be much smaller than the optimum > I/O size. For more details about the motivation for this field, see > https://lore.kernel.org/r/20220210040304.GM59729@dread.disaster.area Hmm. So I guess this is supposed to be the filesystem's best guess at the IO size that will minimize RMW cycles in the entire stack? i.e. if the user does not want RMW of pagecache pages, of file allocation units (if COW is enabled), of RAID stripes, or in the storage itself, then it should ensure that all IOs are aligned to this value? I guess that means for XFS it's effectively max(pagesize, i_blocksize, bdev io_opt, sb_width, and (pretend XFS can reflink the realtime volume) the rt extent size)? I didn't see a manpage update for statx(2) but that's mostly what I'm interested in. :) Looking ahead, it looks like the ext4/f2fs implementations only seem to be returning max(i_blocksize, bdev io_opt)? But not the pagesize? Did I misunderstood this, then? (The plumbing changes in this patch look ok.) --D > Note that as with other statx() extensions, if STATX_IOALIGN isn't set > in the returned statx struct, then these new fields won't be filled in. > This will happen if the filesystem doesn't support STATX_IOALIGN, or if > the file isn't a regular file. (It might be supported on block device > files in the future.) It might also happen if the caller didn't include > STATX_IOALIGN in the request mask, since statx() isn't required to > return information that wasn't requested. > > This commit adds the VFS-level plumbing for STATX_IOALIGN. Individual > filesystems will still need to add code to support it. > > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- > fs/stat.c | 3 +++ > include/linux/stat.h | 3 +++ > include/uapi/linux/stat.h | 9 +++++++-- > 3 files changed, 13 insertions(+), 2 deletions(-) > > diff --git a/fs/stat.c b/fs/stat.c > index 5c2c94464e8b0..9d477218545b8 100644 > --- a/fs/stat.c > +++ b/fs/stat.c > @@ -611,6 +611,9 @@ cp_statx(const struct kstat *stat, struct statx __user *buffer) > tmp.stx_dev_major = MAJOR(stat->dev); > tmp.stx_dev_minor = MINOR(stat->dev); > tmp.stx_mnt_id = stat->mnt_id; > + tmp.stx_mem_align_dio = stat->mem_align_dio; > + tmp.stx_offset_align_dio = stat->offset_align_dio; > + tmp.stx_offset_align_optimal = stat->offset_align_optimal; > > return copy_to_user(buffer, &tmp, sizeof(tmp)) ? -EFAULT : 0; > } > diff --git a/include/linux/stat.h b/include/linux/stat.h > index 7df06931f25d8..48b8b1ad1567c 100644 > --- a/include/linux/stat.h > +++ b/include/linux/stat.h > @@ -50,6 +50,9 @@ struct kstat { > struct timespec64 btime; /* File creation time */ > u64 blocks; > u64 mnt_id; > + u32 mem_align_dio; > + u32 offset_align_dio; > + u32 offset_align_optimal; > }; > > #endif > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h > index 1500a0f58041a..f822b23e81091 100644 > --- a/include/uapi/linux/stat.h > +++ b/include/uapi/linux/stat.h > @@ -124,9 +124,13 @@ struct statx { > __u32 stx_dev_minor; > /* 0x90 */ > __u64 stx_mnt_id; > - __u64 __spare2; > + __u32 stx_mem_align_dio; /* Memory buffer alignment for direct I/O */ > + __u32 stx_offset_align_dio; /* File offset alignment for direct I/O */ > /* 0xa0 */ > - __u64 __spare3[12]; /* Spare space for future expansion */ > + __u32 stx_offset_align_optimal; /* Optimal file offset alignment for I/O */ > + __u32 __spare2; > + /* 0xa8 */ > + __u64 __spare3[11]; /* Spare space for future expansion */ > /* 0x100 */ > }; > > @@ -152,6 +156,7 @@ struct statx { > #define STATX_BASIC_STATS 0x000007ffU /* The stuff in the normal stat struct */ > #define STATX_BTIME 0x00000800U /* Want/got stx_btime */ > #define STATX_MNT_ID 0x00001000U /* Got stx_mnt_id */ > +#define STATX_IOALIGN 0x00002000U /* Want/got IO alignment info */ > > #define STATX__RESERVED 0x80000000U /* Reserved for future struct statx expansion */ > > -- > 2.36.1 >
On Thu, May 19, 2022 at 04:06:05PM -0700, Darrick J. Wong wrote: > On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote: > > From: Eric Biggers <ebiggers@google.com> > > > > Traditionally, the conditions for when DIO (direct I/O) is supported > > were fairly simple: filesystems either supported DIO aligned to the > > block device's logical block size, or didn't support DIO at all. > > > > However, due to filesystem features that have been added over time (e.g, > > data journalling, inline data, encryption, verity, compression, > > checkpoint disabling, log-structured mode), the conditions for when DIO > > is allowed on a file have gotten increasingly complex. Whether a > > particular file supports DIO, and with what alignment, can depend on > > various file attributes and filesystem mount options, as well as which > > block device(s) the file's data is located on. > > > > XFS has an ioctl XFS_IOC_DIOINFO which exposes this information to > > applications. However, as discussed > > (https://lore.kernel.org/linux-fsdevel/20220120071215.123274-1-ebiggers@kernel.org/T/#u), > > this ioctl is rarely used and not known to be used outside of > > XFS-specific code. It also was never intended to indicate when a file > > doesn't support DIO at all, and it only exposes the minimum I/O > > alignment, not the optimal I/O alignment which has been requested too. > > > > Therefore, let's expose this information via statx(). Add the > > STATX_IOALIGN flag and three fields associated with it: > > > > * stx_mem_align_dio: the alignment (in bytes) required for user memory > > buffers for DIO, or 0 if DIO is not supported on the file. > > > > * stx_offset_align_dio: the alignment (in bytes) required for file > > offsets and I/O segment lengths for DIO, or 0 if DIO is not supported > > on the file. This will only be nonzero if stx_mem_align_dio is > > nonzero, and vice versa. > > > > * stx_offset_align_optimal: the alignment (in bytes) suggested for file > > offsets and I/O segment lengths to get optimal performance. This > > applies to both DIO and buffered I/O. It differs from stx_blocksize > > in that stx_offset_align_optimal will contain the real optimum I/O > > size, which may be a large value. In contrast, for compatibility > > reasons stx_blocksize is the minimum size needed to avoid page cache > > read/write/modify cycles, which may be much smaller than the optimum > > I/O size. For more details about the motivation for this field, see > > https://lore.kernel.org/r/20220210040304.GM59729@dread.disaster.area > > Hmm. So I guess this is supposed to be the filesystem's best guess at > the IO size that will minimize RMW cycles in the entire stack? i.e. if > the user does not want RMW of pagecache pages, of file allocation units > (if COW is enabled), of RAID stripes, or in the storage itself, then it > should ensure that all IOs are aligned to this value? > > I guess that means for XFS it's effectively max(pagesize, i_blocksize, > bdev io_opt, sb_width, and (pretend XFS can reflink the realtime volume) > the rt extent size)? I didn't see a manpage update for statx(2) but > that's mostly what I'm interested in. :) Yup, xfs_stat_blksize() should give a good idea of what we should do. It will end up being pretty much that, except without the need to a mount option to turn on the sunit/swidth return, and always taking into consideration extent size hints rather than just doing that for RT inodes... Cheers, Dave.
On Thu, May 19, 2022 at 04:06:05PM -0700, Darrick J. Wong wrote: > I guess that means for XFS it's effectively max(pagesize, i_blocksize, > bdev io_opt, sb_width, and (pretend XFS can reflink the realtime volume) > the rt extent size)? I didn't see a manpage update for statx(2) but > that's mostly what I'm interested in. :) I'll send out a man page update with the next version. I don't think there will be much new information that isn't already included in this patchset, though. > Looking ahead, it looks like the ext4/f2fs implementations only seem to > be returning max(i_blocksize, bdev io_opt)? But not the pagesize? I think that's just an oversight. ext4 and f2fs should round the value up to PAGE_SIZE. - Eric
On Wed, May 18, 2022 at 04:50:05PM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > Traditionally, the conditions for when DIO (direct I/O) is supported > were fairly simple: filesystems either supported DIO aligned to the > block device's logical block size, or didn't support DIO at all. > > However, due to filesystem features that have been added over time (e.g, > data journalling, inline data, encryption, verity, compression, > checkpoint disabling, log-structured mode), the conditions for when DIO > is allowed on a file have gotten increasingly complex. Whether a > particular file supports DIO, and with what alignment, can depend on > various file attributes and filesystem mount options, as well as which > block device(s) the file's data is located on. > > XFS has an ioctl XFS_IOC_DIOINFO which exposes this information to > applications. However, as discussed > (https://lore.kernel.org/linux-fsdevel/20220120071215.123274-1-ebiggers@kernel.org/T/#u), > this ioctl is rarely used and not known to be used outside of > XFS-specific code. It also was never intended to indicate when a file > doesn't support DIO at all, and it only exposes the minimum I/O > alignment, not the optimal I/O alignment which has been requested too. > > Therefore, let's expose this information via statx(). Add the > STATX_IOALIGN flag and three fields associated with it: > > * stx_mem_align_dio: the alignment (in bytes) required for user memory > buffers for DIO, or 0 if DIO is not supported on the file. > > * stx_offset_align_dio: the alignment (in bytes) required for file > offsets and I/O segment lengths for DIO, or 0 if DIO is not supported > on the file. This will only be nonzero if stx_mem_align_dio is > nonzero, and vice versa. > > * stx_offset_align_optimal: the alignment (in bytes) suggested for file > offsets and I/O segment lengths to get optimal performance. This > applies to both DIO and buffered I/O. It differs from stx_blocksize > in that stx_offset_align_optimal will contain the real optimum I/O > size, which may be a large value. In contrast, for compatibility > reasons stx_blocksize is the minimum size needed to avoid page cache > read/write/modify cycles, which may be much smaller than the optimum > I/O size. For more details about the motivation for this field, see > https://lore.kernel.org/r/20220210040304.GM59729@dread.disaster.area > > Note that as with other statx() extensions, if STATX_IOALIGN isn't set > in the returned statx struct, then these new fields won't be filled in. > This will happen if the filesystem doesn't support STATX_IOALIGN, or if > the file isn't a regular file. (It might be supported on block device > files in the future.) It might also happen if the caller didn't include > STATX_IOALIGN in the request mask, since statx() isn't required to > return information that wasn't requested. > > This commit adds the VFS-level plumbing for STATX_IOALIGN. Individual > filesystems will still need to add code to support it. > > Signed-off-by: Eric Biggers <ebiggers@google.com> > --- Looks good to me, Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
* Eric Biggers: > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h > index 1500a0f58041a..f822b23e81091 100644 > --- a/include/uapi/linux/stat.h > +++ b/include/uapi/linux/stat.h > @@ -124,9 +124,13 @@ struct statx { > __u32 stx_dev_minor; > /* 0x90 */ > __u64 stx_mnt_id; > - __u64 __spare2; > + __u32 stx_mem_align_dio; /* Memory buffer alignment for direct I/O */ > + __u32 stx_offset_align_dio; /* File offset alignment for direct I/O */ > /* 0xa0 */ > - __u64 __spare3[12]; /* Spare space for future expansion */ > + __u32 stx_offset_align_optimal; /* Optimal file offset alignment for I/O */ > + __u32 __spare2; > + /* 0xa8 */ > + __u64 __spare3[11]; /* Spare space for future expansion */ > /* 0x100 */ > }; Are 32 bits enough? Would it make sense to store the base-2 logarithm instead? Thanks, Florian
On Fri, May 27, 2022 at 11:02:46AM +0200, Florian Weimer wrote: > * Eric Biggers: > > > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h > > index 1500a0f58041a..f822b23e81091 100644 > > --- a/include/uapi/linux/stat.h > > +++ b/include/uapi/linux/stat.h > > @@ -124,9 +124,13 @@ struct statx { > > __u32 stx_dev_minor; > > /* 0x90 */ > > __u64 stx_mnt_id; > > - __u64 __spare2; > > + __u32 stx_mem_align_dio; /* Memory buffer alignment for direct I/O */ > > + __u32 stx_offset_align_dio; /* File offset alignment for direct I/O */ > > /* 0xa0 */ > > - __u64 __spare3[12]; /* Spare space for future expansion */ > > + __u32 stx_offset_align_optimal; /* Optimal file offset alignment for I/O */ > > + __u32 __spare2; > > + /* 0xa8 */ > > + __u64 __spare3[11]; /* Spare space for future expansion */ > > /* 0x100 */ > > }; > > Are 32 bits enough? Would it make sense to store the base-2 logarithm > instead? I don't think a log2 will work here, XFS will want to report things like raid stripe sizes, which can be any multiple of the fs blocksize. 32 bits is probably enough, seeing as the kernel won't do an IO larger than 2GB anyway. --D > Thanks, > Florian >
On Fri, May 20, 2022 at 01:27:39PM +1000, Dave Chinner wrote: > > > * stx_offset_align_optimal: the alignment (in bytes) suggested for file > > > offsets and I/O segment lengths to get optimal performance. This > > > applies to both DIO and buffered I/O. It differs from stx_blocksize > > > in that stx_offset_align_optimal will contain the real optimum I/O > > > size, which may be a large value. In contrast, for compatibility > > > reasons stx_blocksize is the minimum size needed to avoid page cache > > > read/write/modify cycles, which may be much smaller than the optimum > > > I/O size. For more details about the motivation for this field, see > > > https://lore.kernel.org/r/20220210040304.GM59729@dread.disaster.area > > > > Hmm. So I guess this is supposed to be the filesystem's best guess at > > the IO size that will minimize RMW cycles in the entire stack? i.e. if > > the user does not want RMW of pagecache pages, of file allocation units > > (if COW is enabled), of RAID stripes, or in the storage itself, then it > > should ensure that all IOs are aligned to this value? > > > > I guess that means for XFS it's effectively max(pagesize, i_blocksize, > > bdev io_opt, sb_width, and (pretend XFS can reflink the realtime volume) > > the rt extent size)? I didn't see a manpage update for statx(2) but > > that's mostly what I'm interested in. :) > > Yup, xfs_stat_blksize() should give a good idea of what we should > do. It will end up being pretty much that, except without the need > to a mount option to turn on the sunit/swidth return, and always > taking into consideration extent size hints rather than just doing > that for RT inodes... While working on the man-pages update, I'm having second thoughts about the stx_offset_align_optimal field. Does any filesystem other than XFS actually want stx_offset_align_optimal, when st[x]_blksize already exists? Many network filesystems, as well as tmpfs when hugepages are enabled, already report large (megabytes) sizes in st[x]_blksize. And all documentation I looked at (man pages for Linux, POSIX, FreeBSD, NetBSD, macOS) documents st_blksize as something like "the preferred blocksize for efficient I/O". It's never documented as being limited to PAGE_SIZE, which makes sense because it's not. So stx_offset_align_optimal seems redundant, and it is going to confuse application developers who will have to decide when to use st[x]_blksize and when to use stx_offset_align_optimal. Also, applications that don't work well with huge reported optimal I/O sizes would still continue to exist, as it will remain possible for applications to only be tested on filesystems that report a small optimal I/O size. Perhaps for now we should just add STATX_DIOALIGN instead of STATX_IOALIGN, leaving out the stx_offset_align_optimal field? What do people think? - Eric
On Mon, Jun 13, 2022 at 10:25:12PM -0700, Eric Biggers wrote: > While working on the man-pages update, I'm having second thoughts about the > stx_offset_align_optimal field. Does any filesystem other than XFS actually > want stx_offset_align_optimal, when st[x]_blksize already exists? Many network > filesystems, as well as tmpfs when hugepages are enabled, already report large > (megabytes) sizes in st[x]_blksize. And all documentation I looked at (man > pages for Linux, POSIX, FreeBSD, NetBSD, macOS) documents st_blksize as > something like "the preferred blocksize for efficient I/O". It's never > documented as being limited to PAGE_SIZE, which makes sense because it's not. Yes. While st_blksize is utterly misnamed, it has always aways been the optimal I/O size. > Perhaps for now we should just add STATX_DIOALIGN instead of STATX_IOALIGN, > leaving out the stx_offset_align_optimal field? What do people think? Yes, this sounds like a good plan.
On Wed, Jun 15, 2022 at 06:12:04AM -0700, Christoph Hellwig wrote: > On Mon, Jun 13, 2022 at 10:25:12PM -0700, Eric Biggers wrote: > > While working on the man-pages update, I'm having second thoughts about the > > stx_offset_align_optimal field. Does any filesystem other than XFS actually > > want stx_offset_align_optimal, when st[x]_blksize already exists? Many network > > filesystems, as well as tmpfs when hugepages are enabled, already report large > > (megabytes) sizes in st[x]_blksize. And all documentation I looked at (man > > pages for Linux, POSIX, FreeBSD, NetBSD, macOS) documents st_blksize as > > something like "the preferred blocksize for efficient I/O". It's never > > documented as being limited to PAGE_SIZE, which makes sense because it's not. > > Yes. While st_blksize is utterly misnamed, it has always aways been > the optimal I/O size. > > > Perhaps for now we should just add STATX_DIOALIGN instead of STATX_IOALIGN, > > leaving out the stx_offset_align_optimal field? What do people think? > > Yes, this sounds like a good plan. One more thing. I'm trying to add support for STATX_DIOALIGN on block devices. Unfortunately I don't think it is going to work, at all, since the inode is for the device node and not the block device itself. This is true even after the file is opened (I previously thought that at least that case would work). Were you expecting that this would work on block devices? It seems they will need a different API -- a new BLK* ioctl, or files in /sys/block/$dev/queue. - Eric
On Wed, Jun 15, 2022 at 05:04:57PM -0700, Eric Biggers wrote: > One more thing. I'm trying to add support for STATX_DIOALIGN on block devices. > Unfortunately I don't think it is going to work, at all, since the inode is for > the device node and not the block device itself. This is true even after the > file is opened (I previously thought that at least that case would work). For an open file the block device inode is pointed to by file->f_mapping->host. > Were you expecting that this would work on block devices? It seems they will > need a different API -- a new BLK* ioctl, or files in /sys/block/$dev/queue. blkdev_get_no_open on inode->i_rdev gets you the block device, which then has bdev->bd_inode point to the underlying block device, although for a block device those limit probably would be retrieved not from the inode but the gendisk / request_queue anyway.
On Wed, Jun 15, 2022 at 11:07:17PM -0700, Christoph Hellwig wrote: > On Wed, Jun 15, 2022 at 05:04:57PM -0700, Eric Biggers wrote: > > One more thing. I'm trying to add support for STATX_DIOALIGN on block devices. > > Unfortunately I don't think it is going to work, at all, since the inode is for > > the device node and not the block device itself. This is true even after the > > file is opened (I previously thought that at least that case would work). > > For an open file the block device inode is pointed to by > file->f_mapping->host. > > > Were you expecting that this would work on block devices? It seems they will > > need a different API -- a new BLK* ioctl, or files in /sys/block/$dev/queue. > > blkdev_get_no_open on inode->i_rdev gets you the block device, which > then has bdev->bd_inode point to the underlying block device, although > for a block device those limit probably would be retrieved not from > the inode but the gendisk / request_queue anyway. Yes I know that. The issue is that the inode that statx() is operating on is the device node, so *all* the other statx fields come from that inode. Size, nlink, uid, gid, mode, timestamps (including btime if the filesystem supports it), inode number, device number of the containing filesystem, mount ID, etc. If we were to randomly grab one field from the underlying block device instead, that would be inconsistent with everything else. - Eric
On Wed, Jun 15, 2022 at 11:19:32PM -0700, Eric Biggers wrote: > Yes I know that. The issue is that the inode that statx() is operating on is > the device node, so *all* the other statx fields come from that inode. Size, > nlink, uid, gid, mode, timestamps (including btime if the filesystem supports > it), inode number, device number of the containing filesystem, mount ID, etc. > If we were to randomly grab one field from the underlying block device instead, > that would be inconsistent with everything else. At least on XFS we have a magic hardcoded st_blksize for block devices, but it seems like the generic doesn't do that. But I'm really much more worried about an inconsistency where we get usefull information or some special files rather than where we acquire this information from. So I think going to the block device inode, and also going to it for stx_blksize is the right thing as it actually makes the interface useful. We just need a good helper that all getattr implementations can use to be consistent and/or override these fields after the call to ->getattr.
diff --git a/fs/stat.c b/fs/stat.c index 5c2c94464e8b0..9d477218545b8 100644 --- a/fs/stat.c +++ b/fs/stat.c @@ -611,6 +611,9 @@ cp_statx(const struct kstat *stat, struct statx __user *buffer) tmp.stx_dev_major = MAJOR(stat->dev); tmp.stx_dev_minor = MINOR(stat->dev); tmp.stx_mnt_id = stat->mnt_id; + tmp.stx_mem_align_dio = stat->mem_align_dio; + tmp.stx_offset_align_dio = stat->offset_align_dio; + tmp.stx_offset_align_optimal = stat->offset_align_optimal; return copy_to_user(buffer, &tmp, sizeof(tmp)) ? -EFAULT : 0; } diff --git a/include/linux/stat.h b/include/linux/stat.h index 7df06931f25d8..48b8b1ad1567c 100644 --- a/include/linux/stat.h +++ b/include/linux/stat.h @@ -50,6 +50,9 @@ struct kstat { struct timespec64 btime; /* File creation time */ u64 blocks; u64 mnt_id; + u32 mem_align_dio; + u32 offset_align_dio; + u32 offset_align_optimal; }; #endif diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h index 1500a0f58041a..f822b23e81091 100644 --- a/include/uapi/linux/stat.h +++ b/include/uapi/linux/stat.h @@ -124,9 +124,13 @@ struct statx { __u32 stx_dev_minor; /* 0x90 */ __u64 stx_mnt_id; - __u64 __spare2; + __u32 stx_mem_align_dio; /* Memory buffer alignment for direct I/O */ + __u32 stx_offset_align_dio; /* File offset alignment for direct I/O */ /* 0xa0 */ - __u64 __spare3[12]; /* Spare space for future expansion */ + __u32 stx_offset_align_optimal; /* Optimal file offset alignment for I/O */ + __u32 __spare2; + /* 0xa8 */ + __u64 __spare3[11]; /* Spare space for future expansion */ /* 0x100 */ }; @@ -152,6 +156,7 @@ struct statx { #define STATX_BASIC_STATS 0x000007ffU /* The stuff in the normal stat struct */ #define STATX_BTIME 0x00000800U /* Want/got stx_btime */ #define STATX_MNT_ID 0x00001000U /* Got stx_mnt_id */ +#define STATX_IOALIGN 0x00002000U /* Want/got IO alignment info */ #define STATX__RESERVED 0x80000000U /* Reserved for future struct statx expansion */