Large files

[Raimo Niskanen]

Ok, elaborating...

To activate cpu_timestamp the process has to activate micro-level-
process accounting like this (from sys.c):
    int sys_start_hrvtime(void)
    {
        long msacct = PR_MSACCT;
        int fd;
    
        if ( (fd = open("/proc/self", O_WRONLY)) == -1) {
    	return -1;
        }
        if (ioctl(fd, PIOCSET, &msacct) < 0) {
    	close(fd);
    	return -2;
        }
        close(fd);
        return 0;
    }
that is: write an ioctl to the /proc filesystem,
and in the lfcompile(5) man page it says:

NOTES
     Certain system-specific or non-portable interfaces  are  not
     usable  in  the  large  file compilation environment.  Known
     cases are:
:
:
        o  Interfaces to /proc defined in <procfs.h>.

     Programs that use these interfaces should not be compiled in
     the  large file compilation environment.  As a partial safe-
     guard against making this mistake, including either  of  the
     <libelf.h> or <sys/procfs.h> header files will induce a com-
     pilation error when the large file  compilation  environment
     is enabled.

So, the configure test for this feature does not even compile.

We will try to work around this problem by compiling just the
file containing sys_start_hrvtime without the large file
compilation flags -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64,
and hope that file still can be linked with the others and
that it works.

...elaboration done.

> Raimo Niskanen wrote:
> 
> > This feature was actually on its way into R10B-9, but in the last
> > minute it turned out that it broke the possibility of using
> > cpu_timestamp on call traces, so we are working on an improved
> > solution...
> 
> Could you please elaborate on how the cpu_timestamp trace option interacts with
> this? I'm intrigued.
> 
> > > Hi,
> > >
> > > Support for large files (large being >= 2GB which is actually "moderately
> > sized
> > > files" these days) works ok on 64-bit systems. Doesn't anyone else use
> > large
> > > files on 32-bit systems? In case people is interested it works with the
> > > following recipe:
> > > - Either patch the file driver to open files with O_LARGEFILE and change a
> > > couple variables from off_t to off64_t and make sure they are correctly
> > packed
> > > into 64-bit commands and responses or, much simpler:
> > > $ export CFLAGS="-D_FILE_OFFSET_BITS=64" ; ./configure ; make
> > > (remember to use clean sources). See the libc documentation for details on
> > the
> > > _FILE_OFFSET_BITS flag.
> > >
> > > - Apply the attached patch to make file:position/2 work correctly
> > (everything
> > > else works without the patch, AFAIK). Currently
> > > erts/emulator/drivers/common/efile_drv.c packs the return value of lseek(2)
> > > using reply_Uint (which BTW is a bit misleading -- Uint is typedef'ed to a
> > > pointer-sized variable and not an unsigned int as I would tend to expect.
> > These
> > > don't always match). The return value of lseek is off_t which may not be
> > Uint
> > > sized, so I added a reply_off_t function.
> > > Patch generated against R108-B.
> > >
> > >
> > > Regards,
> > >
> > > Miguel
> > >
> >
> > --
> >
> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
> >
> 
> 
> 

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB