Bug 672917

Summary: hardlink does not link files larger than 1 GB
Product: Red Hat Enterprise Linux 5 Reporter: Pim Zandbergen <p.zandbergen>
Component: hardlinkAssignee: Jan Zeleny <jzeleny>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 5.6CC: jzeleny, p.zandbergen
Target Milestone: rc   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-02 13:21:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch to let hardlink manipulate with 1GiB+ files on i386 none

Description Pim Zandbergen 2011-01-26 17:31:12 UTC 
Description of problem:

hardlink does not link files larger than 1 GB.
For files larger than 1 GB but smaller than 2 GB,
an error is printed "Failed to mmap <filename>.
File sized 2GB or larger are silently ignored.


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

How reproducible:
Always


Steps to Reproduce:
1. Create linkable files of various sizes
for i in 512 1024 1536 2048
do
 dd if=/dev/zero of=$i.dat bs=1024k count=$i
 cp $i.dat $i.dat.bak
done
2. hardlink -vvc .

  
Actual results:
Failed to mmap ./1536.dat.bak
Linked ./1024.dat.bak to ./1024.dat, saved 1073741824
Linked ./512.dat to ./512.dat.bak, saved 536870912


Expected results:
All files linked, no error messages


Additional info:
Same problem with hardlink-1.0-9.fc12.i686 on Fedora 14 i686
Comment 1 Jindrich Novy 2011-01-27 07:20:24 UTC 
Does it fail for you if you set "ulimit -v unlimited" ?

With unlimited virtual memory I get:
$ hardlink -vvc .
Linked ./512.dat to ./512.dat.bak, saved 536870912
Linked ./2048.dat to ./2048.dat.bak, saved 2147483648
Linked ./1536.dat.bak to ./1536.dat, saved 1610612736
Linked ./1024.dat.bak to ./1024.dat, saved 1073741824


Directories 1
Objects 10
IFREG 9
Mmaps 4
Comparisons 4
Linked 4
saved 5368709120
Comment 2 Pim Zandbergen 2011-01-27 10:02:22 UTC 
Fails too; ulimit -v is already unlimited.

I should have mentioned hardlink does not fail on x86_64.
You need to test on i686.
Comment 3 Pim Zandbergen 2011-01-27 10:11:46 UTC 
I suppose this has to do with the 2GB addressing limit for 32-bit processes.

This may not be circumvented when using mmap().
If so, I would suggest to at least print a more clear error message
for files > 1GB && < 2GB, and to not silently ignore files > 2GB
Comment 4 Jindrich Novy 2011-03-04 11:23:26 UTC 
Created attachment 482274 [details]
Patch to let hardlink manipulate with 1GiB+ files on i386

This could be fixed quite easily by replacing mmap() with read(). Please test.
Comment 5 Pim Zandbergen 2011-03-21 17:55:31 UTC 
Yes it works. Thanks.
Comment 6 RHEL Program Management 2013-05-01 06:52:38 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 7 RHEL Program Management 2014-03-07 13:47:02 UTC 
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Comment 8 RHEL Program Management 2014-06-02 13:21:23 UTC 
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).
Comment 9 Pim Zandbergen 2014-06-23 11:18:37 UTC 
This issue is fixed and should have been closed as fixed.