Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454928 - kpartx doesn't work on large volumes
Summary: kpartx doesn't work on large volumes
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper-multipath
Version: 5.2
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Ben Marzinski
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-10 20:11 UTC by Chris St. Pierre
Modified: 2010-01-12 02:43 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 22:09:29 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2009:0232 normal SHIPPED_LIVE device-mapper-multipath bug-fix and enhancement update 2009-01-20 16:06:34 UTC

Description Chris St. Pierre 2008-07-10 20:11:00 UTC
Description of problem:

kpartx errors out on files 2Gb or larger (on 32-bit) or 8Gb or larger (on 64-bit) 
with the cryptic error:

failed to stat() <filename>

Giving it the -v flag does not give any more output.

I have replicated this on Fedora 8 and 9 as well.

Version-Release number of selected component (if applicable):

kpartx-0.4.7-17.el5

How reproducible:

Every time.

Steps to Reproduce:

1. Create a file 2Gb or larger on a 32-bit system, or 8Gb or larger on a 64-bit 
system.
2. Run kpartx on it.
3. Fail!
  
Actual results:

Fails to stat:

# dd if=/dev/zero of=2g.img bs=1024M count=2
2+0 records in
2+0 records out
2147483648 bytes (2.1 GB) copied, 45.3624 seconds, 47.3 MB/s
# kpartx -l 2g.img
failed to stat() 2g.img

Expected results:

It works with files just under 2Gb:

# dd if=/dev/zero of=almost2g.img bs=1000M count=2
2+0 records in
2+0 records out
2097152000 bytes (2.1 GB) copied, 45.1009 seconds, 46.5 MB/s
# kpartx -l almost2g.img

Additional info:

The results I pasted were from a 32-bit machine.  It works exactly the same with 
a 8Gb threshold on 64-bit machines.

This really sucks, since kpartx _would be_ a great tool for working with virtual 
machines, if it worked on large files.  But we use 10 Gb files for our VMs (which 
is even smaller than a lot of people), so we can't mount them on 32- or 64-bit 
systems.

If there's a workaround we can use in the mean time, I'd appreciate that, too.

This has been reported to CentOS as well, but without any activity: http://
bugs.centos.org/view.php?id=2882

Comment 1 RHEL Product and Program Management 2008-07-14 19:13:30 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 2 Ben Marzinski 2008-08-26 03:51:21 UTC
Fixed. Kpartx now uses the 64bit versions of the file access functions.

Comment 5 errata-xmlrpc 2009-01-20 22:09:29 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0232.html


Note You need to log in before you can comment on or make changes to this bug.