This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Asking for Help on Seeking to End of File
- From: Ãngel GonzÃlez <keisial at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: "Linlin Yan (éææ)" <yanll at mail dot cbi dot pku dot edu dot cn>, Godmar Back <godmar at gmail dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 06 Jun 2014 00:28:40 +0200
- Subject: Re: Asking for Help on Seeking to End of File
- Authentication-results: sourceware.org; auth=none
- References: <CA+YjnUuUj_LeGTtGbuuOQy=YFR3HQ7ZHJ7h8XP1Y1ssEQA1Ryw at mail dot gmail dot com> <CAB4+JY+2Dhg1uo-+jputmfSjFtCMBFc7WQ1E3y1WXFYqZadiJQ at mail dot gmail dot com> <CA+YjnUs_CX4E14-JyrHXg8QeoL0YuaGpYFgRYVs7PJ3TCqN3cg at mail dot gmail dot com> <CAAHN_R0t8X7uN=J-JfLVZbt+_dB+uG0hybX2iq5VF_sZprV4bQ at mail dot gmail dot com>
On 05/06/14 18:13, Siddhesh Poyarekar wrote:
The lseek value is rounded on the block size boundary, so a file
system with smaller block size will tend to have a smaller residual
read(). The idea there is to buffer the following block so that it is
faster to read from. Kernel based prefetch in Linux (readahead) seems
to make this redundant, so maybe this buffering is not useful anymore.
Siddhesh
Reading at the block-size boundary should be no problem, since the kernel
will have to read the whole block. However, I find very odd that their
ha server
has a block size of 1 GB (faked by some wrapping layer perhaps?).
Linlin Yan, can you check what is the block size reported for that fs?