On Fri, May 19, 2023 at 3:57 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> Miklos,
>
> This patch set addresses your review feedback on Alesio's V12 patch set
> from 2021 [1] as well as other bugs that I have found since.
> This patch set uses refcounted backing files as we discussed recently [2].
>
> I am posting this for several possible outcomes:
>
> 1. Either FUSE-BPF develpers can use this as a reference implementation
> for their 1st phase of "backing file passthrough"
> 2. Or they can tell me which API changes need to made to this patch set
> so the API is flexible enough to extend to "backing inode passthrough"
> and to "BPF filters" later on
> 3. We find there is little overlap in the APIs and merge this as is
>
> These patches are available on github [3] along with libfuse patches [4].
> I tested them by running xfstests (./check -fuse -g quick.rw) with latest
> libfuse xfstest support.
>
> Without FOPEN_PASSTHROUGH, one test in this group fails (generic/451)
> which tests mixed buffered/aio writes.
> With FOPEN_PASSTHROUGH, this test also passes.
>
> This revision does not set any limitations on the number of backing files
> that can be mapped by the server. I considered several ways to address
> this and decided to try a different approach.
>
> Patch 10 (with matching libfuse patch) is an RFC patch for an alternative
> API approach. Please see my comments on that patch.
>
Miklos,
I wanted to set expectations w.r.t this patch set and the passthrough
feature development in general.
So far I've seen comments from you up to path 5/10, so I assume you
did not get up to RFC patch 10/10.
The comments about adding max stack depth to protocol and about
refactoring overlayfs common code are easy to do.
However, I feel that there are still open core design questions that need
to be spelled out, before we continue.
Do you find the following acceptable for first implementation, or do you
think that those issues must be addressed before merging anything?
1. No lsof visibility of backing files (if server closes them)
2. Derived backing files resource limit (cannot grow beyond nr of fuse files)
3. No data consistency guaranty between different fd to the same inode
(i.e. backing is per fd not per inode)
Depending on your answers, I will decide if I have the bandwidth to carry
this patch set to the finish line or wait for the Android team to post a more
comprehensive patch set that deals with all of the above.
Thanks,
Amir.
