Rust FUSE library for server, virtio-fs and vhost-user-fs

Linux FUSE device (/dev/fuse)

Design

The fuse-backend-rs crate is an rust library to implement Fuse daemons based on the or the virtiofs draft specification.

Linux FUSE is an userspace filesystem framework, and the /dev/fuse device node is the interface for userspace filesystem daemons to communicate with the in-kernel fuse driver.

And the virito-fs specification extends the FUSE framework into the virtualization world, which uses the Virtio protocol to transfer FUSE requests and responses between the Fuse client and server. With virtio-fs, the Fuse client runs within the guest kernel and the Fuse server runs on the host userspace or hardware.

So the fuse-rs crate 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.

Examples

Filesystem Drivers

  • Virtual File System for an example of union file system.
  • Pseudo File System for an example of pseudo file system.
  • Passthrough File System for an example of passthrough(stacked) file system.
  • Registry Accelerated File System for an example of readonly file system for container images.

Fuse Servers

  • Dragonfly Image Service fusedev Server for an example of implementing a fuse server based on the fuse-backend-rs crate.
  • Dragonfly Image Service vhost-user-fs Server for an example of implementing vhost-user-fs server based on the fuse-backend-rs crate.

Fuse Server and Main Service Loop

A sample fuse server based on the Linux Fuse device (/dev/fuse):

use fuse_backend_rs::api::{server::Server, Vfs, VfsOptions};
use fuse_backend_rs::transport::fusedev::{FuseSession, FuseChannel};

struct FuseServer {
    server: Arc<Server<Arc<Vfs>>>,
    ch: FuseChannel,
}

impl FuseServer {
    fn svc_loop(&self) -> Result<()> {
      // Given error EBADF, it means kernel has shut down this session.
      let _ebadf = std::io::Error::from_raw_os_error(libc::EBADF);
      loop {
        if let Some((reader, writer)) = self
                .ch
                .get_request()
                .map_err(|_| std::io::Error::from_raw_os_error(libc::EINVAL))?
        {
          if let Err(e) = self.server.handle_message(reader, writer, None, None) {
            match e {
              fuse_backend_rs::Error::EncodeMessage(_ebadf) => {
                break;
              }
              _ => {
                error!("Handling fuse message failed");
                continue;
              }
            }
          }
        } else {
          info!("fuse server exits");
          break;
        }
      }
      Ok(())
    }
}

License

This project is licensed under

  • Apache License, Version 2.0
  • BSD-3-Clause License
Issues

Collection of the latest Issues

lizelive

lizelive

1

Defining a drop file system as a read only pass through file system that silently ignores write operations.

My plan is for open read, we'd do the open and forward the reads. For create / write we open behave like /dev/null For read directory, if the directory exists read it normally Otherwise treat it like an empty directory.

Reading and writing to a file descriptor that doesn't exist is undefined thinking that it does not throw an error, instead behaves like /dev/null unless it's faster to throw an error.

Getting information for files the don't exist Acts like /dev/null

Would be a lot easier if pass through was a trait with default imitation that actually does pass through.

I was thinking I would be to have a pass through in my struct and forward valid operations and mask failures. Also always disable write caching. My understanding is that their is only one trait I need to implement and that's BackendFileSystem or FileSystem

I was looking at the pass through file system defined here, as well as https://github.com/libfuse/libfuse/blob/master/example/passthrough_hp.cc My understanding is that passthrough_hp.cc doesn't do any unnecessary copies.

  1. Does the pass through do unnecessary copies?
  2. Do I always need synchronous io?
  3. Is there anything like memory mapping that I have to worry about? I really don't want the user to be able to write to the underlying FS under any circumstance.
  4. Should I disable write cashing?
  5. Would it be more performant to implement a black hole (acts acts like an empty directory and ignores all write and creation) and then set up an overlay?
  6. BackendFileSystem vs FileSystem
aakefbs

aakefbs

2

Incompatible PERFILE_DAX flag. I only noticed about this project as Vivek Goyal pointed me to it on the fsdevel list and I checked used flags because of this patch https://marc.info/?l=linux-fsdevel&m=165002361802294&w=2 And then noticed that PERFILE_DAX flag is conflicting with FUSE_INIT_EXT

Looks like you are on a non-upstream kernel with patches?

linux master include/uapi/linux/fuse.h

... #define FUSE_INIT_EXT (1 << 30) #define FUSE_INIT_RESERVED (1 << 31) /* bits 32..63 get shifted down 32 bits into the flags2 field */ #define FUSE_SECURITY_CTX (1ULL << 32) #define FUSE_HAS_INODE_DAX (1ULL << 33)

Btw, any reason you are not using 1 << number for the flags? In my personal opinion so much easier to read...

Versions

Find the latest versions by id

v0.9.0 - Apr 27, 2022

v0.8.0 - Apr 24, 2022

v0.4.0 - Mar 29, 2022

What's Changed

New Contributors

Full Changelog: https://github.com/cloud-hypervisor/fuse-backend-rs/compare/v0.3.0...v0.4.0

v0.3.0 - Feb 08, 2022

Added

  • Optionally enable MAX_PAGES feature
  • Allow customizing the default FUSE features before creating a new vfs structure
  • Support more FUSE server APIs

Changed

The FUSE server has no default FUSE feature set now. The default feature set is only defined in VfsOptions. Non VFS users have to define the default FUSE feature set in the init() method.

v0.2.0 - Dec 30, 2021

[v0.2.0]

Added

  • Enhance passthrough to reduce active fds by using file handle
  • implement Fromfusedev::Error for std::io::Error
  • Use vhost crate from crates.io
  • Introduce readlinkat_proc_file helper
  • Update vm-memory to 0.7.0
  • Add @eryugey to CODEOWNERS file

Fixed

  • Validate path components
  • Prevent ".." escape in do_lookup in passthroughfs
  • Prevent opening of special file in passthroughfs
  • Fix compile error in vfs async test
  • Record real root inode's ino of file system backends in vfs

Deprecated

v0.1.2 - Aug 04, 2021

  • support KILLPRIV_v2
  • enhance vfs to support DAX window map/unmap operations

v0.1.1 - Feb 13, 2021

refine crate documentations:

  1. add README to Cargo.toml
  2. refine README.md

v0.1.0 - Feb 11, 2021

This is the first release!

Information - Updated May 14, 2022

Stars: 43
Forks: 16
Issues: 3

CDRS is looking for maintainers

CDRS is Apache Cassandra driver written in pure Rust

CDRS is looking for maintainers
Http

337

A push parser for the HTTP 1

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2

A push parser for the HTTP 1

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct...

This library is released under the MIT License and the Apache v2 License (see License)

The arkworks ecosystem consist of Rust libraries for designing and working with zero knowledge succinct...

Say Hello To DataBend The Open Source Cloud Warehouse for Everyone

Databend is inspired by apache-arrow and allows you to scale your cloud warehousing, using off the shelf open source stacks & the ultra fast processing speeds you come to expect from say Bigquery

Say Hello To DataBend The Open Source Cloud Warehouse for Everyone

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀

This project is duel-licensed under both the Apache licenses, so feel free to use either at your discretion

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀

This project is duel-licensed under both the Apache licenses, so feel free to use either at your discretion

Bespoke protocol and high-level implementation of Non-fungible token (NFT) technology 🚀
Facebook Instagram Twitter GitHub Dribbble
Privacy