qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/22] block: Support for 512b-on-4k emulation


From: Peter Lieven
Subject: Re: [Qemu-devel] [PATCH 00/22] block: Support for 512b-on-4k emulation
Date: Thu, 12 Dec 2013 07:09:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

Should it be possible to boot from a 4K-native drive with this series?
If yes, I will run some test with some new iSCSI arrays we got for testing
they can export 4k blocksize LUNs.

Anyway, can you please include the patch from Paolo which sets
the bs->request_alignment = iscsilun->block_size in iscsi_open.
It should be a one-liner.

Peter

Am 11.12.2013 22:08, schrieb Kevin Wolf:
> This patch series adds code to the block layer that allows performing
> I/O requests in smaller granularities than required by the host backend
> (most importantly, O_DIRECT restrictions). It achieves this for reads
> by rounding the request to host-side block boundary, and for writes by
> performing a read-modify-write cycle (and serialising requests
> touching the same block so that the RMW doesn't write back stale data).
>
> Originally I intended to reuse a lot of code from Paolo's previous
> patch series, however as I tried to integrate pread/pwrite, which
> already do a very similar thing (except for considering concurrency),
> and because I wanted to implement zero-copy, most of this series ended
> up being new code.
>
> Zero-copy is possible in a common case because while XFS defauls to a
> 4k sector size and therefore 4k on-disk O_DIRECT alignment for 512E
> disks, it still only has a 512 byte memory alignment requirement.
> (Unfortunately the XFS_IOC_DIOINFO ioctl claims 4k even for memory, but
> we know that the value is wrong and can probe it.)
>
>
> Changes since RFC:
> - Moved opt_mem_alignment into BlockLimits [Paolo]
>
> - Changed BlockLimits in turn to work a bit more like the
>   .bdrv_opt_mem_align() callback of the RFC; allows updating the
>   BlockLimits later when the chain changes or bdrv_reopen() toggles
>   O_DIRECT
>
> - Fixed a typo in a commit message [Eric]
>
>
> Kevin Wolf (20):
>   block: Move initialisation of BlockLimits to bdrv_refresh_limits()
>   block: Inherit opt_transfer_length
>   block: Update BlockLimits when they might have changed
>   qemu_memalign: Allow small alignments
>   block: Detect unaligned length in bdrv_qiov_is_aligned()
>   block: Don't use guest sector size for qemu_blockalign()
>   block: Introduce bdrv_aligned_preadv()
>   block: Introduce bdrv_co_do_preadv()
>   block: Introduce bdrv_aligned_pwritev()
>   block: write: Handle COR dependency after I/O throttling
>   block: Introduce bdrv_co_do_pwritev()
>   block: Switch BdrvTrackedRequest to byte granularity
>   block: Allow waiting for overlapping requests between begin/end
>   block: Make zero-after-EOF work with larger alignment
>   block: Generalise and optimise COR serialisation
>   block: Make overlap range for serialisation dynamic
>   block: Align requests in bdrv_co_do_pwritev()
>   block: Change coroutine wrapper to byte granularity
>   block: Make bdrv_pread() a bdrv_prwv_co() wrapper
>   block: Make bdrv_pwrite() a bdrv_prwv_co() wrapper
>
> Paolo Bonzini (2):
>   block: rename buffer_alignment to guest_block_size
>   raw: Probe required direct I/O alignment
>
>  block.c                   | 602 
> +++++++++++++++++++++++++++++++---------------
>  block/backup.c            |   7 +-
>  block/iscsi.c             |  87 ++++---
>  block/qcow2.c             |  11 +-
>  block/qed.c               |  11 +-
>  block/raw-posix.c         | 102 ++++++--
>  block/raw-win32.c         |  41 ++++
>  block/stream.c            |   2 +
>  block/vmdk.c              |  22 +-
>  hw/block/virtio-blk.c     |   2 +-
>  hw/ide/core.c             |   2 +-
>  hw/scsi/scsi-disk.c       |   2 +-
>  hw/scsi/scsi-generic.c    |   2 +-
>  include/block/block.h     |   6 +-
>  include/block/block_int.h |  25 +-
>  util/oslib-posix.c        |   5 +
>  16 files changed, 666 insertions(+), 263 deletions(-)
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]