Date: Fri, 29 Oct 2021 11:59:40 +0100 From: David Chisnall <theraven@FreeBSD.org> To: freebsd-current@freebsd.org Subject: Re: Deprecating smbfs(5) and removing it before FreeBSD 14 Message-ID: <157d6222-0a89-230d-8e54-ec0b785af6a3@FreeBSD.org> In-Reply-To: <20211028152642.ejvwewkztewotln4@mutt-hbsd> References: <CAPyFy2CJKxMQQKwD3N=MTe-P4KodN77e3YCEh4z0Ssf9sXWEcQ@mail.gmail.com> <20211028152642.ejvwewkztewotln4@mutt-hbsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28/10/2021 16:26, Shawn Webb wrote: > I wonder if providing a 9pfs client would be > a good step in helping deprecate smbfs. Note: WSL2 uses 9p-over-VMBus, but most of the Linux world is moving away from 9p-over-VirtIO to FUSE-over-VirtIO. This has a few big advantages: - The kernel already has solid FUSE support so this isn't a completely new code path. - FUSE is designed around POSIX filesystem semantics, 9p isn't and this mismatch causes problems in places. - FUSE filesystems can be exposed almost directly to the guest. For example, if you have a networked filesystem you can run the FUSE FS in an unprivileged userspace process and remove the entire host kernel storage stack from the attack surface for the guest. - FUSE allows exposing buffer cache pages. The FUSE-over-VirtIO mechanism makes it fairly easy to expose read-only root filesystem images to guests. The last point is especially important for container workloads where you may have hundreds of containers in lightweight VMs on a single node all using the same base layer. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?157d6222-0a89-230d-8e54-ec0b785af6a3>