+++ 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):
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
The #blocks column for the disk is different in DomU & Dom0
The #blocks seen in DomU matches #blocks seen in Dom0
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
Created attachment 141715 [details]
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)
to the disk section of an existing guest.
Finally boot the guest & compare /proc/partitions for this device in the Dom0 &
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
Patch added in xen-unstable
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:
Created attachment 141846 [details]
Patch to fix large blktap disks
This additional patch fixes blktap based disks which are > 2TB
Please post for ACKs
QE ack for RHEL5.
Created attachment 142572 [details]
Patch to fix blkback driver handling of > 2tb disk
The equivalent userspace blktap patches are tracked in a separate bug 217580
2.6.18-7.el5 included in 20070125.0.