Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <EC8AF6A7-9A90-4C21-8A1F-4AE936776876@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_DB83B9B8-69A7-4FD9-B14D-F8B77FC7C0F2";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH v4 6/9] f2fs: don't allow DIO reads but not DIO writes
Date:   Mon, 25 Jul 2022 17:58:31 -0600
In-Reply-To: <Yt7dCcG0ns85QqJe@sol.localdomain>
Cc:     Jaegeuk Kim <jaegeuk@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>
To:     Eric Biggers <ebiggers@kernel.org>
References: <20220722071228.146690-1-ebiggers@kernel.org>
 <20220722071228.146690-7-ebiggers@kernel.org> <YtyoF89iOg8gs7hj@google.com>
 <Yt7dCcG0ns85QqJe@sol.localdomain>
Precedence: bulk


--Apple-Mail=_DB83B9B8-69A7-4FD9-B14D-F8B77FC7C0F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jul 25, 2022, at 12:12 PM, Eric Biggers <ebiggers@kernel.org> wrote:
>=20
> On Sat, Jul 23, 2022 at 07:01:59PM -0700, Jaegeuk Kim wrote:
>> On 07/22, Eric Biggers wrote:
>>> From: Eric Biggers <ebiggers@google.com>
>>>=20
>>> Currently, if an f2fs filesystem is mounted with the mode=3Dlfs 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.
>>=20
>> 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?
>>=20
>=20
> 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 don't think this is f2fs related, but some backup applications I'm =
aware
of are using DIO reads to avoid polluting the page cache when reading =
large
numbers of files. They don't care about DIO writes, since that is =
usually
slower than async writes due to the sync before returning from the =
syscall.

Also, IMHO it doesn't make sense to remove useful functionality because =
the
new STATX_DIOALIGN fields don't handle this.  At worst the application =
will
still get an error when trying a DIO write, but in most cases they will
not use the brand new STATX call in the first place, and if this is =
documented
then any application that starts to use it should be able to handle it.

Cheers, Andreas


--Apple-Mail=_DB83B9B8-69A7-4FD9-B14D-F8B77FC7C0F2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmLfLigACgkQcqXauRfM
H+DIjBAAuhcCUrRZxLbIIbGQiYg9WA8Kq1A3wSBPDzMet5t78gjiKUo6y+RE2w0X
O2Be8DY9X8x4OIpbD4jiFAe7TiVDAHAYjjrzKFMykU63wB4nJELcIZrqELT/O1qg
9Zi1+hqoXK+WcCcC8IEh52+ypABRczFIb9OF6RPR450wAxc+0x7lXfyZ/TzBcRyl
+NeWbyLAQfW+VRViN/re9tlticLobDklbfgNC0rNuhp1CawlnMVsqWSxx/F9WT3s
RjdsJ8hzDqLEpPv6Sgd30T9U4UaoLEpRe36CMuT4/SYx6h6SR2Kv61+Z3IihAp41
utLypsHnpswfLjF3KmxusOMLZGmCG1EFazn/gMi6WuccfBaI+m7OXeUvvlLGnzn4
9RJWpVHy3TVTWdikFE/LVP9L7D8rj2jos9UVpFE8QUO2Gu1NNf6C5lIg3iXlvcvn
uxuqCpYcPCCwYosLSNcpi9tNW/p3aS0WNNfGlqWfB8Au4S/91sMJsGKkON+jwsMs
cMiUECc+eFc7HuCrP80IW+N8asiaGrTWGrrg+EpxFtl12OzKyn4OnoY5NxWuLXLF
3lSS1IZWudfgO1TD/5sUmvsHtUS4Rd3akslKsAQyavGxszDWvxIGvU0kABSb8k1P
q3CXMHx8oG9FooyoP3FnfUzDrZXf40Sk28cCsqOa09926JUbhqY=
=zitC
-----END PGP SIGNATURE-----

--Apple-Mail=_DB83B9B8-69A7-4FD9-B14D-F8B77FC7C0F2--