From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:53204)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Q9Sfd-0001hk-N4
	for qemu-devel@nongnu.org; Mon, 11 Apr 2011 21:45:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hch@lst.de>) id 1Q9LZm-0003ua-00
	for qemu-devel@nongnu.org; Mon, 11 Apr 2011 14:11:02 -0400
Received: from verein.lst.de ([213.95.11.211]:54580 helo=newverein.lst.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hch@lst.de>)
	id 1Q9LZl-0003u1-RO
	for qemu-devel@nongnu.org; Mon, 11 Apr 2011 14:11:01 -0400
Date: Mon, 11 Apr 2011 20:11:00 +0200
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20110411181100.GA8877@lst.de>
References: <BANLkTin0_e=b=c5bhp2jNndaKXrstCbkPg@mail.gmail.com>
	<BANLkTi=hnMBn__h08ka+V8Rzu6k7ahR64Q@mail.gmail.com>
	<BANLkTim-OHgybKO0xnC_P-1m-J0amupakA@mail.gmail.com>
	<BANLkTi=jK8zwbq=Mn5t=aXTZzWJLxGTpmQ@mail.gmail.com>
	<20110406150606.GA28955@lst.de> <4D9C8391.102@redhat.com>
	<20110406155249.GA29963@lst.de>
	<BANLkTinrOUmcXJf3PjCH8Yt1sQb5X3QwYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BANLkTinrOUmcXJf3PjCH8Yt1sQb5X3QwYg@mail.gmail.com>
Subject: Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <http://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Lyu Mitnick <mitnick.lyu@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

On Thu, Apr 07, 2011 at 07:10:00AM +0800, Lyu Mitnick wrote:
> Would you mind to share your solution about this feature?? My idea is
> replace
> all bdrv_pread(), bdrv_pwrite_sync(), bdrv_pwrite() in block/vpc.c to
> bdrv_pread_split(),  bdrv_pwrite_sync_split(), bdrv_pwrite_split()
> corresponding.
> bdrv_pread_split(),  bdrv_pwrite_sync_split(), bdrv_pwrite_split() should
> deal with
> data splitted at different files via bdrv_pread(), bdrv_pwrite_sync(),
> bdrv_pwrite(),
> give an interface of sequential byte accessed. Is it suitable to solve this
> issue??

For the synchronous bdrv_read/bdrv_write used in vmdk the problem actually
is rather trivial, as it already split it's reads/write on a cluster
boundary internally, and the higher level split is always alignment to
a cluster boundary.  So basically no new work there.