From: "Darrick J. Wong" <djwong@kernel.org> To: Florian Weimer <fweimer@redhat.com> Cc: Eric Biggers <ebiggers@kernel.org>, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-api@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Keith Busch <kbusch@kernel.org> Subject: Re: [RFC PATCH v2 1/7] statx: add I/O alignment information Date: Fri, 27 May 2022 09:22:54 -0700 [thread overview] Message-ID: <YpD63ocQmmgpZVrd@magnolia> (raw) In-Reply-To: <87r14ffivd.fsf@oldenburg.str.redhat.com> 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 >
WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <djwong@kernel.org> To: Florian Weimer <fweimer@redhat.com> Cc: linux-xfs@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Eric Biggers <ebiggers@kernel.org>, Keith Busch <kbusch@kernel.org>, linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [f2fs-dev] [RFC PATCH v2 1/7] statx: add I/O alignment information Date: Fri, 27 May 2022 09:22:54 -0700 [thread overview] Message-ID: <YpD63ocQmmgpZVrd@magnolia> (raw) In-Reply-To: <87r14ffivd.fsf@oldenburg.str.redhat.com> 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 > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2022-05-27 16:23 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-18 23:50 [RFC PATCH v2 0/7] make statx() return I/O alignment information Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers 2022-05-18 23:50 ` [RFC PATCH v2 1/7] statx: add " Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers 2022-05-19 7:05 ` Christoph Hellwig 2022-05-19 7:05 ` [f2fs-dev] " Christoph Hellwig 2022-05-19 23:06 ` Darrick J. Wong 2022-05-19 23:06 ` [f2fs-dev] " Darrick J. Wong 2022-05-20 3:27 ` Dave Chinner 2022-05-20 3:27 ` [f2fs-dev] " Dave Chinner 2022-06-14 5:25 ` Eric Biggers 2022-06-14 5:25 ` [f2fs-dev] " Eric Biggers 2022-06-15 13:12 ` Christoph Hellwig 2022-06-15 13:12 ` [f2fs-dev] " Christoph Hellwig 2022-06-16 0:04 ` Eric Biggers 2022-06-16 0:04 ` [f2fs-dev] " Eric Biggers 2022-06-16 6:07 ` Christoph Hellwig 2022-06-16 6:07 ` [f2fs-dev] " Christoph Hellwig 2022-06-16 6:19 ` Eric Biggers 2022-06-16 6:19 ` [f2fs-dev] " Eric Biggers 2022-06-16 6:29 ` Christoph Hellwig 2022-06-16 6:29 ` [f2fs-dev] " Christoph Hellwig 2022-05-20 6:30 ` Eric Biggers 2022-05-20 6:30 ` [f2fs-dev] " Eric Biggers 2022-05-20 11:52 ` Christian Brauner 2022-05-20 11:52 ` [f2fs-dev] " Christian Brauner 2022-05-27 9:02 ` Florian Weimer 2022-05-27 9:02 ` Florian Weimer 2022-05-27 16:22 ` Darrick J. Wong [this message] 2022-05-27 16:22 ` [f2fs-dev] " Darrick J. Wong 2022-05-18 23:50 ` [RFC PATCH v2 2/7] fscrypt: change fscrypt_dio_supported() to prepare for STATX_IOALIGN Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers 2022-05-18 23:50 ` [RFC PATCH v2 3/7] ext4: support STATX_IOALIGN Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers 2022-05-18 23:50 ` [RFC PATCH v2 4/7] f2fs: move f2fs_force_buffered_io() into file.c Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers 2022-05-18 23:50 ` [RFC PATCH v2 5/7] f2fs: don't allow DIO reads but not DIO writes Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers 2022-05-18 23:50 ` [RFC PATCH v2 6/7] f2fs: simplify f2fs_force_buffered_io() Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers 2022-05-18 23:50 ` [RFC PATCH v2 7/7] f2fs: support STATX_IOALIGN Eric Biggers 2022-05-18 23:50 ` [f2fs-dev] " Eric Biggers
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YpD63ocQmmgpZVrd@magnolia \ --to=djwong@kernel.org \ --cc=ebiggers@kernel.org \ --cc=fweimer@redhat.com \ --cc=kbusch@kernel.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-block@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.