From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: xfs tuning for a 830 GB partition (mkfs.xfs options)
Date: Wed, 08 Dec 2010 18:27:50 -0600 [thread overview]
Message-ID: <4D002286.2080204@hardwarefreak.com> (raw)
In-Reply-To: <AANLkTi=qkM9c5ukdJj7Hqhj8XMWSOGNENLEG9_Uz_DBT@mail.gmail.com>
Abel Coto put forth on 12/8/2010 5:29 PM:
> By the moment i will use one hard disk for / (on ext3) and /home , and
> the data partition for saving 3d projects working on in another hard
> disk (1,5 tb one , with the 350 GB partition and one of 1 TB for
> backups of /home mostly)
>
> so agcount should be in both cases 4, as i haven't got a raid (the 1,5
> tb disk won't be in the LVM neither).
>
> I have read that in xfsprogs 3.1.2, i think, -l lazy-count=1,version=2
> and -i attr=2 is the default option like agcount=4. So i should only
> specify the -l size=128m if i want a log size of 128m for improve
> deleting performance and improving system in general.
With a single disk filesystem, you can tweak these things forever, and
you will gain almost no performance benefit over the mkfs.xfs defaults,
though you may decrease performance if you don't know exactly what
you're doing, such as with your previous misunderstanding of agcount.
The one thing you can tweak beyond defaults to get improved performance
is using delayed logging, which will increase metadata write performance
substantially. For example, deletes of large groups (thousands) of
small files will be "massively" faster using delayed logging. IIRC this
requires kernel 2.6.36 or later. Simply add "delaylog" to you
/etc/fstab mount options.
> I think in /home the most important thing is read/write seqential
> performance , and in /data (the 350 GB partition) the same.
>
> I don't think /data would have to handle too many ramdon reads/ writes
> when Maya saves and read data from it, i think would be mostly
> seqential and then allocated in memory.
Again, with a single disk, there's not much you can tweak to increase
general XFS performance, except for metadata writes using delaylog. For
sequential file reads/writes and random reads/writes, you're at the
mercy of the drive's spindle speed.
XFS options can't improve upon the poor physics of a single spinning
drive. If you need improved file performance (not metadata), your
options are to add spindles and stripe the data (RAID card or mdadm,
RAID 0/5/6/10), or use a good quality SSD.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-12-09 0:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 19:32 xfs tuning for a 830 GB partition (mkfs.xfs options) Abel Coto
2010-12-08 22:14 ` Stan Hoeppner
[not found] ` <AANLkTi=qkM9c5ukdJj7Hqhj8XMWSOGNENLEG9_Uz_DBT@mail.gmail.com>
2010-12-09 0:27 ` Stan Hoeppner [this message]
2010-12-09 1:05 ` Dave Chinner
2010-12-09 1:34 ` Dave Chinner
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=4D002286.2080204@hardwarefreak.com \
--to=stan@hardwarefreak.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