Re: Large files

[Andreas Dilger <adilger@clusterfs.com>]

On Jun 10, 2003  11:12 -0400, Richard B. Johnson wrote:
> > On Tue, Jun 10, 2003 at 09:57:57AM -0400, Richard B. Johnson wrote:
> > > With 32 bit return values, ix86 Linux has a file-size limitation
> > > which is currently about 0x7fffffff. Unfortunately, instead of
> > > returning from a write() with a -1 and errno being set, so that
> > > a program can do something about it, write() executes a signal(25)
> > > which kills the task even if trapped. Is this one of those <expletive
> > > deleted> POSIX requirements or is somebody going to fix it?
> >
> >   http://www.sas.com/standards/large.file/
> >
> > #define SIGXFSZ    25    /* File size limit exceeded (4.2 BSD). */
> >
> > from  fs/buffer.c:
> >
> >         err = -EFBIG;
> >         limit = current->rlim[RLIMIT_FSIZE].rlim_cur;
> >         if (limit != RLIM_INFINITY && size > (loff_t)limit) {
> >                 send_sig(SIGXFSZ, current, 0);
> >                 goto out;
> >         }
> >         if (size > inode->i_sb->s_maxbytes)
> >                 goto out;
> >
> >
> 
> On the system that fails, there are no ulimits and it's the root
> account, therefore I don't know how to set the above limit to
> RLIM_INFINITY (~0LU).  It's also version  2.4.20. I don't think
> it has anything to do with 'rlim' shown above. In any event
> sending a signal when the file-size exceeds some level is preposterous.
> The write should return -1 and errno should have been set to EFBIG
> (in user space). That allows the user's database to create another
> file and keep on trucking instead of blowing up and destroying the
> user's inventory or whatever else was in process.
> 
> FYI, this caused the failure of a samba server for M$ stuff. It
> gives the impression of Linux being defective. This is not good.

If your application is not compiled with O_LARGEFILE, you will also
get SIGXFSZ if you try to write past the 2GB limit.  This is to avoid
your application corrupting data by trying to store a 64-bit file
size in an (apparently) 32-bit data value (32-bit because you didn't
specify O_LARGEFILE).

I don't see anything in signal(7) which says that SIGXFSZ(25) can't be
caught and handled by the application, but at that point you may as
well just fix the app to just open the file with O_LARGEFILE and handle
64-bit file offsets properly.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/