> On Jan 8, 2021, at 5:08 PM, Amir Goldstein <[email protected]> wrote: > >>> Miklos, >>> >>> I would like to point out that this discussion is relevant to any low level >>> fuse filesystem, but especially those that are proxying a real filesystem. >>> >>> I have raised this question before in the FUSE_PASSTHROUGH threads. >>> There is a lot of code duplication among various low-level fuse projects and >>> as we get to NFS export support and complex issues like this one, is it >>> getting unlikely that all projects will handle this correctly. >>> >>> Do you think there is room for some more generic code in libfuse and if >>> so how? Following an example implementation (assuming it gets fixed) >>> and hand picking fixes to projects cannot scale for long. >>> >>> The challenge is that most of the generic code would be in lookup and >>> maintaining the internal inode cache, but each filesystem may need >>> different representations of the Inode object. >>> >>> I was thinking of something along the lines of an OO library that >>> implements the generic lookup/inode cache for a base FuseInode class >>> that implementers can inherit from. >>> >>> This doesn't need to be in the libfuse project at all. >>> Seeing the virtiofsd already has a Rust implementation that is BSD >>> licensed, maybe that can be used as a starting point? >>> >>> David, >>> >>> How hard do you think it would be to re-factor virtiofsd-rs to >>> an implementation that inherits from a base passthroughfsd-rs? >>> >>> BTW, is virtiofsd-rs the offical virtiofsd or an experimental one? >>> Which tree does Miklos' patch apply to? >>> >>> Anyone has other thoughts about how to reduce fragmentation in >>> implementations? >> >> There's an fuse-backend-rs[1] project hosted on cloud-hypervisor, it is >> a library to communicate with the Linux FUSE clients, which includes: >> >> - ABI layer, which defines all data structures shared between linux Fuse >> framework and Fuse daemons. >> - API layer, defines the interfaces for Fuse daemons to implement a >> userspace file system. >> - Transport layer, which supports both the Linux Fuse device and >> virtio-fs protocol. >> - VFS/pseudo_fs, an abstraction layer to support multiple file systems >> by a single virtio-fs device. >> - A sample passthrough file system implementation, which passes through >> files from daemons to clients. >> >> I'm wondering if fuse-backend-rs is a proper project to work on, and >> maybe virtiofsd-rs could be switched to use it as well in the future. >> >> Thanks, >> Eryu >> >> [1] https://github.com/cloud-hypervisor/fuse-backend-rs > > > Hi Eryu! > > This looks very interesting. > Can you guys say a few words about the maturity of this project. > Does it have any CI? any beta/production workloads that use it? > I would be happy to contribute the open_by_handle_at() changes > if I know they will get properly tested. > > As demonstrated in this demo fs [1], with xfs/ext4 as underlying filesystem, > full NFS support can be implemented by implementing lookup in filesystem > by inode only, before fuse adds support to LOOKUP_HANDLE in the protocol. > > Thanks, > Amir. Hi Amir, This project is derived from crosvm and Cloud Hypervisor, and we have extended it to support some Container centric usage mode. About quality, I think it may be some sort of “product”, but the project itself still lacks of a robust CI system. The proposal you mentioned about open_by_handle_at() is very attractive:) We have encountered some cases running out of file descriptors, we have also encountered issues to enabling virtio-fs over nfs. Absolutely the open_by_handle_at() proposal helps here:) And the next big step of the project is to enable io_uring and rust async io:) Thanks!
> > [1] https://github.com/amir73il/libfuse/commits/cachegwfs _______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
