On Fri, Jan 08, 2021 at 11:08:41AM +0200, Amir Goldstein 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?
We do have secure container workloads running in production env (limited scale for testing though) and using fuse-backend-rs to passthrough fs operations. > I would be happy to contribute the open_by_handle_at() changes > if I know they will get properly tested. Yes, as Liu Jiang said, we have similar issues when using viriofs, and are happy to test the open_by_handle code! Thanks, Eryu > > 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. > > [1] https://github.com/amir73il/libfuse/commits/cachegwfs _______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
