Red Hat Bugzilla – Bug 166067
Can not write a buffer beyond 2 giga bytes in a C program (if kernel version >= 2.6.11)
Last modified: 2007-11-30 17:11:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.8) Gecko/20050718 Firefox/1.0.4 (Debian package 1.0.4-2sarge1)
Description of problem:
After updating the kernel version >= 2.6.11 (so FC3 has the
same problem), under a C program, when I use write() or fwrite()
(or some other low level C write fonction) to write a buffer
beyond 2147483648 bytes, program fails with error message
: invalid argument.
Solution I used now is just downgrading to a 2.6.10 kernel.
My Athlon64 box config: 4 Giga bytes memory with a athlon64 3500+.
int main (int argc, char *argv)
size_to_wrt = 2147483648; /* can not beyond 2147483647 bytes */
buffer_to_wrt = malloc(size_to_wrt);
if(buffer_to_wrt == NULL) printf("Malloc error\n");
fd = open(argv, O_CREAT | O_RDWR, S_IRUSR|S_IWUSR);
size_wrten = write(fd, buffer_to_wrt, size_to_wrt);
if(size_wrten != size_to_wrt)
printf("Error message: %s\n", strerror(errno));
Version-Release number of selected component (if applicable):
if kernel version >= 2.6.11
Steps to Reproduce:
1. A athlon64 PC has more that 2 Gbytes memory.
2. Compile ths sample C program.
(cc -o test_64bit_write test_64bit_write.c)
3. Execute with: test_64bit_write foo.
Actual Results: error message
test_64bit_write : invalid argument.
Expected Results: Program pass.
Is there any genuine need for this? This change was a deliberate upstream
decision, made after one or two code paths in the kernel were found which didn't
handle >=2GB IOs correctly. Our policy is to follow upstream behaviour in all
In many industrial code we do need some kind of the
IO stream copy between the memory and storage device,
specially for a 64 bit program this kind of the
application comes soonly.
Certainly we can loop the I/O by buffer of 2Gb, but
this should not be done in a high level application,
but at some low level system IO menagement.
Thanks for any opinion.
Anyway, the error message should be more explit
--- I had spend hours to found this.
POSIX simply does not provide such fine-grained error codes; EINVAL is the
closest one available. Unix in general just doesn't have a mechanism for
reporting errors with such specificity.
Our behaviour in this case is going to continue to match upstream. It's
certainly worth asking on the linux kernel mailing lists if you think this
restriction is inappropriate.