From: Dave Chinner <david@fromorbit.com>
To: Dave Hall <kdhall@binghamton.edu>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_fsr, sunit, and swidth
Date: Thu, 14 Mar 2013 10:57:03 +1100 [thread overview]
Message-ID: <20130313235703.GX21651@dastard> (raw)
In-Reply-To: <5140C147.7070205@binghamton.edu>
On Wed, Mar 13, 2013 at 02:11:19PM -0400, Dave Hall wrote:
> Does xfs_fsr react in any way to the sunit and swidth attributes of
> the file system?
Not directly.
> In other words, with an XFS filesytem set up
> directly on a hardware RAID, it is recommended that the mount
> command be changed to specify sunit and swidth values that reflect
> the new geometry of the RAID.
The mount option does nothing if sunit/swidth weren't specified at
mkfs time. sunit/swidth affect the initial layout of the filesystem,
and that cannot be altered after the fact. Hence you can't
arbitrarily change sunit/swidth after mkfs - you are limited to
changes that are compatible with the existing alignment. If you have
no alignment specified, then there isn't a new alignment that can be
verified as compatible with the existing layout.....
> In my case, these values were not
> specified on the mkfs.xfs of a rather large file system running on a
> RAID 6 array.
Which means the mount option won't work.
> I am wondering adding sunit and swidth parameters to
> the fstab will cause xfs_fsr to do anything different than it is
> already doing. Most importantly, will it improve performace in any
> way?
It will make no difference at all.
A more important question: why do you even need to run xfs_fsr?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-03-13 23:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 18:11 xfs_fsr, sunit, and swidth Dave Hall
2013-03-13 23:57 ` Dave Chinner [this message]
2013-03-14 0:03 ` Stan Hoeppner
[not found] ` <514153ED.3000405@binghamton.edu>
2013-03-14 12:26 ` Stan Hoeppner
2013-03-14 12:55 ` Stan Hoeppner
2013-03-14 14:59 ` Dave Hall
2013-03-14 18:07 ` Stefan Ring
2013-03-15 5:14 ` Stan Hoeppner
2013-03-15 11:45 ` Dave Chinner
2013-03-16 4:47 ` Stan Hoeppner
2013-03-16 7:21 ` Dave Chinner
2013-03-16 11:45 ` Stan Hoeppner
2013-03-25 17:00 ` Dave Hall
2013-03-27 21:16 ` Stan Hoeppner
2013-03-29 19:59 ` Dave Hall
2013-03-31 1:22 ` Dave Chinner
2013-04-02 10:34 ` Hans-Peter Jansen
2013-04-03 14:25 ` Dave Hall
2013-04-12 17:25 ` Dave Hall
2013-04-13 0:45 ` Dave Chinner
2013-04-13 0:51 ` Stan Hoeppner
2013-04-15 20:35 ` Dave Hall
2013-04-16 1:45 ` Stan Hoeppner
2013-04-16 16:18 ` Dave Chinner
2015-02-22 23:35 ` XFS/LVM/Multipath on a single RAID volume Dave Hall
2015-02-23 11:18 ` Emmanuel Florac
2015-02-24 22:04 ` Dave Hall
2015-02-24 22:33 ` Dave Chinner
[not found] ` <54ED01BC.6080302@binghamton.edu>
2015-02-24 23:33 ` Dave Chinner
2015-02-25 11:49 ` Emmanuel Florac
2015-02-25 11:21 ` Emmanuel Florac
2013-03-28 1:38 ` xfs_fsr, sunit, and swidth 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=20130313235703.GX21651@dastard \
--to=david@fromorbit.com \
--cc=kdhall@binghamton.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.