Bug 217580

Summary: blktap backed disk size wraps around at 2 TB mark
Product: Red Hat Enterprise Linux 5 Reporter: Daniel Berrangé <berrange>
Component: xenAssignee: Daniel Berrangé <berrange>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 5.0CC: sct, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: RC Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-02-08 00:59:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 216556    
Bug Blocks:    

Description Daniel Berrangé 2006-11-28 20:01:24 UTC
+++ This bug was initially created as a clone of Bug #216556 +++

+++ This bug was initially created as a clone of Bug #216555 +++

Description of problem:
If I create a virtual disk (either a file, or block device backed) in the dom0
host with a size of 5 TB, and export this to a guest DomU, the domu will only
see it as being 1 TB in size. It looks as if the Xen virtual disk driver is
wrapping around at the 2 TB mark.

Version-Release number of selected component (if applicable):
xen-3.0.3-0.1.rc3
kernel-xen-2.6.18-1.2849.fc6

How reproducible:
Always (on 32-bit)

Steps to Reproduce:
1. Create an block device 7 TB in size
2. Export this to the DomU in the guest config file
3. Look at /proc/partitions inside the guest kernel
4. Look at /proc/partitions in the dom0 host kernel
  
Actual results:
The #blocks column for the disk is different in DomU & Dom0

Expected results:
The #blocks seen in DomU matches #blocks seen in Dom0

Additional info:
The same problem occurs for file backed virtual disks on 32-bit host/guest.

There is no problem on 64-bit kernels - I have exported disks as large as 15 PB
 to the guest.

This is all testing with paravirt guests. Not verified if fully virt guests have
any issues yet.


Post from Ian upstream suggests 32-bit wraparound in blkfront driver

http://lists.xensource.com/archives/html/xen-devel/2006-11/msg01023.html

-- Additional comment from berrange on 2006-11-20 20:39 EST --
Created an attachment (id=141715)
Script to create huge block devices with device mapper trickery

The attached script is useful for reproducing the problems.

First create a data file to store the actual data, say 10 GB in size

  * dd if=/dev/null of=/xen/scratch.img bs=1 count=0 seek=10GB

Setup as loop device

  * losetup /dev/loop0 /xen/scratch.img

Now, create  a huge (5 TB) device backed by this small file

  * sparse_create xenhuge  /dev/loop0 $(echo 2000*1000*1000*5 | bc)

Then, add

    'phy:/dev/mapper/xenhuge,xvdb,w' 

to the disk section of an existing guest.

Finally boot the guest & compare /proc/partitions for this device in the Dom0 &
DomU.


-- Additional comment from pm-rhel on 2006-11-20 21:00 EST --
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

-- Additional comment from berrange on 2006-11-21 07:40 EST --
Patch added in xen-unstable

http://xenbits.xensource.com/xen-unstable.hg?cs=0c0ef61de06b

-- Additional comment from berrange on 2006-11-21 17:45 EST --
I have tested the patch listed in comment #3 and confirmed it fixes operation of
file: and phy: backed disks > 2 TB in size. It does not, however, fix tap:aio:
backed disks.


-- Additional comment from berrange on 2006-11-21 17:46 EST --
Created an attachment (id=141846)
Patch to fix large blktap disks

This additional patch fixes blktap based disks which are > 2TB

Comment 1 Daniel Berrangé 2006-11-28 20:02:56 UTC
Cloned this bug from 216556, because that bug was for the kernel fixed. Blktap
is in userspace though, so needs the corresponding fix in Xen RPM.

The neccessary fix is upstream now:

http://xenbits.xensource.com/xen-unstable.hg?cs=4666710bfc55


Comment 2 RHEL Program Management 2006-11-28 20:30:23 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 4 Jay Turner 2006-12-01 14:26:41 UTC
QE ack for RHEL5.

Comment 5 RHEL Program Management 2007-02-08 00:59:32 UTC
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.


Comment 6 Stephen Tweedie 2007-03-16 13:10:56 UTC
*** Bug 232608 has been marked as a duplicate of this bug. ***