From: Paolo Bonzini <pbonzini@redhat.com>
To: Ming Lei <ming.lei@canonical.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-stable@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] block: fix big write
Date: Wed, 10 Dec 2014 17:44:01 +0100 [thread overview]
Message-ID: <54887851.20600@redhat.com> (raw)
In-Reply-To: <CACVXFVPXftZri3PiGOH-tMwg2=r3-dtVhbHGgSvnd5Aru2bHYg@mail.gmail.com>
On 10/12/2014 16:47, Ming Lei wrote:
> > > Finally blkdev_issue_zeroout() can send WRITE SAME(10/16) directly
> > > and it can be from user space, fs, and block drivers.
> >
> > That is WRITE SAME without UNMAP, it is not used by mkfs, and Linux has
> > always honored max_write_same_blocks for it (defaulting to a 65535 block
> > limit for older devices that did not report a limit).
>
> From QEMU view, blk_aio_write_zeroes() still need to handle
> case without UNMAP, and the default 65535 is just linux's current
> implementation, and even the recent patch tries to increase
> the default setting. Also the default limit might be bigger on other OS.
What is "another OS" that produces WRITE SAME with >2GB of data?
http://blogs.vmware.com/vsphere/2012/06/low-level-vaai-behaviour.html#more-3129
says ESX's default write same size is 1MB (2048 blocks).
Windows does not use WRITE SAME at all, according to Microsoft at
http://msdn.microsoft.com/en-us/library/windows/hardware/dn265487%28v=vs.85%29.aspx.
65535 is a sensible default for a host that doesn't know about
max_write_same_sectors. Anything else would break physical drives as well.
Please produce a concrete case that is broken, with a released OS.
Paolo
> > So what *concrete* case would be fixed by adding extra little-used code
> > in QEMU to do the split?
next prev parent reply other threads:[~2014-12-10 16:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 16:15 [Qemu-devel] [PATCH] block: fix big write Ming Lei
2014-12-05 16:33 ` Paolo Bonzini
2014-12-08 7:19 ` Ming Lei
2014-12-09 17:45 ` Paolo Bonzini
2014-12-10 1:41 ` Ming Lei
2014-12-10 9:56 ` Paolo Bonzini
2014-12-10 12:23 ` Ming Lei
2014-12-10 12:55 ` Paolo Bonzini
2014-12-10 14:35 ` Ming Lei
2014-12-10 15:02 ` Paolo Bonzini
2014-12-10 15:47 ` Ming Lei
2014-12-10 16:44 ` Paolo Bonzini [this message]
2014-12-05 17:03 ` Max Reitz
2014-12-05 17:04 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54887851.20600@redhat.com \
--to=pbonzini@redhat.com \
--cc=kwolf@redhat.com \
--cc=ming.lei@canonical.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.