From: Emmanuel Florac <eflorac@intellique.com>
To: Steve Bergman <sbergman27@gmail.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Questions about XFS
Date: Tue, 11 Jun 2013 15:10:55 +0200 [thread overview]
Message-ID: <20130611151055.2680b6cc@harpe.intellique.com> (raw)
In-Reply-To: <loom.20130611T112155-970@post.gmane.org>
Le Tue, 11 Jun 2013 09:56:38 +0000 (UTC)
Steve Bergman <sbergman27@gmail.com> écrivait:
> Hi all,
>
> I have a few questions about XFS that didn't make the XFS FAQ. I'm
> trying to get a feel for where I might want to use it on my servers
> (or at home). A mix of ext3 & ext4 has worked well for me. But I'd
> like to get to know XFS a bit better. The target OS would be RHEL6.
>
> 1. I don't have "lots and large". Why should I run XFS?
Because it performs well and reliably.
> 2. I don't have "lots and large". Why shouldn't I run XFS?
Because ext4 is more common and won't uncover unexpected bugs in badly
written applications.
> 3. Why doesn't RHEL6 support XFS on root, when the XFS FAQ says XFS
> on root is fine? Is there some issue I should be aware of?
Not that I know of. I've used XFS as root back in the RedHat 7.x times,
13 years ago. I've used XFS as root on Irix years before that.
However nowadays I use XFS extensively but usually not as root.
> 4. From the time I write() a bit of data, what's the maximum time
> before the data is actually committed to disk?
On the distributions I'm using (Debian, Slackware), no significant
delay that I know of. Even extremely mistreated systems (pulling the
plug while working shouldn't do any harm, should it?)
> 5. Ext4 provides some automatic fsync'ing to avoid the zero-length
> file issue for some common cases via the auto_da_alloc feature added
> in kernel 2.6.30. Does XFS have similar behavior?
I don't know. I keep hearing of this "xfs bug" but never actually
encountered it, ever, though I've set up about 3000 servers with XFS
filesystems, many to work under very harsh conditions.
> 6. RHEL6 Anaconda sets a RAID10 chunk size of 512K by default XFS
> complains and sets its log stripe down to 32k. Should I accept
> Anaconda's default? It knows I've requested XFS formatting before it
> sets the chunk size, after all.
512k seems insanely large to me. Something like 64 or 256k seems more
common, and reasonable. BTW, 256k is a perfectly valid size for xfs log
stripe. My advice: unless you plan on working only with big files,
create a 64k stripe RAID-10. Your performance will be much better, and
XFS will be happy.
> 8. Eric (and the XFS FAQ) have recommended just using the defaults for
> mkfs.xfs and mount. But I've also heard Dave say "Increase logbsize
> and use inode64; everybody does that, but we just haven't made it the
> default". I'm guessing it doesn't matter if one doesn't have large
> and lots?
Actually inode64 is default on recent kernels. Of course this doesn't
apply to RH which for some reason uses only positively jurassic
kernels :)
Increasing logbsize is probably unnecessary except on highly
performance sensitive workloads; currently the 32k default should be
enough.
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-06-11 13:11 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 9:56 Questions about XFS Steve Bergman
2013-06-11 13:10 ` Emmanuel Florac [this message]
2013-06-11 13:35 ` Stefan Ring
2013-06-11 13:52 ` Ric Wheeler
2013-06-11 13:59 ` Ric Wheeler
2013-06-11 16:12 ` Steve Bergman
2013-06-11 17:19 ` Ric Wheeler
2013-06-11 17:27 ` Stefan Ring
2013-06-11 17:31 ` Ric Wheeler
2013-06-11 17:41 ` Stefan Ring
2013-06-11 18:03 ` Eric Sandeen
2013-06-11 19:30 ` Steve Bergman
2013-06-11 21:03 ` Dave Chinner
2013-06-11 21:43 ` Steve Bergman
2013-06-11 17:59 ` Ben Myers
2013-06-11 17:28 ` Eric Sandeen
2013-06-11 19:17 ` Steve Bergman
2013-06-11 21:47 ` Dave Chinner
2013-07-22 14:59 ` Steve Bergman
2013-07-22 15:16 ` Steve Bergman
2013-06-12 8:26 ` Roger Oberholtzer
2013-06-12 10:34 ` Ric Wheeler
2013-06-12 13:52 ` Roger Oberholtzer
2013-06-12 12:12 ` Stan Hoeppner
2013-06-12 13:48 ` Roger Oberholtzer
2013-06-13 0:48 ` Dave Chinner
2013-06-11 19:35 ` Ben Myers
2013-06-11 19:55 ` Steve Bergman
2013-06-11 20:08 ` Ben Myers
2013-06-11 21:57 ` Matthias Schniedermeyer
2013-06-11 22:18 ` Steve Bergman
-- strict thread matches above, loose matches on Subject: below --
2013-10-25 14:28 harryxiyou
2013-10-25 14:42 ` Emmanuel Florac
2013-10-25 14:57 ` Eric Sandeen
2013-10-25 16:24 ` harryxiyou
2013-10-25 16:44 ` harryxiyou
2013-10-26 10:41 ` Stan Hoeppner
2013-10-27 3:29 ` Eric Sandeen
2013-10-25 16:13 ` harryxiyou
2013-10-25 16:16 ` Eric Sandeen
2007-03-13 13:40 clflush
2007-03-13 15:36 ` Klaus Strebel
2007-03-13 15:53 ` Stein M. Hugubakken
2007-03-13 15:55 ` Eric Sandeen
2007-03-14 16:33 ` Stewart Smith
2007-03-15 4:26 ` Taisuke Yamada
2007-03-15 9:07 ` clflush
2007-03-15 14:41 ` Geir A. Myrestrand
2007-03-16 10:36 ` Martin Steigerwald
2007-03-17 0:47 ` Jason White
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=20130611151055.2680b6cc@harpe.intellique.com \
--to=eflorac@intellique.com \
--cc=linux-xfs@oss.sgi.com \
--cc=sbergman27@gmail.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