diff options
author | Eric Blake <eblake@redhat.com> | 2017-07-07 15:30:49 -0500 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2017-07-14 12:04:42 +0200 |
commit | 081dd1fe36f0ccc04130d1edd136c787c5f8cc50 (patch) | |
tree | 5d0f1fce79c0fb610e6ddc24f6cd29fc197887b3 /.exrc | |
parent | 0c1d50bda7ae03146b4bf7bc3a12389897ea059c (diff) | |
download | qemu-081dd1fe36f0ccc04130d1edd136c787c5f8cc50.zip qemu-081dd1fe36f0ccc04130d1edd136c787c5f8cc50.tar.gz qemu-081dd1fe36f0ccc04130d1edd136c787c5f8cc50.tar.bz2 |
nbd: Implement NBD_INFO_BLOCK_SIZE on client
The upstream NBD Protocol has defined a new extension to allow
the server to advertise block sizes to the client, as well as
a way for the client to inform the server whether it intends to
obey block sizes.
When using the block layer as the client, we will obey block
sizes; but when used as 'qemu-nbd -c' to hand off to the
kernel nbd module as the client, we are still waiting for the
kernel to implement a way for us to learn if it will honor
block sizes (perhaps by an addition to sysfs, rather than an
ioctl), as well as any way to tell the kernel what additional
block sizes to obey (NBD_SET_BLKSIZE appears to be accurate
for the minimum size, but preferred and maximum sizes would
probably be new ioctl()s), so until then, we need to make our
request for block sizes conditional.
When using ioctl(NBD_SET_BLKSIZE) to hand off to the kernel,
use the minimum block size as the sector size if it is larger
than 512, which also has the nice effect of cooperating with
(non-qemu) servers that don't do read-modify-write when
exposing a block device with 4k sectors; it might also allow
us to visit a file larger than 2T on a 32-bit kernel.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20170707203049.534-10-eblake@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to '.exrc')
0 files changed, 0 insertions, 0 deletions