RE: largeio mount and performance impact

Sebastian Brings
2006-09-24T13:48:50Z

> -----Original Message-----
> From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf
Of
> Sebastian Brings
> Sent: Sonntag, 24. September 2006 15:42
> To: Eric Sandeen
> Cc: xfs@oss.sgi.com
> Subject: RE: largeio mount and performance impact
>
> > -----Original Message-----
> > From: Eric Sandeen [mailto:sandeen@sandeen.net]
> > Sent: Samstag, 23. September 2006 18:34
> > To: Sebastian Brings
> > Cc: xfs@oss.sgi.com
> > Subject: Re: largeio mount and performance impact
> >
> > 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
>
>
> Stat seems to report 12MB:
>
> # stat -c %o sebastian.tgz
> 12582912
>
> 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
> (rw,noatime,client_timeout=1s,retry=0,server_list=(meta01,
> meta02),filestreams,quota,mtpt=/shares/fs1)
>
>
> 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.
>
>
> Sebastian
>

Now I remember. Filestreams was added during the update. Maybe that
makes the difference. Anyways, I just wanted to point out that largeio
mount option may have unexpected side effects

Sebastian