aboutsummaryrefslogtreecommitdiff
path: root/hw/nvram
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2016-07-21 13:34:48 -0600
committerPaolo Bonzini <pbonzini@redhat.com>2016-08-03 18:44:57 +0200
commitb8d0a9804d0bd43c9b662a6917ae9cd514a54dff (patch)
treeedbb21af2bc767690acda8c5c03a2d5b06d2b86b /hw/nvram
parente9fd416e66539ad43bbab018f346cb164136c099 (diff)
downloadqemu-b8d0a9804d0bd43c9b662a6917ae9cd514a54dff.zip
qemu-b8d0a9804d0bd43c9b662a6917ae9cd514a54dff.tar.gz
qemu-b8d0a9804d0bd43c9b662a6917ae9cd514a54dff.tar.bz2
block: Cater to iscsi with non-power-of-2 discard
Dell Equallogic iSCSI SANs have a very unusual advertised geometry: $ iscsi-inq -e 1 -c $((0xb0)) iscsi://XXX/0 wsnz:0 maximum compare and write length:1 optimal transfer length granularity:0 maximum transfer length:0 optimal transfer length:0 maximum prefetch xdread xdwrite transfer length:0 maximum unmap lba count:30720 maximum unmap block descriptor count:2 optimal unmap granularity:30720 ugavalid:1 unmap granularity alignment:0 maximum write same length:30720 which says that both the maximum and the optimal discard size is 15M. It is not immediately apparent if the device allows discard requests not aligned to the optimal size, nor if it allows discards at a finer granularity than the optimal size. I tried to find details in the SCSI Commands Reference Manual Rev. A on what valid values of maximum and optimal sizes are permitted, but while that document mentions a "Block Limits VPD Page", I couldn't actually find documentation of that page or what values it would have, or if a SCSI device has an advertisement of its minimal unmap granularity. So it is not obvious to me whether the Dell Equallogic device is compliance with the SCSI specification. Fortunately, it is easy enough to support non-power-of-2 sizing, even if it means we are less efficient than truly possible when targetting that device (for example, it means that we refuse to unmap anything that is not a multiple of 15M and aligned to a 15M boundary, even if the device truly does support a smaller granularity where unmapping actually works). Reported-by: Peter Lieven <pl@kamp.de> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1469129688-22848-5-git-send-email-eblake@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'hw/nvram')
0 files changed, 0 insertions, 0 deletions