PosixSequentialFile::Skip(uint64_t n)

[GoogleCodeExporter]

The method PosixSequentialFile::Skip(uint64_t n) uses fseek, which is defined 
as:

int fseek(FILE *stream, long offset, int whence);

The problem is that "offset" is 4 bytes in 32bit machines.

Wouldn't it be better to use fseeko?

int fseeko(FILE *stream, off_t offset, int whence);

and in the Makefile have:
-D_FILE_OFFSET_BITS=64

Original issue reported on code.google.com by guido.re...@yahoo.com on 29 May 2013 at 4:38

[GoogleCodeExporter]

Does this show up on some profiling that you've done? Would using fseeko bring 
about a noticeable performance boost?

Original comment by dgrogan@chromium.org on 29 May 2013 at 2:20

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It doesn't show up in any profiling, nor is it a performance boost. I was just 
reading the code and learning how it works when I saw that.

What I think might be a problem is that, as a "long" is only 4 bytes in a 32 
bit machine, if the parameter "n" is greater than 2^31 (it is an uint64t_n), it 
might wrap around

Original comment by guido.re...@yahoo.com on 30 May 2013 at 5:56

[GoogleCodeExporter]

Given how LevelDB works, it strikes me as unlikely that a 32-bit system would 
end up having files large enough for -D_FILE_OFFSET_BITS=64 or fseeko to matter.

Original comment by cbsm...@gmail.com on 4 Oct 2013 at 11:30

[GoogleCodeExporter]

I think I've run into this issue. I'm doing a large batch import on a 64Bit 
machine. This causes the log file to grow over 2GB. If I use this database on a 
32Bit machine befor compaction has finished I get an error.

I'm interestd in a fix for this ;)

Original comment by ingemar....@philotech.de on 2 Dec 2013 at 10:15