Re: [Xen-devel] Re: Getting xen to recognise large disks

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Tue, Nov 21, 2006 at 09:11:18PM +0000, Daniel P. Berrange wrote:
> On Tue, Nov 21, 2006 at 11:34:45AM +0000, Keir Fraser wrote:
> > On 21/11/06 11:21, "Robin Bowes" <robin-lists@xxxxxxxxxxxxxx> wrote:
> > 
> > > Keir Fraser wrote:
> > >> On 21/11/06 2:13 am, "Robin Bowes" <robin-lists@xxxxxxxxxxxxxx> wrote:
> > >> 
> > >> I'll make a patch today.
> > >> 
> > > 
> > > Thanks Keir, looking forward to testing it.
> > 
> > If you don't mind using the xen-unstable source repository, it's changeset
> > 12496:0c0ef61de06b. It probably hasn't reached the public repository just
> > yet (should very shortly though).
> 
> I've tested that changeset with the following
> 
>  - phy:  against a 5 TB partition
>  - file: against a 7.3 TB file
> 
> In both cases the # of sectors matches in Dom0 vs DomU. For good measure
> I also ran Stephen Tweedie's verify-data tool in the DomU to verify no
> data I/O wraparound issues elsewhere in the code & it passed without
> trouble.
> 
> Blktap, however, is a different story - it is showing wraparound for disk
> size at the 2 TB size mark stil. The userspace blktap tools have totally
> inconsistent data types. Sometimes using int, sometimes long, sometimes
> unsigned long & sometimes uint64. I'm working on a patch which makes it 
> 
>  - 'unsigned long long'  for # sectors
>  - 'unsigned long'       for sector size
>  - 'unsigned int'        for info
> 
> This makes it match the data types used in blkfront/blkback exactly.
> With this patch applied, the DomU sees correct disk size, however,
> the verify-data tool is showing nasty data consistency issues when
> writing/reading to such a disk. So I think there is 32-bit wrap
> around somewhere in the I/O codepath for blktap. I'll get back when
> I've found out more info...

It turns out that blktap wasn't (directly) at fault here. I was storing my
file based disk images on an XFS formatted partition in the host. Well it
appears that XFS doesn't play nice with the async I/O + O_DIRECT options
that blktap likes so all your data goes to /dev/null :-)

I re-tested blktap + large file backed disks on ext3 & GFS and everything
is working as expected. So stay away from a XFS+blktap combo if you like 
your data :-)


Attaching the patch to blktap to fix 32-bit wraparound of sector counts.

 Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

Attachment: blktap-2tb-2.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel