public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Jeff Flowers <ragepie@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: XFS Best Practices
Date: Thu, 20 Aug 2009 10:58:10 -0500	[thread overview]
Message-ID: <4A8D7292.70806@sandeen.net> (raw)
In-Reply-To: <a0531a500908200845m5dbc4356o278cb6c90d2925f9@mail.gmail.com>

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

      reply	other threads:[~2009-08-20 15:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-20 15:00 XFS Best Practices Jeff Flowers
2009-08-20 15:23 ` Eric Sandeen
2009-08-20 15:45   ` Jeff Flowers
2009-08-20 15:58     ` Eric Sandeen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A8D7292.70806@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=ragepie@gmail.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox