> -----Original Message-----
> From: Eric Sandeen [mailto:sandeen@xxxxxxxxxxx]
> Sent: Samstag, 23. September 2006 18:34
> To: Sebastian Brings
> Cc: xfs@xxxxxxxxxxx
> Subject: Re: largeio mount and performance impact
> Sebastian Brings wrote:
> > In a different thread I read about the largeio mount option for XFS.
> > 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
> > was 90+% and the performance dropped by about 50%. The app is
> > wave audio file, and for every 3840 bytes of audio samples it
> > it updates the RIFF header of the file. All of this was done using
> > 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
> > 13MiB, translated to a seek(2) to offset 1mib and a read(2) of 12
> > Initiall I assumed something very strange had happened to the C lib
> > defaults. Otoh 12MiB is the swidth of the filesystem, so I assume
> > the C lib got the 12 MiB optimal IO size from XFS and therefore
> > as described above. Could that be?
> Unless you specify the largeio mount option, I don't -think- any of
> is exposed.
> What does stat -c %o <file> say?
> Did this strace behavior change from sp2 to sp3?
Stat seems to report 12MB:
# stat -c %o sebastian.tgz
Mount does not have largeio set explicitly. But this is a CXFS, so this
may change tings:
/dev/cxvm/fs1 on /shares/fs1 type xfs
I don't have strace data from the app running under sp2. But changing
the default library buffer size to a more reasonable size after the
fopen(), the app behaved normal again.