All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Rosenberg <drosen@google.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-unionfs@vger.kernel.org, bpf@vger.kernel.org,
	kernel-team@android.com
Subject: Re: [RFC PATCH v2 00/21] FUSE BPF: A Stacked Filesystem Extension for FUSE
Date: Tue, 22 Nov 2022 12:56:38 -0800	[thread overview]
Message-ID: <CA+PiJmRLTXfjJmgJm9VRBQeLVkWgaqSq0RMrRY1Vj7q6pV+omw@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxiyRxsZjkku_V2dBMvh1AGiKQx-iPjsD5tmGPv1PgJHvQ@mail.gmail.com>

I've been running the generic xfstests against it, with some
modifications to do things like mount/unmount the lower and upper fs
at once. Most of the failures I see there are related to missing
opcodes, like FUSE_SETLK, FUSE_GETLK, and FUSE_IOCTL. The main failure
I have been seeing is generic/126, which is happening due to some
additional checks we're doing in fuse_open_backing. I figured at some
point we'd add some tests into libfuse, and that sounds like a good
place to start.

On Tue, Nov 22, 2022 at 3:13 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Tue, Nov 22, 2022 at 4:15 AM Daniel Rosenberg <drosen@google.com> wrote:
> >
> > These patches extend FUSE to be able to act as a stacked filesystem. This
> > allows pure passthrough, where the fuse file system simply reflects the lower
> > filesystem, and also allows optional pre and post filtering in BPF and/or the
> > userspace daemon as needed. This can dramatically reduce or even eliminate
> > transitions to and from userspace.
> >
> > For this patch set, I have removed the code related to the bpf side of things
> > since that is undergoing some large reworks to get it in line with the more
> > recent BPF developements. This set of patches implements direct passthrough to
> > the lower filesystem with no alteration. Looking at the v1 code should give a
> > pretty good idea of what the general shape of the bpf calls will look like.
> > Without the bpf side, it's like a less efficient bind mount. Not very useful
> > on its own, but still useful to get eyes on it since the backing calls will be
> > larglely the same when bpf is in the mix.
> >
> > This changes the format of adding a backing file/bpf slightly from v1. It's now
> > a bit more modular. You add a block of data at the end of a lookup response to
> > give the bpf fd and backing id, but there is now a type header to both blocks,
> > and a reserved value for future additions. In the future, we may allow for
> > multiple bpfs or backing files, and this will allow us to extend it without any
> > UAPI breaking changes. Multiple BPFs would be useful for combining fuse-bpf
> > implementations without needing to manually combine bpf fragments. Multiple
> > backing files would allow implementing things like a limited overlayfs.
> > In this patch set, this is only a single block, with only backing supported,
> > although I've left the definitions reflecting the BPF case as well.
> > For bpf, the plan is to have two blocks, with the bpf one coming first.
> > Any further extensions are currently just speculative.
> >
> > You can run this without needing to set up a userspace daemon by adding these
> > mount options: root_dir=[fd],no_daemon where fd is an open file descriptor
> > pointing to the folder you'd like to use as the root directory. The fd can be
> > immediately closed after mounting. This is useful for running various fs tests.
> >
>
> Which tests did you run?
>
> My recommendation (if you haven't done that already):
> Add a variant to libfuse test_passthrough (test_examples.py):
> @pytest.mark.parametrize("name", ('passthrough', 'passthrough_plus',
>                            'passthrough_fh', 'passthrough_ll',
> 'passthrough_bpf'))
>
> and compose the no_daemon cmdline for the 'passthrough_bpf' mount.
>
> This gives pretty good basic test coverage for FUSE passthrough operations.
>
> I've extended test_passthrough_hp() for my libfuse_passthrough patches [1],
> but it's the same principle.
>
> Thanks,
> Amir.
>
> [1] https://github.com/amir73il/libfuse/commits/fuse_passthrough
> * 'passthrough_module' uses 'libfuse_passthrough' which enables
>    Allesio's FUSE_DEV_IOC_PASSTHROUGH_OPEN by default.

  reply	other threads:[~2022-11-22 20:57 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22  2:15 [RFC PATCH v2 00/21] FUSE BPF: A Stacked Filesystem Extension for FUSE Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 01/21] fs: Generic function to convert iocb to rw flags Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 02/21] fuse-bpf: Update fuse side uapi Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 03/21] fuse-bpf: Prepare for fuse-bpf patch Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 04/21] fuse: Add fuse-bpf, a stacked fs extension for FUSE Daniel Rosenberg
2022-11-22 10:19   ` Amir Goldstein
2022-11-22 21:23     ` Daniel Rosenberg
2022-11-23 23:31   ` kernel test robot
2022-11-22  2:15 ` [RFC PATCH v2 05/21] fuse-bpf: Add ioctl interface for /dev/fuse Daniel Rosenberg
2022-11-22 14:20   ` kernel test robot
2022-11-22  2:15 ` [RFC PATCH v2 06/21] fuse-bpf: Don't support export_operations Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 07/21] fuse-bpf: Add support for FUSE_ACCESS Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 08/21] fuse-bpf: Partially add mapping support Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 09/21] fuse-bpf: Add lseek support Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 10/21] fuse-bpf: Add support for fallocate Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 11/21] fuse-bpf: Support file/dir open/close Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 12/21] fuse-bpf: Support mknod/unlink/mkdir/rmdir Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 13/21] fuse-bpf: Add support for read/write iter Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 14/21] fuse-bpf: support FUSE_READDIR Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 15/21] fuse-bpf: Add support for sync operations Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 16/21] fuse-bpf: Add Rename support Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 17/21] fuse-bpf: Add attr support Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 18/21] fuse-bpf: Add support for FUSE_COPY_FILE_RANGE Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 19/21] fuse-bpf: Add xattr support Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 20/21] fuse-bpf: Add symlink/link support Daniel Rosenberg
2022-11-22  2:15 ` [RFC PATCH v2 21/21] fuse-bpf: allow mounting with no userspace daemon Daniel Rosenberg
2022-11-22 11:13 ` [RFC PATCH v2 00/21] FUSE BPF: A Stacked Filesystem Extension for FUSE Amir Goldstein
2022-11-22 20:56   ` Daniel Rosenberg [this message]
2022-11-22 21:23     ` Bernd Schubert
2023-02-02  8:47       ` Amir Goldstein
2023-02-02 22:01         ` Bernd Schubert
2023-02-03 11:43           ` Amir Goldstein
2023-02-10  9:38             ` Miklos Szeredi
2023-02-10  9:41               ` Nikolaus Rath
2023-02-10 10:53                 ` Miklos Szeredi
2023-02-14 16:53                   ` Attending LFS (was: [RFC PATCH v2 00/21] FUSE BPF: A Stacked Filesystem Extension for FUSE) Nikolaus Rath
2023-02-14 18:04                     ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+PiJmRLTXfjJmgJm9VRBQeLVkWgaqSq0RMrRY1Vj7q6pV+omw@mail.gmail.com \
    --to=drosen@google.com \
    --cc=amir73il@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.