| Message ID | 20221122021536.1629178-1-drosen@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | FUSE BPF: A Stacked Filesystem Extension for FUSE | expand |
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.
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.
On 11/22/22 21:56, Daniel Rosenberg wrote: > 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. Here is a branch of xfstests that should work with fuse and should not run "rm -fr /" (we are going to give it more testing this week). https://github.com/hbirth/xfstests Bernd
On Tue, Nov 22, 2022 at 11:23 PM Bernd Schubert <bernd.schubert@fastmail.fm> wrote: > > > > On 11/22/22 21:56, Daniel Rosenberg wrote: > > 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. > > > Here is a branch of xfstests that should work with fuse and should not > run "rm -fr /" (we are going to give it more testing this week). > > https://github.com/hbirth/xfstests > > Bernd, Daniel, Vivek, Did you see LSFMMBPF 2023 CFP [1]? Did you consider requesting an invitation? I think it could be a good opportunity to sit in a room and discuss the roadmap of "FUSE2" with all the developers involved. I am on the program committee for the Filesystem track, and I encourage you to request an invite if you are interested to attend and/or nominate other developers that you think will be valuable for this discussion. Thanks, Amir. [1] https://lore.kernel.org/linux-fsdevel/Y9qBs82f94aV4%2F78@localhost.localdomain/
On 2/2/23 09:47, Amir Goldstein wrote: > On Tue, Nov 22, 2022 at 11:23 PM Bernd Schubert > <bernd.schubert@fastmail.fm> wrote: >> >> >> >> On 11/22/22 21:56, Daniel Rosenberg wrote: >>> 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. >> >> >> Here is a branch of xfstests that should work with fuse and should not >> run "rm -fr /" (we are going to give it more testing this week). >> >> https://github.com/hbirth/xfstests >> >> > > Bernd, Daniel, Vivek, > > Did you see LSFMMBPF 2023 CFP [1]? > > Did you consider requesting an invitation? > I think it could be a good opportunity to sit in a room and discuss the > roadmap of "FUSE2" with all the developers involved. > > I am on the program committee for the Filesystem track, and I encourage > you to request an invite if you are interested to attend and/or nominate > other developers that you think will be valuable for this discussion. > > Thanks, > Amir. > > [1] https://lore.kernel.org/linux-fsdevel/Y9qBs82f94aV4%2F78@localhost.localdomain/ Thanks a lot Amir, I'm going to send out an invitation tomorrow. Maybe Nikolaus as libfuse maintainer could also attend? Thanks, Bernd
> > Bernd, Daniel, Vivek, > > > > Did you see LSFMMBPF 2023 CFP [1]? > > > > Did you consider requesting an invitation? > > I think it could be a good opportunity to sit in a room and discuss the > > roadmap of "FUSE2" with all the developers involved. > > > > I am on the program committee for the Filesystem track, and I encourage > > you to request an invite if you are interested to attend and/or nominate > > other developers that you think will be valuable for this discussion. > > > > Thanks, > > Amir. > > > > [1] https://lore.kernel.org/linux-fsdevel/Y9qBs82f94aV4%2F78@localhost.localdomain/ > > > Thanks a lot Amir, I'm going to send out an invitation tomorrow. Maybe > Nikolaus as libfuse maintainer could also attend? > Since this summit is about kernel filesystem development, I am not sure on-prem attendance will be the best option for Nikolaus as we do have a quota for on-prem attendees, but we should have an option for connecting specific attendees remotely for specific sessions, so that could be great. Two more notes: 1. We realize that companies are going through economic changes and that this may not be the best time to request travel approval or to be able to get it. This should not stop you from requesting to attend! Worse case, you can attend remotely. It is not the same experience, but it is better than not attending at all if you have something to contribute to the discussion. 2. Bernd, I think you have some interesting WIP on "FUSE2" that the majority of fs developers are not aware of. It would be great if you can follow the instructions in CFP and also post a TOPIC suggestion to fsdevel, to get the discussion started ahead of the summit. Daniel, same request for FUSE BFP. The TOPIC suggestion should highlight the remaining open questions about design and API, which may be good to discuss in this forum. Please do not be intimidated by suggesting a TOPIC, you don't need to prepare any slides if you do not want to, nor to submit an abstract or anything of that sort. Thanks, Amir.
On Fri, 3 Feb 2023 at 12:43, Amir Goldstein <amir73il@gmail.com> wrote: > > Thanks a lot Amir, I'm going to send out an invitation tomorrow. Maybe > > Nikolaus as libfuse maintainer could also attend? > > > > Since this summit is about kernel filesystem development, I am not sure > on-prem attendance will be the best option for Nikolaus as we do have > a quota for > on-prem attendees, but we should have an option for connecting specific > attendees remotely for specific sessions, so that could be great. Not sure. I think including non-kernel people might be beneficial to the whole fs development community. Not saying LSF is the best place, but it's certainly a possibility. Nikolaus, I don't even know where you're located. Do you think it would make sense for you to attend? Thanks, Miklos
On Fri, 10 Feb 2023, at 09:38, Miklos Szeredi wrote: > On Fri, 3 Feb 2023 at 12:43, Amir Goldstein <amir73il@gmail.com> wrote: > >> > Thanks a lot Amir, I'm going to send out an invitation tomorrow. Maybe >> > Nikolaus as libfuse maintainer could also attend? >> > >> >> Since this summit is about kernel filesystem development, I am not sure >> on-prem attendance will be the best option for Nikolaus as we do have >> a quota for >> on-prem attendees, but we should have an option for connecting specific >> attendees remotely for specific sessions, so that could be great. > > Not sure. I think including non-kernel people might be beneficial to > the whole fs development community. Not saying LSF is the best place, > but it's certainly a possibility. > > Nikolaus, I don't even know where you're located. Do you think it > would make sense for you to attend? Hi folks, I'm located in London. I've never been at LHS, so it's hard for me to tell if I'd be useful there or not. If there's interest, then I would make an effort to attend. Are we talking about the event in Vancouver on May 8th? Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On Fri, 10 Feb 2023 at 10:42, Nikolaus Rath <nikolaus@rath.org> wrote: > > On Fri, 10 Feb 2023, at 09:38, Miklos Szeredi wrote: > > On Fri, 3 Feb 2023 at 12:43, Amir Goldstein <amir73il@gmail.com> wrote: > > > >> > Thanks a lot Amir, I'm going to send out an invitation tomorrow. Maybe > >> > Nikolaus as libfuse maintainer could also attend? > >> > > >> > >> Since this summit is about kernel filesystem development, I am not sure > >> on-prem attendance will be the best option for Nikolaus as we do have > >> a quota for > >> on-prem attendees, but we should have an option for connecting specific > >> attendees remotely for specific sessions, so that could be great. > > > > Not sure. I think including non-kernel people might be beneficial to > > the whole fs development community. Not saying LSF is the best place, > > but it's certainly a possibility. > > > > Nikolaus, I don't even know where you're located. Do you think it > > would make sense for you to attend? > > Hi folks, > > I'm located in London. > > I've never been at LHS, so it's hard for me to tell if I'd be useful there or not. If there's interest, then I would make an effort to attend. > > Are we talking about the event in Vancouver on May 8th? Yes, that's the one. I'd certainly think it would be useful, since there will be people with interest in fuse filesystems and hashing out the development direction involves libfuse as well. Here's the CFP and attendance request if you are interested: https://events.linuxfoundation.org/lsfmm/program/cfp/ Thanks, Miklos
Hi folks, I've looked into this in more detail. I wouldn't be able to get the travel funded by my employer, and I don't think I'm a suitable recipient for the Linux Foundation's travel fund. Therefore, I think it would make more sense for me to attend potentially relevant sessions remotely. If there's anything I need to do for that, please let me know. Otherwise I'll assume that at some point I'll get a meeting invite from someone :-). If there's a way to schedule these sessions in a Europe-friendly time that would be much appreciated! Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« On Fri, 10 Feb 2023, at 10:53, Miklos Szeredi wrote: > On Fri, 10 Feb 2023 at 10:42, Nikolaus Rath <nikolaus@rath.org> wrote: >> >> On Fri, 10 Feb 2023, at 09:38, Miklos Szeredi wrote: >> > On Fri, 3 Feb 2023 at 12:43, Amir Goldstein <amir73il@gmail.com> wrote: >> > >> >> > Thanks a lot Amir, I'm going to send out an invitation tomorrow. Maybe >> >> > Nikolaus as libfuse maintainer could also attend? >> >> > >> >> >> >> Since this summit is about kernel filesystem development, I am not sure >> >> on-prem attendance will be the best option for Nikolaus as we do have >> >> a quota for >> >> on-prem attendees, but we should have an option for connecting specific >> >> attendees remotely for specific sessions, so that could be great. >> > >> > Not sure. I think including non-kernel people might be beneficial to >> > the whole fs development community. Not saying LSF is the best place, >> > but it's certainly a possibility. >> > >> > Nikolaus, I don't even know where you're located. Do you think it >> > would make sense for you to attend? >> >> Hi folks, >> >> I'm located in London. >> >> I've never been at LHS, so it's hard for me to tell if I'd be useful there or not. If there's interest, then I would make an effort to attend. >> >> Are we talking about the event in Vancouver on May 8th? > > Yes, that's the one. > > I'd certainly think it would be useful, since there will be people > with interest in fuse filesystems and hashing out the development > direction involves libfuse as well. > > Here's the CFP and attendance request if you are interested: > > https://events.linuxfoundation.org/lsfmm/program/cfp/ > > Thanks, > Miklos
On Tue, Feb 14, 2023 at 6:53 PM Nikolaus Rath <nikolaus@rath.org> wrote: > > Hi folks, > > I've looked into this in more detail. > > I wouldn't be able to get the travel funded by my employer, and I don't think I'm a suitable recipient for the Linux Foundation's travel fund. Therefore, I think it would make more sense for me to attend potentially relevant sessions remotely. > > If there's anything I need to do for that, please let me know. Otherwise I'll assume that at some point I'll get a meeting invite from someone :-). > Please use the Form in the CFP link to request to attend and specify that you can only attend remotely. This will get you subscribed to information about relevant sessions and how to connect. > If there's a way to schedule these sessions in a Europe-friendly time that would be much appreciated! > Will do my best to take that into consideration :) Thanks, Amir. > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > > On Fri, 10 Feb 2023, at 10:53, Miklos Szeredi wrote: > > On Fri, 10 Feb 2023 at 10:42, Nikolaus Rath <nikolaus@rath.org> wrote: > >> > >> On Fri, 10 Feb 2023, at 09:38, Miklos Szeredi wrote: > >> > On Fri, 3 Feb 2023 at 12:43, Amir Goldstein <amir73il@gmail.com> wrote: > >> > > >> >> > Thanks a lot Amir, I'm going to send out an invitation tomorrow. Maybe > >> >> > Nikolaus as libfuse maintainer could also attend? > >> >> > > >> >> > >> >> Since this summit is about kernel filesystem development, I am not sure > >> >> on-prem attendance will be the best option for Nikolaus as we do have > >> >> a quota for > >> >> on-prem attendees, but we should have an option for connecting specific > >> >> attendees remotely for specific sessions, so that could be great. > >> > > >> > Not sure. I think including non-kernel people might be beneficial to > >> > the whole fs development community. Not saying LSF is the best place, > >> > but it's certainly a possibility. > >> > > >> > Nikolaus, I don't even know where you're located. Do you think it > >> > would make sense for you to attend? > >> > >> Hi folks, > >> > >> I'm located in London. > >> > >> I've never been at LHS, so it's hard for me to tell if I'd be useful there or not. If there's interest, then I would make an effort to attend. > >> > >> Are we talking about the event in Vancouver on May 8th? > > > > Yes, that's the one. > > > > I'd certainly think it would be useful, since there will be people > > with interest in fuse filesystems and hashing out the development > > direction involves libfuse as well. > > > > Here's the CFP and attendance request if you are interested: > > > > https://events.linuxfoundation.org/lsfmm/program/cfp/ > > > > Thanks, > > Miklos