XFS Best Practices

XFS Best Practices

[Jeff Flowers]

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 [1],
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.

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?



Thank you!

-- 
[1] http://everything2.com/title/Filesystem+performance+tweaking+with+XFS+on+Linux

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

Re: XFS Best Practices

[Eric Sandeen]

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 [1],
> 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.  :)

> 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.

-Eric

> Thank you!
> 

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

Re: XFS Best Practices

[Jeff Flowers]

On Thu, Aug 20, 2009 at 11:23 AM, Eric Sandeen<sandeen@sandeen.net> 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 [1],
>> 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).


>> 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.
>
> -Eric

Thanks for the information. Your explaination of write barries is one
of the better ones I have read.

-- 
Jeff

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

Re: XFS Best Practices

[Eric Sandeen]

Jeff Flowers wrote:
> On Thu, Aug 20, 2009 at 11:23 AM, Eric Sandeen<sandeen@sandeen.net> 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 [1],
>>> 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.
>>
>> -Eric
> 
> Thanks for the information. Your explaination of write barries is one
> of the better ones I have read.
> 

You're welcome :)

-Eric

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