Re: xfs performance problem

[Christoph Hellwig <hch@infradead.org>]

On Sun, May 01, 2011 at 06:52:46PM +1000, Dave Chinner wrote:
> > > more than likely your problem is that barriers have been enabled for
> > > MD/DM devices on the new kernel, and they aren't on the old kernel.
> > > XFS uses barriers by default, ext3 does not. Hence XFS performance
> > > will change while ext3 will not. Check dmesg output when mounting
> > > the filesystems on the different kernels.
> > 
> > But didn't 2.6.38 replace barriers by explicit flushes the filesystem has to 
> > wait for - mitigating most of the performance problems with barriers?
> 
> IIRC, it depends on whether the hardware supports FUA or not. If it
> doesn't then device cache flushes are used to emulate FUA and so
> performance can still suck. Christoph will no doubt correct me if I
> got that wrong ;)

Mitigating most of the barrier performance issues is a bit of a strong
word.  Yes, it remove useless ordering requirements, but fundamentally
you still have to flush the disk cache to the physical medium, which
is always going to be slower than just filling up a DRAM cache like
ext3's default behaviour in mainline does (interestingly both SLES
and RHEL have patched it to provide safe behaviour by default).

Both the old barrier and new flush code will use the FUA bit if
available, and those optimize the post-flush for a log write out.
Note that currently libata by default always disables FUA support,
even if the disk supports it, so you'll need a SAS/FC/iSCSI/etc
device to actually see FUA requests, which is quite sad as it
should provide a nice speedup epecially for SATA where the cache
flush command is not queueable and thus requires us to still
drain any outstanding I/O at least for a short duration.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs