This is the mail archive of the
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: "Linda A. Walsh" <law at tlinx dot org>
- Cc: Ãngel GonzÃlez <keisial at gmail dot com>, 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: Sun, 20 Jul 2014 12:00:09 +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> <CA+YjnUs7bfSaAUyvLJCd0mkx9mzpSq2X==BqB6K_7mpYYpO74g at mail dot gmail dot com> <CA+YjnUtbnkr6e4FSsBJ3DXhYkNPGOOaqquX9DipsX7csnQMfiA at mail dot gmail dot com> <53CB3462 dot 5070401 at tlinx dot org>
Thank you very much for your clarifying the key point.
Our privous mount parameters are as following:
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 <email@example.com> wrote:
> Linlin Yan (éææ) wrote:
>> On Fri, Jun 6, 2014 at 8:18 AM, Linlin Yan (éææ)
>> <firstname.lastname@example.org> wrote:
>>> root@ngs ~ # mount | grep '/rd'
>>> /dev/mapper/rd on /rd type xfs
>> 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
> to the above in case someone else stumbles upon this thread.
> It's not the largeio, specifically that is causing the problem. By
> it won't cause that behavior.
> It's the allocsize
> 5.6. Mount Options - Large I/O
> These mount options affect the preferred filesystem I/O size reported by
> * 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