* XFS Best Practices @ 2009-08-20 15:00 Jeff Flowers 2009-08-20 15:23 ` Eric Sandeen 0 siblings, 1 reply; 4+ messages in thread From: Jeff Flowers @ 2009-08-20 15:00 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XFS Best Practices 2009-08-20 15:00 XFS Best Practices Jeff Flowers @ 2009-08-20 15:23 ` Eric Sandeen 2009-08-20 15:45 ` Jeff Flowers 0 siblings, 1 reply; 4+ messages in thread From: Eric Sandeen @ 2009-08-20 15:23 UTC (permalink / raw) To: Jeff Flowers; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XFS Best Practices 2009-08-20 15:23 ` Eric Sandeen @ 2009-08-20 15:45 ` Jeff Flowers 2009-08-20 15:58 ` Eric Sandeen 0 siblings, 1 reply; 4+ messages in thread From: Jeff Flowers @ 2009-08-20 15:45 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: XFS Best Practices 2009-08-20 15:45 ` Jeff Flowers @ 2009-08-20 15:58 ` Eric Sandeen 0 siblings, 0 replies; 4+ messages in thread From: Eric Sandeen @ 2009-08-20 15:58 UTC (permalink / raw) To: Jeff Flowers; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-08-20 15:58 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox