Large files

[Miguel Barreiro]

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
>