[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Getting xen to recognise large disks
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |