virtiofs: virtio-fs host<->guest shared file system

  • Copyright (C) 2019 Red Hat, Inc.

Introduction

The virtiofs file system for Linux implements a driver for the paravirtualizedVIRTIO “virtio-fs” device for guest<->host file system sharing. It allows aguest to mount a directory that has been exported on the host.

Guests often require access to files residing on the host or remote systems.Use cases include making files available to new guests during installation,booting from a root file system located on the host, persistent storage forstateless or ephemeral guests, and sharing a directory between guests.

Although it is possible to use existing network file systems for some of thesetasks, they require configuration steps that are hard to automate and theyexpose the storage network to the guest. The virtio-fs device was designed tosolve these problems by providing file system access without networking.

Furthermore the virtio-fs device takes advantage of the co-location of theguest and host to increase performance and provide semantics that are notpossible with network file systems.

Usage

Mount file system with tagmyfs on/mnt:

guest#mount-tvirtiofsmyfs/mnt

Please seehttps://virtio-fs.gitlab.io/ for details on how to configure QEMUand the virtiofsd daemon.

Mount options

virtiofs supports general VFS mount options, for example, remount,ro, rw, context, etc. It also supports FUSE mount options.

atime behavior

The atime-related mount options, for example, noatime, strictatime,are ignored. The atime behavior for virtiofs is the same as theunderlying filesystem of the directory that has been exportedon the host.

Internals

Since the virtio-fs device uses the FUSE protocol for file system requests, thevirtiofs file system for Linux is integrated closely with the FUSE file systemclient. The guest acts as the FUSE client while the host acts as the FUSEserver. The /dev/fuse interface between the kernel and userspace is replacedwith the virtio-fs device interface.

FUSE requests are placed into a virtqueue and processed by the host. Theresponse portion of the buffer is filled in by the host and the guest handlesthe request completion.

Mapping /dev/fuse to virtqueues requires solving differences in semanticsbetween /dev/fuse and virtqueues. Each time the /dev/fuse device is read, theFUSE client may choose which request to transfer, making it possible toprioritize certain requests over others. Virtqueues have queue semantics andit is not possible to change the order of requests that have been enqueued.This is especially important if the virtqueue becomes full since it is thenimpossible to add high priority requests. In order to address this difference,the virtio-fs device uses a “hiprio” virtqueue specifically for requests thathave priority over normal requests.