BHYVE magic pattern disk support and NFS WRITE_SAME Re: BHYVE on NFSv4.2 filesystem?
Dan Shelton <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.hackers |
|---|---|
| Message-ID | <CAAvCNcDxO9YrvutebMNZOM9P-sddPLto9mEz7qKmt9EmhEBE8A@mail.gmail.com> |
On Tue, 9 Jun 2026 at 17:49, Rick Macklem <[email protected]> wrote: > > On Mon, May 18, 2026 at 3:39 PM Bakul Shah <[email protected]> wrote: > > > > On May 18, 2026, at 2:26 PM, Dan Shelton <[email protected]> wrote: > > > > > > On Fri, 20 Feb 2026 at 01:21, Bakul Shah <[email protected]> wrote: > > >> > > >> On Feb 19, 2026, at 11:45 AM, Dan Shelton <[email protected]> wrote: > > >>> > > >>> On Wed, 18 Feb 2026 at 22:45, Dan Shelton <[email protected]> wrote: > > >>>> > > >>>> Hello, > > >>>> > > >>>> Has anyone tried a BHYVE with a disk as file on a NFSv4.2 mount? > > >> > > >> Yes. [I tried this on a 15.0-RELEASE-p3 host, nfsv4.2 mounting > > >> a filesystem from a 15.0-STABLE machine] > > > > > > How about the performance? Is it better than iSCSI? > > > > I don't know about iSCSI but comparing with p9fs: > > > > Test1: > > dd bs=1m count=4000 > /dev/null < large-file > > > > nfsV3: > > 32.3 > > 46.3 > > 51.3 > > > > nfsV4: > > 129.1 > > 59.9 > > 48.8 > > > > p9fs: > > 17.7 > > 17.5 > > 17.6 > > > > Test2: > > find /usr/src/ > /dev/null > > > > nfsV3: > > 60.0 > > 39.0 > > 30.9 > > > > nfsV4: > > 54.0 > > 17.9 > > 35.8 > > > > p9fs: > > 6.9 > > 6.5 > > 6.6 > > > > > > So slower in all cases. In addition the variability in nfs numbers is concerning! > > > > p9fs doesn't cache but nfs does, so anything cached is served much faster. > At this time it is only a hunch, but I think this might help.. > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-uncacheable-files/ > > I plan on implementing this soon for FreeBSD. Could you pls implement NFS WRITE_SAME support in FreeBSD nfsd? VMs and databases sometimes have write patterns like filling a virtual disk with long (4M, 32M, 512M, ...) sequences of 0x11111111, 0xdeadf00d or similar patterns (between 0x1 byte and 65536 bytes long repeated sequences). These are NOT sparse file holes (which represent unallocated areas), these are "magic patterns" for various purposes, and are done with SCSI WRITE SAME. Windows HyperV and VMware have acceleration for these writes and benefit a lot in terms of performance. Dan -- Dan Shelton - Cluster Specialist Win/Lin/Bsd