[Ocfs2-tools-devel] [PATCH 1/1] Ocfs2-tools: Let o2image.c also correctly deal with LARGEFILE.

[tristan.ye]

On Fri, 2009-02-27 at 16:15 +0800, Coly Li wrote:
> 
> Joel Becker Wrote:
> > On Fri, Feb 27, 2009 at 03:43:01PM +0800, tristan.ye wrote:
> >> On Fri, 2009-02-27 at 15:29 +0800, Coly Li wrote:
> >>> Joel Becker Wrote:
> >>>> On Tue, Feb 24, 2009 at 10:36:12AM +0800, Tristan Ye wrote:
> >>>>> We may not need to switch the open64() on by marco HAVE_OPEN64 here,
> >>>>> since actually the HAVE_OPEN64 seems never was defined in the scope of
> >>>>> o2image.c. To be more explicit, we simply could use open64() directly since
> >>>>> such 64bits utility will never affect on 32bits Linux.
> >>>>>
> >>>>> Signed-off-by: Tristan Ye <tristan.ye at oracle.com>
> >>>> This change is correct anyway, because _LARGEFILE64_SOURCE explicitly
> >>>> means we have open64().  If a system is broken enough not to have it, we
> >>>> just want to fail.
> >>>>
> >>> Since include/ocfs2/ocfs2.h declares _LARGEFILES64_SOURCE explicitly, can we say if:
> >>> 1) a source file includes "ocfs2/ocfs2.h"
> >>> 2) a device file (e.g. /dev/sda or /dev/sda1) to be opened
> >>> an open64() should be used other than open() ?
> >> Coly,
> >>
> >> We only need to use 64bits io system call alternatives where large io is
> >> going to happen, such as opening a LARGE file, growing a file up to 2G,
> >> etc.
> >>
> >> I personally think there is no need to use open64 to open a device
> >> special file, anyway, it may not hurt us if we use 64 bits io system
> >> calls everywhere since it only takes effect on a 32bits linux. Joel, how
> >> dou you think about it?
> > 
> > 	I personally use open64() everywhere.  You never know what might
> > happen, and it's easier to have open64() and never need it than to be
> > stuck with binaries using open() and failing at a 2G boundary.
> > 
> Oh, a more question: I only know lseek will fail at 2G limitation, will open() also fail on a >2GB
> file ?
> I just write a test code to open a 2.6G iso file, only open it with open(2) seems OK.

For a large file(more than 2G) on 32bits linux, a simple open() will not
fail, but with such a 32bits open(), following io operations such as
read, write,lseek etc will definitely failed at 2G boundary.

Could try to read the whole 2.6G until its end or just append some bits
to its end, i bet it will fail.

Since a 32bits linux use 32bits off_t for file offset, you need to have
a 64bit offset to deal with LARGEFILE , it can be acheived by following
two ways:

1) define _LARGEFILE64_SOURCE in the handler let 64bits io system call
available for 32bits system

2) use O_LARGEFILE option to open a file: e.g open(fname, O_RDWR |
O_LARGEFILE), it also will use a 64bits offset instead of 32bits off_t.

When you go over the ocfs2-tools src, you'll find we use the first way
for LARGEFILE support.


Regards,
Tristan
> 
> Thanks.