Bug 166600 - CRM619504: setrlimit RLIMIT_FSIZE limited to 32-bit values, even on 64-bit kernels
CRM619504: setrlimit RLIMIT_FSIZE limited to 32-bit values, even on 64-bit ke...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Staubach
Brian Brock
Depends On:
Blocks: 168424
  Show dependency treegraph
Reported: 2005-08-23 14:38 EDT by Issue Tracker
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2006-0144
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 11:28:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (900 bytes, patch)
2005-08-26 10:21 EDT, Peter Staubach
no flags Details | Diff

  None (edit)
Description Issue Tracker 2005-08-23 14:38:31 EDT
Escalated to Bugzilla from IssueTracker
Comment 5 Issue Tracker 2005-08-23 14:38:40 EDT
From User-Agent: XML-RPC

Here's a summary of the issue based on my analysis. I did all this on an
x86_64 system running RHEL3-U5.

Creating a file > 4GB works when ulimt -f is unlimited:

[root@dl585 tmp]# ulimit -f


[root@dl585 tmp]# dd if=/dev/zero of=testfile bs=1k count=$((5*1024*1024))
5242880+0 records in

5242880+0 records out

[root@dl585 tmp]# ls -lh testfile

-rw-r--r--    1 root     root         5.0G Sep  2 10:35 testfile

When the ulimit is not unlimitied but is greater than 4GB, creating a file
> 4GB (whether or not it is less than the ulimit) fails with "No space
left on device" (but there is space left on the device):

[root@dl585 tmp]# ulimit -f $((6*1024*1024))

[root@dl585 tmp]# ulimit -f


[root@dl585 tmp]# dd if=/dev/zero of=testfile bs=1k

dd: writing `testfile': No space left on device

4194305+0 records in

4194304+0 records out

[root@dl585 tmp]# ls -lh testfile

-rw-r--r--    1 root     root         4.0G Sep  2 10:41 testfile

Creating a file larger than the ulimit when the ulimit is less than 4GB
fails with "File size limit exceeded" (this is the way it is supposed to

[root@dl585 tmp]# ulimit -f $((4*1024*1024-1))

[root@dl585 tmp]# ulimit -f


[root@dl585 tmp]# dd if=/dev/zero of=testfile bs=1k

File size limit exceeded

[root@dl585 tmp]# ls -l testfile

-rw-r--r--    1 root     root     4294966272 Sep  2 10:44 testfile

 So I don't think the problem is with *setting* the limit (it appears at
least to report as correctly set). Something breaks in file I/O when the
limit is 4GB or greater, but not when it is unlimited.

It also doesn't appear to matter if you're running a 32bit or 64bit

 I'm afraid I've reached the end of my ability to debug this. I have to
pass it up to Engineering, who might have a better idea where this is

This event sent from IssueTracker by streeter
 issue 78136
Comment 7 Peter Staubach 2005-08-26 10:21:01 EDT
Created attachment 118157 [details]
Proposed patch
Comment 8 Peter Staubach 2005-08-26 10:39:15 EDT
The problem was that the arithmetic used to calculate the offset and count
values was being artificially constrained to unsigned 32 bit values.  It
should have been using unsigned long values, which would then scale
appropriately on 64 bit architectures.

I also eliminated an unnecessary test.
Comment 14 Ernie Petrides 2005-09-30 02:42:18 EDT
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.4.EL).
Comment 17 Red Hat Bugzilla 2006-03-15 11:28:39 EST
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 the 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.


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