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

[Coly Li]

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?
> 
When we read/write device file like /dev/sda or /dev/sda1, it's very often to be larger than 2GB.
Also it's quite common to read a data file exceed 2GB size. e.g. in blockcheck, where I still see a
suspicious open() :))

Thanks.
-- 
Coly Li
SuSE Labs