On Fri, Apr 10, 2026 at 11:38 AM John Groves <[email protected]> wrote: > > On 26/04/10 05:24PM, Bernd Schubert wrote: > > > > > > On 4/10/26 16:46, John Groves wrote: > > > On 26/04/06 10:43AM, Joanne Koong wrote: > > >> On Tue, Mar 31, 2026 at 5:37 AM John Groves <[email protected]> wrote: > > >>> > > >>> From: John Groves <[email protected]> > > >>> > > >>> NOTE: this series depends on the famfs dax series in Ira's > > >>> for-7.1/dax-famfs > > >>> branch [0] > > >>> > > >>> Description: > > >>> > > >>> This patch series introduces famfs into the fuse file system framework. > > >>> Famfs depends on the bundled dax patch set. > > >>> > > >>> The famfs user space code can be found at [1]. > > >>> > > >>> John Groves (10): > > >>> famfs_fuse: Update macro s/FUSE_IS_DAX/FUSE_IS_VIRTIO_DAX/ > > >>> famfs_fuse: Basic fuse kernel ABI enablement for famfs > > >>> famfs_fuse: Plumb the GET_FMAP message/response > > >>> famfs_fuse: Create files with famfs fmaps > > >>> famfs_fuse: GET_DAXDEV message and daxdev_table > > >>> famfs_fuse: Plumb dax iomap and fuse read/write/mmap > > >>> famfs_fuse: Add holder_operations for dax notify_failure() > > >>> famfs_fuse: Add DAX address_space_operations with noop_dirty_folio > > >>> famfs_fuse: Add famfs fmap metadata documentation > > >>> famfs_fuse: Add documentation > > >>> > > >>> Documentation/filesystems/famfs.rst | 142 ++++ > > >>> Documentation/filesystems/index.rst | 1 + > > >>> MAINTAINERS | 10 + > > >>> fs/fuse/Kconfig | 13 + > > >>> fs/fuse/Makefile | 1 + > > >>> fs/fuse/dir.c | 2 +- > > >>> fs/fuse/famfs.c | 1180 +++++++++++++++++++++++++++ > > >>> fs/fuse/famfs_kfmap.h | 167 ++++ > > >>> fs/fuse/file.c | 45 +- > > >>> fs/fuse/fuse_i.h | 116 ++- > > >>> fs/fuse/inode.c | 35 +- > > >>> fs/fuse/iomode.c | 2 +- > > >>> fs/namei.c | 1 + > > >>> include/uapi/linux/fuse.h | 88 ++ > > >>> 14 files changed, 1790 insertions(+), 13 deletions(-) > > >>> create mode 100644 Documentation/filesystems/famfs.rst > > >>> create mode 100644 fs/fuse/famfs.c > > >>> create mode 100644 fs/fuse/famfs_kfmap.h > > >>> > > >>> > > >>> base-commit: 2ae624d5a555d47a735fb3f4d850402859a4db77 > > >>> -- > > >>> 2.53.0 > > >>> > > >> > > >> Hi John, > > >> > > >> I’m curious to hear your thoughts on whether you think it makes sense > > >> for the famfs-specific logic in this series to be moved to a bpf > > >> program that goes through a generic fuse iomap dax layer. > > >> > > >> Based on [1], this gives feature-parity with the famfs logic in this > > >> series. In my opinion, having famfs go through a generic fuse iomap > > >> dax layer makes the fuse kernel code more extensible for future > > >> servers that will also want to use dax iomap, and keeps the fuse code > > >> cleaner by not having famfs-specific logic hardcoded in and having to > > >> introduce new fuse uapis for something famfs-specific. In my > > >> understanding of it, fuse is meant to be generic and it feels like > > >> adding server-specific logic goes against that design philosophy and > > >> sets a precedent for other servers wanting similar special-casing in > > >> the future. I'd like to explore whether the bpf and generic fuse iomap > > >> dax layer approach can preserve that philosophy while still giving > > >> famfs the flexibility it needs. > > >> > > >> I think moving the famfs logic to bpf benefits famfs as well: > > >> - Instead of needing to issue a FUSE_GET_FMAP request after a file is > > >> opened, the server can directly populate the metadata map from > > >> userspace with the mapping info when it processes the FUSE_OPEN > > >> request, which gets rid of the roundtrip cost > > >> - The server can dynamically update the metadata / bpf maps during > > >> runtime from userspace if any mapping info needs to change > > >> - Future code changes / updates for famfs are all server-side and can > > >> be deployed immediately instead of needing to go through the upstream > > >> kernel mailing list process > > >> - Famfs updates / new releases can ship independently of kernel releases > > >> > > >> I'd appreciate the chance to discuss tradeoffs or if you'd rather > > >> discuss this at the fuse BoF at lsf, that sounds great too. > > >> > > >> Thanks, > > >> Joanne > > >> > > > > > > Hi Joanne, > > > > > > I'm definitely up for discussing it, and talking before LSFMM would be > > > good because then I'd have some time to think about before we discuss > > > at LSFMM. > > > > > > I have not had a chance to really study this, in part since I've never > > > even > > > written a "hello world" BPF program. > > > > > > I'll ping off-list about times to talk. > > > > > > However... > > > > > > I would object vehemently to this sort of re-write prior to going > > > upstream, > > > as would users and vendors who need famfs now that the memory products it > > > enables have started to ship. > > > > > > This work started over 3 years ago, initial patches over 2 years ago, > > > community decision that it should go into fuse 2 years ago, first fuse > > > patches a year ago. > > > > > > This implementation is pretty much exactly in line with > > > expectation-setting > > > starting two years ago. Famfs is a complicated orchestration between dax, > > > fuse, ndctl (for daxctl), libfuse and the extensive famfs user space. > > > Famfs > > > has a fairly small kernel footprint, but its user space is much larger. > > > This could set it back a year if we re-write now.
Hi John, Thanks for your email. I totally understand where you're coming from - having already spent a year reworking your initial patches to go through fuse, the last thing needed is another change. Bernd brought up the question of whether after merging this series in, it could then be converted to bpf. If this is an option on the table, I'd say we should just merge your series now and do any conversions later, but I don't think this is possible. As I understand it, the policy is that all kernel releases must be backwards-compatible, which means once this series lands, the famfs code will live within fuse permanently. I definitely do not want to see famfs set back by yet another year. With the bpf approach, I don't think it requires another rewrite. I'm not sure if you had the chance to look at my email from February [1], but it contains the prototype code for the generic fuse iomap dax layer with your famfs logic in this series moved to bpf. I think it's pretty technically straightforward as it uses the famfs code logic you've already written in this series and just moves it to bpf. Overall, my intention with bringing this up is just to make sure we're at least aware of this alternative before anything is merged and permanent. If Miklos and you think we should land this series, then I'm on board with that. Thanks, Joanne [1] https://lore.kernel.org/linux-fsdevel/CAJnrk1YMqDKA5gDZasrxGjJtfdbhmjxX5uhUv=OSPyA=g5e...@mail.gmail.com/ > > > > > > Two things are true at once: I think this is a serious idea worth > > > considering, and I think it's too late to make this sort of change before > > > going upstream. Products need this enablement, and quite a long process > > > has > > > run in order to make it available in a timely fashion (which means soon > > > now). I hope we can avoid making the perfect the enemy of the good. > > > > > > I believe the risk of merging famfs soon is quite low, because famfs will > > > not affect anybody who doesn't use it. I hope we can run this discussion > > > and > > > analysis in parallel with merging the current implementation of famfs > > > soon. > > > > > > Hi John, > > > > one question, assuming most of these things can be done with eBPF, would > > you convert to eBPF after the merge? > > Hi Bernd, > > Stipulating that I've never even written 'hello world' with BPF, if it's > a nicer solution with no downsides we would migrate there. I don't know > enough yet to put a time frame on it, but I'll certainly understand more > by LSFMM. Will you be there? > > I'm hoping for a call with Joanne and Darrick in the next few days to get > better educated on it. > > > > > (I also need to find the time to review at least all of your libfuse > > changes, I feel guilty that still haven't done it.). > > > > > > Thanks, > > Bernd > > The libfuse changes are pretty small now. Two new messages - GET_FMAP and > GET_DAXDEV - plus a few more bits and bobs. If a future BPF migration took > place, there is a chance that those message numbers could be retired and > reused in the future. > > Watch this space... > > Thanks, > John >
