Jeff Flowers wrote:
> On Thu, Aug 20, 2009 at 11:23 AM, Eric Sandeen<sandeen@xxxxxxxxxxx> wrote:
>> Jeff Flowers wrote:
>>> I am going to use XFS on a Arch Linux box and I am looking for ways to
>>> maximize XFS performance. According to an article I have read ,
>>> best XFS performance was reached with a file system formatted with a
>>> 64MB log and mounted with 8 log buffers and atime disabled. But I am
>>> curious, from the prespective of the XFS experts of this list, if this
>>> is still good advice and if it is still relevant, as this article was
>>> published in 2003.
>> Based on the information you've provided about the performance issues
>> you're seeing with your particular workload (i.e., nothing), the
>> existing defaults are perfect for you. :)
> For me, it is not about dissatisfaction with XFS performance but
> simply wanting to know if there are optimizations I am missing and
> could be taking advantage of. Many forums have people talking about
> options to improve or optimize Ext3 and Ext4 performance but XFS seems
> to be dismissed (which I don't understand, as XFS is a very mature and
> proven filesystem).
Sure, but the point is, if there is some all-encompassing "tweak" or
optimization to be made, it is already a default in xfs.
Tuning beyond defaults is usually about tradeoffs, and making those
tradeoffs depends on what you actually want to do with the filesystem.
It's not meant to be snarky, but by and large the defaults for xfs
really do match most normal usage scenarios, and looking for tips &
tweaks isn't usually necessary IMHO.
>>> Also, I have seen a few people recommend turning off the internal
>>> buffers of hard drives (via hdparm) when using a file system like XFS.
>>> Good advice?
>> When drive write caches lose power it may lead to inconsistencies in a
>> journaling filesystem like xfs, which relies on data hitting the disk in
>> a certain order, more or less. By default xfs issues barriers to
>> enforce this ordering; this has the effect of flushing the write cache
>> to make it safe. In some cases disabling barriers and also disabling
>> write cache may be a good choice.
>> If you "never" lose power (good ups?) then write caching is safe even
>> w/o barriers.
> Thanks for the information. Your explaination of write barries is one
> of the better ones I have read.
You're welcome :)