>>With nfs as source storage, it's really slow currently (lseek slow + a lot of >>nfs ops).
it's blocked around 30min for 300GB, with a raw file on a netapp san array through nfs. ----- Mail original ----- De: "aderumier" <aderum...@odiso.com> À: "Fam Zheng" <f...@redhat.com> Cc: "Kevin Wolf" <kw...@redhat.com>, qemu-bl...@nongnu.org, "Jeff Cody" <jc...@redhat.com>, "qemu-devel" <qemu-devel@nongnu.org>, "qemu-stable" <qemu-sta...@nongnu.org>, "stefanha" <stefa...@redhat.com>, "pbonzini" <pbonz...@redhat.com>, js...@redhat.com, wangxiaol...@ucloud.cn Envoyé: Vendredi 26 Juin 2015 15:36:10 Objet: Re: [Qemu-devel] [Qemu-stable] [PATCH v7 0/8] block: Mirror discarded sectors Hi, >>There is no problem, the observasion by Andrey was just that qmp command >>takes >>a few minutes before returning, because he didn't apply >> >>https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg02511.html Is this patch already apply on the block tree ? With nfs as source storage, it's really slow currently (lseek slow + a lot of nfs ops). ----- Mail original ----- De: "Fam Zheng" <f...@redhat.com> À: "pbonzini" <pbonz...@redhat.com> Cc: "Kevin Wolf" <kw...@redhat.com>, qemu-bl...@nongnu.org, "Jeff Cody" <jc...@redhat.com>, "qemu-devel" <qemu-devel@nongnu.org>, "qemu-stable" <qemu-sta...@nongnu.org>, "stefanha" <stefa...@redhat.com>, js...@redhat.com, wangxiaol...@ucloud.cn Envoyé: Jeudi 25 Juin 2015 12:45:38 Objet: Re: [Qemu-devel] [Qemu-stable] [PATCH v7 0/8] block: Mirror discarded sectors On Thu, 06/25 09:02, Fam Zheng wrote: > On Wed, 06/24 19:01, Paolo Bonzini wrote: > > > > > > On 24/06/2015 11:08, Fam Zheng wrote: > > >> Stefan, > > >> > > >> The only controversial patches are the qmp/drive-mirror ones (1-3), > > >> while > > >> patches 4-8 are still useful on their own: they fix the mentioned crash > > >> and > > >> improve iotests. > > >> > > >> Shall we merge the second half (of course none of them depend on 1-3) > > >> now that > > >> softfreeze is approaching? > > > > > > Stefan, would you consider applying patches 4-8? > > > > Actually why not apply all of them? Even if blockdev-mirror is a > > superior interface in the long run, the current behavior of drive-mirror > > can cause images to balloon up to the full size, which is bad. > > Extending drive-mirror is okay IMHO for 2.4. > > > > Before we do that, Andrey Korolyov has reported a hang issue with unmap=true, > I'll take a look at it today. There is no problem, the observasion by Andrey was just that qmp command takes a few minutes before returning, because he didn't apply https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg02511.html Fam
