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: Linlin Yan (éææ) <yanll at mail dot cbi dot pku dot edu dot cn>
- To: Ãngel GonzÃlez <keisial at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Godmar Back <godmar at gmail dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 6 Jun 2014 08:18:05 +0800
- 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> <5390EF18 dot 7010306 at gmail dot com>
Indeed, it is very strange.
root@ngs ~ # multipath -ll
rd (36000d310001f43000000000000000016) dm-0 COMPELNT,Compellent Vol
size=90T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=active
|- 0:0:3:5 sda 8:0 active ready running
|- 0:0:5:5 sdb 8:16 active ready running
|- 2:0:3:5 sdc 8:32 active ready running
`- 2:0:5:5 sdd 8:48 active ready running
root@ngs ~ # mount | grep '/rd'
/dev/mapper/rd on /rd type xfs
(rw,noatime,usrquota,grpquota,logbsize=256k,logbufs=8,allocsize=1073741824,largeio)
root@ngs ~ # xfs_info /rd
meta-data=/dev/mapper/rd isize=256 agcount=96, agsize=251658240 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=24159191040, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
On Fri, Jun 6, 2014 at 6:28 AM, Ãngel GonzÃlez <keisial@gmail.com> wrote:
> 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?