Re: Asking for Help on Seeking to End of File

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

Hi Linda,

Thank you very much for your clarifying the key point.

Our privous mount parameters are as following:
   rw,noatime,usrquota,grpquota,logbsize=256k,logbufs=8,allocsize=1073741824,largeio
which was inherited from other servers maintained by another ex-technician.

These high performance servers are used for scientific computing on
large genomic data, which are usually dozens of gigabytes. Therefore
we thought big "allocsize" and "largeio" should help a lot (however,
it is embarrassing that we seem to have not tested it precisely yet).

In the past, the "allocsize" was set to about 256M in order to make it
cache as much as possible to improve the I/O speed. On the new server
on which the performance problem occured, I enlarged the "allosize"
because it has much larger memory than other servers. Out of my
expectation, the I/O performance of some programs that open and read a
few bytes repeatly behaviors badly.

In conclusion, I feel it was a misuse of both "allocsize" and
"largeio". Now the mount parameters are almost the same as above,
except without "largeio". It behaviors normal now.

On Sun, Jul 20, 2014 at 11:15 AM, Linda A. Walsh <law@tlinx.org> wrote:
> Linlin Yan (éææ) wrote:
>>
>> On Fri, Jun 6, 2014 at 8:18 AM, Linlin Yan (éææ)
>> <yanll@mail.cbi.pku.edu.cn> wrote:
>>>
>>> root@ngs ~ # mount | grep '/rd'
>>> /dev/mapper/rd on /rd type xfs
>>>
>>> (rw,noatime,usrquota,grpquota,logbsize=256k,logbufs=8,allocsize=1073741824,largeio)
>>>
>>>
>>
>> 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.
>>
>
> ---
>    I know this is over a month past the post, but wanted to post a
> correction
> to the above in case someone else stumbles upon this thread.
>
>    It's not the largeio, specifically that is causing the problem.  By
> itself
> it won't cause that behavior.
>
>    It's the allocsize
> (from
> http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/ch05s06.html):
>
>
> 5.6. Mount Options - Large I/O
>
> These mount options affect the preferred filesystem I/O size reported by
> stat(2)
> largeio
>    *   A filesystem that has a swidth specified will return the swidth value
> (in bytes) in st_blksize
>    *   If the filesystem does not have a swidth specified but does specify
> an allocsize then allocsize (in bytes) will be returned instead.
>
> nolargeio (default)
>    *  The optimal I/O reported in st_blksize will be as small as possible to
> allow user applications to avoid inefficient read/modify/write I/O.
>
> If neither of these two options are specified, then the filesystem will
> behave as if nolargeio was specified.
> ----
>
> I.e. when the filesystem was mounted, someone specified that the file
> system should try to make spaced for 1GB when it allocates space.
> This would be great for files of 1GB in size, but not likely what you
> want.  I.e. largeio is designed to help xfs lay files out on disk
> to prevent fragmentation by leaving space available for expansion
> at the end of the file (controlled by the user on mount).
>
> You might find out who or what was causing the file system to be
> mounted with allocsize=1GB
>
>