On 12/4/19 11:03 PM, Walter Dnes wrote:
nbd is a "Network Block Device" driver along the lines of NFS, but
it doesn't handle concurrency. https://nbd.sourceforge.io/
I think I'd liken NBD to iSCSI more so than NFS. Primarily because both
NBD and iSCSI provide local block devices that are backed by something
across the network. Conversely, NFS provides access to regular files
from across the network.
You can put a file system on an NBD / iSCSI block device if you want,
but you don't have to. Conversely, NFS is a file system and doesn't
require putting a file system on top of it.
But it's generic, and can handle any *REGULAR* file system, not just NFS.
NFS is not a file system in the /typical/ sense. There is no mkfs.nfs.
NFS is a file system in the sense that it is mounted and provides access
to files.
QCOW2, or raw, or whatever, is a special QEMU format. So it requires
QEMU libs (i.e. qemu-nbd) to decode QCOW2/RAW.
Why doesn't qemu have a dependency on NFS?
It doesn't, nor does it need to.
Same answer; they're both remote network block device systems that most
linux users don't need,
NFS is not a block device.
and they're both unrelated to the core functionality of QEMU.
QEMU can use image files (qcow(2) or raw) on any mounted file system.
NFS qualifies as a mounted file system, but that is completely outside
of QEMU.
Normal file systems can be put on NBD & iSCSI devices and mounted, but
that is also completely outside of QEMU.
QEMU proper will not use NBD devices (directly) itself.
qemu-nbd is a utility to act as a NBD server to allow the Linux kernel
to be an NBD client to access qcow(2) image files.
qemu-nbd is not /needed/ for normal QEMU operation.
--
Grant. . . .
unix || die
--
Grant. . . .
unix || die
