Escalated to Bugzilla from IssueTracker
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 unlimited [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 6291456 [root@dl585 tmp]# dd if=/dev/zero of=testfile bs=1k count=$((4*1024*1024+1)) 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 fail): [root@dl585 tmp]# ulimit -f $((4*1024*1024-1)) [root@dl585 tmp]# ulimit -f 4194303 [root@dl585 tmp]# dd if=/dev/zero of=testfile bs=1k count=$((4*1024*1024)) 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 application. 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 failing. This event sent from IssueTracker by streeter issue 78136
Created attachment 118157 [details] Proposed patch
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.
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).
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. http://rhn.redhat.com/errata/RHSA-2006-0144.html