Very informative explanation.
On 12/05/19 20:01, Grant Taylor wrote:
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.
But, since it's included in the package, and apparently (from the name)
will use a NBD device, then I think the dependency is logical
