[Virtio-fs] [fuse-devel] 'FORGET' ordering semantics (vs unlink & NFS)
Liu, Jiang
gerry at linux.alibaba.com
Fri Jan 8 09:25:07 UTC 2021
> On Jan 8, 2021, at 5:08 PM, Amir Goldstein <amir73il at gmail.com> 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
More information about the Virtio-fs
mailing list