Skip to content

Repository files navigation

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

Crates.io Crates.io

Design

The fuse-backend-rs crate is an rust library to implement Fuse daemons based on the Linux FUSE device (/dev/fuse) 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.

arch

Async IO (Experimental)

Besides the traditional synchronous IO path, an asynchronous IO path is provided through the optional async-io cargo feature, e.g.:

[dependencies]
fuse-backend-rs = { git = "https://github.com/cloud-hypervisor/fuse-backend-rs", features = ["fusedev", "async-io"] }

The async-io feature is not part of a released crate version yet, so depend on the git repository directly. Please note that the feature is still experimental:

  • It depends on tokio-uring and io_uring, so it's only available on Linux. Builds with the feature enabled will fail on other platforms.
  • The asynchronous interfaces and behavior may change in future releases.
  • The asynchronous handlers of PassthroughFs currently relay requests to their synchronous counterparts, so the blocking syscalls run in the context of the async runtime. A native io_uring based implementation is planned for the future.

To serve requests asynchronously, mount the filesystem through Vfs and drive a FuseDevTask (fusedev transport) inside an async runtime, refer to tests/async_smoke.rs for a working example.

Examples

Filesystem Drivers

Fuse Servers

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

About

Rust crate for implementing FUSE backends

Resources

Stars

188 stars

Watchers

9 watching

Forks

Releases

Packages

Used by

Contributors

Languages