Asking for Help on Seeking to End of File

[Linlin Yan (颜林林)]

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?