On Tue, Aug 29, 2023 at 9:14 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Tue, Jun 6, 2023 at 4:06 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > On Tue, 6 Jun 2023 at 13:19, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> > >
> > > On Tue, Jun 6, 2023 at 12:49 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> [...]
>
> > > > I'm not sure that the per-file part of this is necessary, doing
> > > > everything per-inode should be okay. What are the benefits?
> > > >
> > >
> > > I agree that semantics are simpler with per-inode.
> > > The only benefit I see to per-file is the lifetime of the mapping.
> > >
> > > It is very easy IMO to program with a mapping scope of
> > > open-to-close that is requested by FOPEN_PASSTHROUGH
> > > and FOPEN_PASSTHROUGH_AUTO_CLOSE.
> >
> > Right, and this case the resource limiting is also easy to think about.
> >
> > I'm not worried about consistency, fuse server can do whatever it
> > wants with the data anyway. I am worried about the visibility of the
> > mapping. One idea would be to create a kernel thread for each fuse sb
> > instance and install mapped files into that thread's file table. In
> > theory this should be trivial as the VFS has all the helpers that can
> > do this safely.
> >
>
> Sounds doable.
> I will look into this after I get the basics sorted out.
>
> > >
> > > I think if I can make this patch set work per-inode, the roadmap
> > > from here to FUSE-BPF would be much more clear.
> >
> > One advantage of per-inode non-autoclose would be that open could be
> > done without a roundtrip to the server. However the resource
> > limiting becomes harder to think about.
> >
> > So it might make sense to just create two separate modes:
> >
> > - per-open unmap-on-release (autoclose)
> > - per-inode unmap-on-forget (non-autoclose, mapping can be torn down
> > explicitly)
> >
>
Miklos,
I have a POC for the two modes above, see kernel patches [1] and
passthrough_hp example[2].
As far as I know, I addressed all your review comments on v13:
1. factor out common helpers from overlayfs
2. factor out ioctl helpers
3. per-file and per-inode backing file modes
4. optional auto close flag
Only thing not addressed yet is lsof-visibility of the backing files.
The first passthrough_hp commit:
- Enable passthrough mode for read/write operations
Is the original passthrough_hp POC of Alessio, which implements
the per-open unmap-on-release (autoclose), as the original POC did.
Unlike Alession's version, this implementation uses the explicit ioctl
flag FUSE_BACKING_MAP_ID to setup an "inode unbound" backing file
and the explicit open flag FOPEN_PASSTHROUGH_AUTO_CLOSE
to unmap the backing id, when the backing file is assigned to the fuse file.
FOPEN_PASSTHROUGH (without AUTO_CLOSE) would let the server
manage the backing ids, but that mode is not implemented in the example.
The seconds passthrough_hp commit:
- Enable passthrough of multiple fuse files to the same backing file
Maps all the rdonly FUSE files to the same "inode bound" backing
file that is setup on the first rdonly open of an inode.
The implementation uses the ioctl flag FUSE_BACKING_MAP_INODE
and the open flag FOPEN_PASSTHROUGH (AUTO_CLOSE not
supported in this mode).
The "inode bound" shared backing file is released of inode evict
of course, but the example explicitly unmaps the inode bound
backing file on close of the last open file of an inode.
Writable files still use the per-open unmap-on-release mode.
I ran this POC on fstests using the newly added support for
running fuse in fstests with a mount helper (one libfuse patch
in my branch improves the mount helper).
First I verified that the group -g quick.rw passes on baseline
passthrough_hp and then I tested with backing files enabled.
The tests found some failures with splice_{read/write}, so
I added support for splice_{read/write} to backing files and
then all the tests passed.
NOTE that if the FOPEN_PASSTHROUGH directive fails for
any reason, this will not fail the open - it will just open the file
without passthrough, and if a valid backing_id is provided
with FOPEN_PASSTHROUGH_AUTO_CLOSE, then the
backing file will be auto closed regardless if the open fails.
Please ACK this API design and then I will continue to clean up
the kernel patches and post them for review.
I still plan to:
1. Move more code into backing_file helpers (i.e. splice/mmap)
2. Install fds of backing files in kernel task file table
Please let me know if you have any comments so far and if
you want me to post the patches even without the kernel task,
as that may take me a bit longer to get to.
Thanks,
Amir.
[1] https://github.com/amir73il/linux/commits/fuse-backing-fd
[1] https://github.com/amir73il/libfuse/commits/fuse-backing-fd
