Re: Asking for Help on Seeking to End of File

[Linlin Yan (éææ) <yanll at mail dot cbi dot pku dot edu dot cn>]

Thank you everyone!

I have finally found the problem. It is due to the mount parameter
"largeio" of the xfs file system. I tried to remove this parameter
before by running command "mount /dev/mapper/rd /rd -o remount", but
with no any effect. This time, I unmount the device and mount it again
without "largeio". It behaviours efficiently as expect now.

On Fri, Jun 6, 2014 at 8:18 AM, Linlin Yan (éææ)
<yanll@mail.cbi.pku.edu.cn> wrote:
> 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?