xfs
[Top] [All Lists]

Re: largeio mount and performance impact

To: Sebastian Brings <sebas@xxxxxxxxxxxxxx>
Subject: Re: largeio mount and performance impact
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sat, 23 Sep 2006 11:34:23 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <55EF1E5D5804A542A6CA37E446DDC206655888@xxxxxxxxxxxxxxxxxxxxxx>
References: <55EF1E5D5804A542A6CA37E446DDC206655888@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 1.5.0.7 (Macintosh/20060909)
Sebastian Brings wrote:
In a different thread I read about the largeio mount option for XFS. Now
I wonder if the problems I recently ran in have been caused by this.

After a system uprgade from sles9 sp2 to sp3 one app started
misbehaving. Before the upgrade it used 15% CPU, after the upgrade it
was 90+% and the performance dropped by about 50%. The app is writing a
wave audio file, and for every 3840 bytes of audio samples it appends,
it updates the RIFF header of the file. All of this was done using the
buffered fopen/fwrite/... C library functions. An strace showed that seeking to the beginning of the file also
triggered a 12MiB read(2) call, and seeking to the end, for example to
13MiB, translated to a seek(2) to offset 1mib and a read(2) of 12 MiB.

Initiall I assumed something very strange had happened to the C lib
defaults. Otoh 12MiB is the swidth of the filesystem, so I assume that
the C lib got the 12 MiB optimal IO size from XFS and therefore behaved
as described above. Could that be?

Unless you specify the largeio mount option, I don't -think- any of this is 
exposed.

What does stat -c %o <file> say?

Did this strace behavior change from sp2 to sp3?

-Eric


<Prev in Thread] Current Thread [Next in Thread>