On Tue, Aug 27, 2024 at 5:32 PM Han-Wen Nienhuys <hanwenn@xxxxxxxxx> wrote: > > On Tue, Aug 27, 2024 at 3:48 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > On Tue, Aug 27, 2024 at 11:42 AM Han-Wen Nienhuys <hanwenn@xxxxxxxxx> wrote: > > > > > > Hi folks, > > > > Hi Han-Wen, > > > > For future reference, please CC FUSE and libfuse maintainers > > and FUSE passthrough developer (me) if you want to make sure > > that you got our attention. > > Sure. Who is the libfuse maintainer these days? Oops, forgot to CC Bernd. > > > > I tried simply closing the backing FD right after obtaining the > > > backing ID, and it seems to work. Is this permitted? > > > > Yes. > > awesome! > > > BTW, since you are one of the first (publicly announced) users of > > FUSE passthrough, it would be helpful to get feedback about API, > > which could change down the road and about your wish list. > > For full transparency, I just work on the go-fuse library for fun, I > don't have direct applications for passthrough at the moment. That > said, I have been trying to make it go faster, and obviously bypassing > user-space for reads/writes helps in a big way. > > > Specifically, I have WIP patches for > > - readdir() passthrough > > - stat()/getxattr()/listxattr() passthrough > > > > and users feedback could help me decide how to prioritize between > > those (and other) FUSE passthrough efforts. > > It's been useful in the past to defer all file operations to an > underlying file, and only change where in the tree a file is surfaced. > In that sense, it would be nice to just say "pass all operations on > this (open) file to this other file". Go-FUSE has a LoopbackFile and > LoopbackNode that lets you do that very easily, but it would be extra > attractive if that would also avoid kernel roundtrips. > > For flexibility, it might be useful to pass a bitmask or a list of > FUSE opcodes back to the kernel, so you can select which operations > should be passed through. There is an ops_mask in my WIP patches: https://github.com/amir73il/linux/commits/fuse-backing-inode-wip/ > > The most annoying part of the current functionality is the > CAP_SYS_ADMIN restriction; I am not sure everyone is prepared to run > their file systems as root. Could the ioctl check that the file was > opened as O_RDWR, and stop checking for root? > Donno. It's a challenge. Will need to think about it. > If you are proposing to do xattr functions, that means that you also > will do passthrough for files that are not opened? > > Right now, the backing ID is in the OpenOut structure; how would you > pass back the backing ID so it could be used for stat() ? IMO the most > natural solution would be to extend the lookup response so you can > directly insert a backing ID there. Yes, that's the idea. The WIP demonstrates a different lifetime for the backing inode that could persist from lookup to evict, but the lookup response was not extended yet. > > I made a mistake in how I treat opendir/readdir in the high-level > go-fuse API. Until that is fixed, I cannot use passthrough for > readdir. That said, part of making FUSE filesystems go fast is to > amortize the cost of lookup using readdirplus. That wouldn't work with > readdir passthrough, so it may not be that useful. > This is indeed a challenge. I'll need to see how to deal with it. > So in summary, my wishlist for passthrough (decreasing importance): > > 1. get rid of cap_sys_admin requirement > 2. allow passthrough for all file operations (fallocate, fsync, flush, > setattr, etc.) > Thanks for the feedback! Amir.
