[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v0] Implement new cache mode "targe
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH v0] Implement new cache mode "target" |
Date: |
Thu, 15 Aug 2019 16:27:45 +0200 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
Am 15.08.2019 um 15:53 hat Stefan Hajnoczi geschrieben:
> On Wed, Aug 07, 2019 at 04:09:54PM +0300, Artemy Kapitula wrote:
>
> Hi,
> Please use "scripts/get_maintainer.pl -f block.c" to find out which
> maintainers to email. address@hidden is a high-traffic list and
> patches not CCed to the right maintainer may not get quick review.
>
> > There is an issue with databases in VM that perform too slow
> > on generic SAN storages. The key point is fdatasync that flushes
> > disk on SCSI target.
> >
> > The QEMU blockdev "target" cache mode intended to be used with
> > SAN storages and is a mix of "none" by using direct I/O and
> > "unsafe" that omit device flush.
> >
> > Such storages has its own data integrity protection and can
> > be operated with direct I/O without additional fdatasyc().
> >
> > With generic SCSI targets like LIO or SCST it boost performance
> > up to 100% on some profiles like database with transaction journal
> > (postrgesql/mssql/oracle etc) or virtualized SDS (ceph/rook inside
> > VMs) which performs block device cache flush on journal record.
>
> If the physical storage controller has a Battery Backed Unit (BBU) or
> similar then flush requests are not required with O_DIRECT. This has
> been a common enterprise storage configuration for many years and is
> already supported in QEMU today:
>
> Configure the guest with cache=none and disable the emulated storage
> controller's write cache (e.g. -device virtio-blk-pci,write-cache=off).
> Inside the guest /sys/block/$BLKDEV/queue/write_cache should show "write
> through".
>
> I think this patch is not necessary since write-cache=off already
> exists. cache=target is also slower since the guest sends unnecessary
> flush requests to the emulated storage controller.
Two more comments:
1. The proposed cache mode can already be configured as
cache.direct=on,cache.no-flush=on. I don't think we intend to add new
aliases for combinations of these options. The existing aliases exist
for compatibility reasons.
2. If fdatasync() takes noticable time on such storage, this is a host
kernel problem. If we know that there is nothing to be synced, the
kernel should just return immediately without involving any I/O.
Kevin
signature.asc
Description: PGP signature