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...
Regards,
Dan.
[1] http://people.redhat.com/sct/src/verify-data/
-- 
|=- 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  -=| 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
 
 |