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

[Joel Becker]

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.

Joel

-- 

"There are some experiences in life which should not be demanded
 twice from any man, and one of them is listening to the Brahms Requiem."
        - George Bernard Shaw

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127