On Fri, Aug 19, 2022 at 05:06:06PM -0700, Jaegeuk Kim wrote: > On 08/15, Eric Biggers wrote: > > On Sat, Jul 30, 2022 at 08:08:26PM -0700, Jaegeuk Kim wrote: > > > On 07/25, Eric Biggers wrote: > > > > On Sat, Jul 23, 2022 at 07:01:59PM -0700, Jaegeuk Kim wrote: > > > > > On 07/22, Eric Biggers wrote: > > > > > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > > > > > > > > > Currently, if an f2fs filesystem is mounted with the mode=lfs and > > > > > > io_bits mount options, DIO reads are allowed but DIO writes are not. > > > > > > Allowing DIO reads but not DIO writes is an unusual restriction, which > > > > > > is likely to be surprising to applications, namely any application that > > > > > > both reads and writes from a file (using O_DIRECT). This behavior is > > > > > > also incompatible with the proposed STATX_DIOALIGN extension to statx. > > > > > > Given this, let's drop the support for DIO reads in this configuration. > > > > > > > > > > IIRC, we allowed DIO reads since applications complained a lower performance. > > > > > So, I'm afraid this change will make another confusion to users. Could > > > > > you please apply the new bahavior only for STATX_DIOALIGN? > > > > > > > > > > > > > Well, the issue is that the proposed STATX_DIOALIGN fields cannot represent this > > > > weird case where DIO reads are allowed but not DIO writes. So the question is > > > > whether this case actually matters, in which case we should make STATX_DIOALIGN > > > > distinguish between DIO reads and DIO writes, or whether it's some odd edge case > > > > that doesn't really matter, in which case we could just fix it or make > > > > STATX_DIOALIGN report that DIO is unsupported. I was hoping that you had some > > > > insight here. What sort of applications want DIO reads but not DIO writes? > > > > Is this common at all? > > > > > > I think there's no specific application to use the LFS mode at this > > > moment, but I'd like to allow DIO read for zoned device which will be > > > used for Android devices. > > > > > > > So if the zoned device feature becomes widely adopted, then STATX_DIOALIGN will > > be useless on all Android devices? That sounds undesirable. > > Do you have a plan to adopt STATX_DIOALIGN in android? Nothing specific, but statx() is among the system calls that are supported by Android's libc and that apps are allowed to use. So STATX_DIOALIGN would become available as well. I'd prefer if it actually worked properly if apps, or Android system components, do actually try to use it (or need to use it)... > > What we need to do is make a decision about whether this means we should build > > in a stx_dio_direction field (indicating no support / readonly support / > > writeonly support / readwrite support) into the API from the beginning. If we > > don't do that, then I don't think we could simply add such a field later, as the > > statx_dio_*_align fields will have already been assigned their meaning. I think > > we'd instead have to "duplicate" the API, with STATX_DIOROALIGN and > > statx_dio_ro_*_align fields. That seems uglier than building a directional > > indicator into the API from the beginning. On the other hand, requiring all > > programs to check stx_dio_direction would add complexity to using the API. > > > > Any thoughts on this? > > I haven't seen the details of the implementation tho, why not supporting it > only if filesystem has the same DIO RW policy? As I've mentioned, we could of course make STATX_DIOALIGN report that DIO is unsupported when the DIO support is read-only. The thing that confuses me based on the responses so far is that there seem to be two camps of people: (1) people who really want STATX_DIOALIGN, and who don't think that read-only DIO support should exist so they don't want STATX_DIOALIGN to support it; and (2) people who feel that read-only DIO support is perfectly reasonable and useful, and who don't care whether STATX_DIOALIGN supports it because they don't care about STATX_DIOALIGN in the first place. While both camps seem to agree that STATX_DIOALIGN shouldn't support read-only DIO, it is for totally contradictory reasons, so it's not very convincing. We should ensure that we have rock-solid reasoning before committing to a new UAPI that will have to be permanently supported... - Eric
