On 5/15/23 22:16, Nikolaus Rath wrote:
On May 15 2023, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
On Mon, May 15, 2023 at 10:29 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
On Fri, 12 May 2023 at 21:37, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
I was waiting for LSFMM to see if and how FUSE-BPF intends to
address the highest value use case of read/write passthrough.
From what I've seen, you are still taking a very broad approach of
all-or-nothing which still has a lot of core design issues to address,
while these old patches already address the most important use case
of read/write passthrough of fd without any of the core issues
(credentials, hidden fds).
As far as I can tell, this old implementation is mostly independent of your
lookup based approach - they share the low level read/write passthrough
functions but not much more than that, so merging them should not be
a blocker to your efforts in the longer run.
Please correct me if I am wrong.
As things stand, I intend to re-post these old patches with mandatory
FOPEN_PASSTHROUGH_AUTOCLOSE to eliminate the open
questions about managing mappings.
Miklos, please stop me if I missed something and if you do not
think that these two approaches are independent.
Do you mean that the BPF patches should use their own passthrough mechanism?
I think it would be better if we could agree on a common interface for
passthough (or per Paul's suggestion: backing) mechanism.
Well, not exactly different.
With BFP patches, if you have a backing inode that was established during
LOOKUP with rules to do passthrough for open(), you'd get a backing file and
that backing file would be used to passthrough read/write.
FOPEN_PASSTHROUGH is another way to configure passthrough read/write
to a backing file that is controlled by the server per open fd instead of by BFP
for every open of the backing inode.
Obviously, both methods would use the same backing_file field and
same read/write passthrough methods regardless of how the backing file
was setup.
Obviously, the BFP patches will not use the same ioctl to setup passthrough
(and/or BPF program) to a backing inode, but I don't think that matters much.
When we settle on ioctls for setting up backing inodes, we can also add new
ioctls for setting up backing file with optional BPF program.
I don't see any reason to make the first ioctl more complicated than this:
struct fuse_passthrough_out {
uint32_t fd;
/* For future implementation */
uint32_t len;
void *vec;
};
One advantage with starting with FOPEN_PASSTHROUGH, besides
dealing with the highest priority performance issue, is how it deals with
resource limits on open files.
One thing that struck me when we discussed FUSE-BPF at LSF was that from
a userspace point of view, FUSE-BPF presents an almost completely
different API than traditional FUSE (at least in its current form).
As long as there is no support for falling back to standard FUSE
callbacks, using FUSE-BPF means that most of the existing API no longer
works, and instead there is a large new API surface that doesn't work in
standard FUSE (the pre-filter and post-filter callbacks for each
operation).
I think this means that FUSE-BPF file systems won't work with FUSE, and
FUSE filesystems won't work with FUSE-BPF.
Is that so? I think found some incompatibilities in the patches (need to
double check), but doesn't it just do normal fuse operations and then
replies with an ioctl to do passthrough? BPF is used for additional
filtering, that would have to be done otherwise in userspace.
Really difficult in the current patch set and data structures is to see
what is actually BPF and what is passthrough.
Thanks,
Bernd
