Re: [PATCH v14 00/12] FUSE passthrough for file io

From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>,
	Daniel Rosenberg <drosen@google.com>,
	 Paul Lawrence <paullawrence@google.com>,
	Alessio Balsini <balsini@android.com>,
	 Christian Brauner <brauner@kernel.org>,
	fuse-devel@lists.sourceforge.net,  linux-fsdevel@vger.kernel.org,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH v14 00/12] FUSE passthrough for file io
Date: Wed, 1 Nov 2023 16:25:40 +0100	[thread overview]
Message-ID: <CAJfpegt3mEii075roOTk6RKeNKGc89pGMkWrvVM0uLyrpg7Ebg@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxja2G2M22bWSi_kDE2vdxs+sJ0ua9JgD-e7LEGsTcNGXw@mail.gmail.com>

On Wed, 1 Nov 2023 at 16:06, Amir Goldstein <amir73il@gmail.com> wrote:

> That would make sense if readdirplus request is sent to server
> in parallel to executing readdir passthrough and readdirplus
> response does the prepopulation asynchronously.

Yes, that's fine, and it might even make sense to do that regardless
of passthrough.  Readdirplus is similar to read-ahead in this regard.

> Are you also referring to mixing cached and uncached readdir?
> because that seems fine to me.

But is it really fine?  The server must be very careful to prevent
inconsistency between the cached and the uncached readdir, which could
lead to really surprising results.  I just see no point in caching if
the same result is available from a backing directory.

> I will try to add these rules to FOPEN_PASSTHROUGH:
> - ignore request on backing inode conflict
> - ignore request if inode is already open in caching mode
> - make FOPEN_PASSTHROUGH implicit if inode is already open
>   in passthrough *unless* file is open with FOPEN_DIRECT_IO

Sounds good.

There's still this case:

 - file is opened in non-passthrough caching mode, and is being read/written
 - at the same time the file is opened in passthrough mode

The proper thing would be to switch the first file to passthrough mode
while it's open.  It adds some complexity but I think it's worth it.

Thanks,
Miklos

>
> Thanks,
> Amir.