2019-05-19 20:07:45 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2009-01-22 15:33:25 +08:00
|
|
|
config FUSE_FS
|
|
|
|
|
tristate "FUSE (Filesystem in Userspace) support"
|
2016-08-29 21:46:37 +08:00
|
|
|
select FS_POSIX_ACL
|
2009-01-22 15:33:25 +08:00
|
|
|
help
|
|
|
|
|
With FUSE it is possible to implement a fully functional filesystem
|
|
|
|
|
in a userspace program.
|
|
|
|
|
|
2012-08-30 05:51:51 +08:00
|
|
|
There's also a companion library: libfuse2. This library is available
|
|
|
|
|
from the FUSE homepage:
|
2020-07-24 00:43:11 +08:00
|
|
|
<https://github.com/libfuse/>
|
2012-08-30 05:51:51 +08:00
|
|
|
although chances are your distribution already has that library
|
|
|
|
|
installed if you've installed the "fuse" package itself.
|
2009-01-22 15:33:25 +08:00
|
|
|
|
2020-04-15 00:48:35 +08:00
|
|
|
See <file:Documentation/filesystems/fuse.rst> for more information.
|
2009-01-22 15:33:25 +08:00
|
|
|
See <file:Documentation/Changes> for needed library/utility version.
|
|
|
|
|
|
|
|
|
|
If you want to develop a userspace FS, or if you want to use
|
|
|
|
|
a filesystem based on FUSE, answer Y or M.
|
2012-08-30 05:51:51 +08:00
|
|
|
|
|
|
|
|
config CUSE
|
|
|
|
|
tristate "Character device in Userspace support"
|
|
|
|
|
depends on FUSE_FS
|
|
|
|
|
help
|
|
|
|
|
This FUSE extension allows character devices to be
|
|
|
|
|
implemented in userspace.
|
|
|
|
|
|
|
|
|
|
If you want to develop or use a userspace character device
|
|
|
|
|
based on CUSE, answer Y or M.
|
virtio-fs: add virtiofs filesystem
Add a basic file system module for virtio-fs. This does not yet contain
shared data support between host and guest or metadata coherency speedups.
However it is already significantly faster than virtio-9p.
Design Overview
===============
With the goal of designing something with better performance and local file
system semantics, a bunch of ideas were proposed.
- Use fuse protocol (instead of 9p) for communication between guest and
host. Guest kernel will be fuse client and a fuse server will run on
host to serve the requests.
- For data access inside guest, mmap portion of file in QEMU address space
and guest accesses this memory using dax. That way guest page cache is
bypassed and there is only one copy of data (on host). This will also
enable mmap(MAP_SHARED) between guests.
- For metadata coherency, there is a shared memory region which contains
version number associated with metadata and any guest changing metadata
updates version number and other guests refresh metadata on next access.
This is yet to be implemented.
How virtio-fs differs from existing approaches
==============================================
The unique idea behind virtio-fs is to take advantage of the co-location of
the virtual machine and hypervisor to avoid communication (vmexits).
DAX allows file contents to be accessed without communication with the
hypervisor. The shared memory region for metadata avoids communication in
the common case where metadata is unchanged.
By replacing expensive communication with cheaper shared memory accesses,
we expect to achieve better performance than approaches based on network
file system protocols. In addition, this also makes it easier to achieve
local file system semantics (coherency).
These techniques are not applicable to network file system protocols since
the communications channel is bypassed by taking advantage of shared memory
on a local machine. This is why we decided to build virtio-fs rather than
focus on 9P or NFS.
Caching Modes
=============
Like virtio-9p, different caching modes are supported which determine the
coherency level as well. The “cache=FOO” and “writeback” options control
the level of coherence between the guest and host filesystems.
- cache=none
metadata, data and pathname lookup are not cached in guest. They are
always fetched from host and any changes are immediately pushed to host.
- cache=always
metadata, data and pathname lookup are cached in guest and never expire.
- cache=auto
metadata and pathname lookup cache expires after a configured amount of
time (default is 1 second). Data is cached while the file is open
(close to open consistency).
- writeback/no_writeback
These options control the writeback strategy. If writeback is disabled,
then normal writes will immediately be synchronized with the host fs.
If writeback is enabled, then writes may be cached in the guest until
the file is closed or an fsync(2) performed. This option has no effect
on mmap-ed writes or writes going through the DAX mechanism.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2018-06-12 16:41:17 +08:00
|
|
|
|
|
|
|
|
config VIRTIO_FS
|
|
|
|
|
tristate "Virtio Filesystem"
|
|
|
|
|
depends on FUSE_FS
|
|
|
|
|
select VIRTIO
|
|
|
|
|
help
|
|
|
|
|
The Virtio Filesystem allows guests to mount file systems from the
|
2019-11-20 21:43:32 +08:00
|
|
|
host.
|
virtio-fs: add virtiofs filesystem
Add a basic file system module for virtio-fs. This does not yet contain
shared data support between host and guest or metadata coherency speedups.
However it is already significantly faster than virtio-9p.
Design Overview
===============
With the goal of designing something with better performance and local file
system semantics, a bunch of ideas were proposed.
- Use fuse protocol (instead of 9p) for communication between guest and
host. Guest kernel will be fuse client and a fuse server will run on
host to serve the requests.
- For data access inside guest, mmap portion of file in QEMU address space
and guest accesses this memory using dax. That way guest page cache is
bypassed and there is only one copy of data (on host). This will also
enable mmap(MAP_SHARED) between guests.
- For metadata coherency, there is a shared memory region which contains
version number associated with metadata and any guest changing metadata
updates version number and other guests refresh metadata on next access.
This is yet to be implemented.
How virtio-fs differs from existing approaches
==============================================
The unique idea behind virtio-fs is to take advantage of the co-location of
the virtual machine and hypervisor to avoid communication (vmexits).
DAX allows file contents to be accessed without communication with the
hypervisor. The shared memory region for metadata avoids communication in
the common case where metadata is unchanged.
By replacing expensive communication with cheaper shared memory accesses,
we expect to achieve better performance than approaches based on network
file system protocols. In addition, this also makes it easier to achieve
local file system semantics (coherency).
These techniques are not applicable to network file system protocols since
the communications channel is bypassed by taking advantage of shared memory
on a local machine. This is why we decided to build virtio-fs rather than
focus on 9P or NFS.
Caching Modes
=============
Like virtio-9p, different caching modes are supported which determine the
coherency level as well. The “cache=FOO” and “writeback” options control
the level of coherence between the guest and host filesystems.
- cache=none
metadata, data and pathname lookup are not cached in guest. They are
always fetched from host and any changes are immediately pushed to host.
- cache=always
metadata, data and pathname lookup are cached in guest and never expire.
- cache=auto
metadata and pathname lookup cache expires after a configured amount of
time (default is 1 second). Data is cached while the file is open
(close to open consistency).
- writeback/no_writeback
These options control the writeback strategy. If writeback is disabled,
then normal writes will immediately be synchronized with the host fs.
If writeback is enabled, then writes may be cached in the guest until
the file is closed or an fsync(2) performed. This option has no effect
on mmap-ed writes or writes going through the DAX mechanism.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2018-06-12 16:41:17 +08:00
|
|
|
|
|
|
|
|
If you want to share files between guests or with the host, answer Y
|
2019-11-20 21:43:32 +08:00
|
|
|
or M.
|