Try to compile your C code with -D_FILE_OFFSET_BITS=64
On Wednesday 06 September 2006 06:08, Andreas Fink wrote:
> Vincent says:
> >> - logrotate is your friend... :)
> >> - or use 64 bits arch
>
> 1. Logrotate is already my friend (it was misconfigured though...)
> 2. 64bit architecture is not a limit for having larger files. MacOS X
> on intel has no problem creating such large files.
>
> On 06.09.2006, at 02:34, Mi Reflejo wrote:
> > The 2gb limit is in 32-bit cpu: Most exactly in libc, kernel fs
> > drivers and VFS layer.
>
> This is not correct anymore. The kernel is running 32bit (but is
> actually a AMD Opteron with EMT64 support) but can deal with large
> filesystems. The filesystem also supports file larger than 2GB
> (people using VMWAre would cry otherwise). So the only location left
> is in libc.
>
> See this:
> Let me create a file larger than 2G
>
> $ dd if=/dev/zero of=test bs=1M count=2050
> 2050+0 records in
> 2050+0 records out
> 2149580800 bytes (2.1 GB) copied, 48.2032 seconds, 44.6 MB/s
> [EMAIL PROTECTED] ~]$ ls -l test
> -rw-rw-r-- 1 afink afink 2149580800 Sep 6 05:42 test
> [EMAIL PROTECTED] ~]$
>
> So we can create files larger than 2GB on that filesystem. This was
> not the case in 2001 when I run into that problem too where the
> filesystem was really the limit. So it can not be kernel, not
> filesystem. So it must be a libc limitation but for appending data to
> a existing file, it sounds rather strange to me that fprintf has this
> limit. Lets test this with a small piece of C:
>
> #include <stdio.h>
> #include <errno.h>
>
> main()
> {
> FILE *f;
> int i;
>
> f = fopen("test.bin","a");
>
> if(f==NULL)
> {
> fprintf(stderr,"could not open file\nerrno= %d
> \n",errno);
> return -1;
> }
> fseek(f,0,SEEK_END);
> for(i=0;i<1000;i++)
> {
> fprintf(f,"The world is nice\n");
> }
> fclose(f);
> }
>
> This code shows that when I do a fopen on the 2.1GB file, I get an
> error 27 back. ( EFBIG). So it must be libc issue. However libc is
> used on my other platforms too and doesnt show this behaviours.
>
> As "dd" has no probelm, Kannel can be made not having a problem too.
> Furthermore, Kannel should not crash in that scenario which it
> currently does.
> And Kannel doesnt recover from that crash after a restart because the
> logfile doesnt change its size (we dont truncate it). So using the
> box around the box to autorestart it, wont solve it.
