qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCHv3 1.8 8/9] qemu-img: increase min_sparse to 128 sectors (64kb)
Date: Thu, 5 Dec 2013 11:35:15 +0100	[thread overview]
Message-ID: <20131205103515.GE9629@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <73B4DA19-7D30-4392-8E20-BE9B8C9D4555@kamp.de>

On Thu, Dec 05, 2013 at 05:55:22AM +0100, Peter Lieven wrote:
> 
> 
> > Am 05.12.2013 um 03:12 schrieb Eric Blake <eblake@redhat.com>:
> > 
> > On 12/04/2013 09:46 AM, Peter Lieven wrote:
> > 
> >>> I guess a sane size would be cluster size.  For a raw file 4 KB is
> >>> reasonable since that's the file system block size.
> >> in case of iscsi the cluster size could be much too high as for example
> >> my storage has a cluster_size of 15MB.
> >>> 
> >>> Is it necessary to increase to 64 KB here?
> >> No, its indepent of the rest. Paolo suggested to increase it and I can confirm
> >> that for my usage case its faster than 4K.
> > 
> > At least on NTFS file systems, 64k is the minimum size of a hole in a
> > sparse file.  While many file systems support smaller holes, there are
> > definitely systems where trying to detect smaller holes only results in
> > wasted efforts.  Is it worth making the default dynamic based on stat()
> > information regarding optimum IO size for the given destination file system?
> 
> it is definetely worth it, but i would require additional work and testing. the current code does not create holes that are aligned to min_sparse and min_sparse has to be limited to a reasonable size. and i wonder if the right value is bs->bl.opt_transfer_lenght, bs->bl.discard_alignment or bdi->cluster_size/9. maybe depepnding on if its a cow Image or not.
> 
> i can look at this. but i would leave the patch out for now.

Okay, I'll drop this patch for now.  It can be improved in a separate
series.

Stefan

  reply	other threads:[~2013-12-05 10:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27 10:07 [Qemu-devel] [PATCHv3 1.8 0/9] qemu-img convert optimizations Peter Lieven
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 1/9] qemu-img: add support for skipping zeroes in input during convert Peter Lieven
2013-11-27 10:17   ` Paolo Bonzini
2013-12-04 16:46   ` Stefan Hajnoczi
2013-12-04 16:51     ` Peter Lieven
2013-12-05 10:30       ` Stefan Hajnoczi
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 2/9] qemu-img: fix usage instruction for qemu-img convert Peter Lieven
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 3/9] block/iscsi: set bdi->cluster_size Peter Lieven
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 4/9] block: add opt_transfer_length to BlockLimits Peter Lieven
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 5/9] block/iscsi: set bs->bl.opt_transfer_length Peter Lieven
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 6/9] qemu-img: dynamically adjust iobuffer size during convert Peter Lieven
2013-12-05 13:30   ` Eric Blake
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 7/9] qemu-img: round down request length to an aligned sector Peter Lieven
2013-12-04 15:49   ` Stefan Hajnoczi
2013-12-04 15:56     ` Peter Lieven
2013-12-05 10:33       ` Stefan Hajnoczi
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 8/9] qemu-img: increase min_sparse to 128 sectors (64kb) Peter Lieven
2013-12-04 16:43   ` Stefan Hajnoczi
2013-12-04 16:46     ` Peter Lieven
2013-12-05  2:12       ` Eric Blake
2013-12-05  4:55         ` Peter Lieven
2013-12-05 10:35           ` Stefan Hajnoczi [this message]
2013-11-27 10:07 ` [Qemu-devel] [PATCHv3 1.8 9/9] qemu-img: decrease progress update interval on convert Peter Lieven
2013-12-05 12:15 ` [Qemu-devel] [PATCHv3 1.8 0/9] qemu-img convert optimizations Stefan Hajnoczi
2013-12-05 14:55   ` Peter Lieven

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=20131205103515.GE9629@stefanha-thinkpad.redhat.com \
    --to=stefanha@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).