From: Eric Sandeen <sandeen@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 01/27] xfs: update mount options documentation
Date: Thu, 13 Jun 2013 19:53:21 -0500 [thread overview]
Message-ID: <51BA6981.407@redhat.com> (raw)
In-Reply-To: <20130614004052.GO29338@dastard>
On 6/13/13 7:40 PM, Dave Chinner wrote:
>>> +
>>> > > + The sunit and swidth parameters specified must be compatible
>>> > > + with the existing filesystem alignment characteristics. If
>>> > > + the filesystem was not created with data alignment
>>> > > + constraints, then it may be impossible to set a valid sunit
>>> > > + (and hence swidth) value. In general, that means the only
>>> > > + valid changes to sunit are increasing it by a power-of-2
>>> > > + multiple. Valid swidth values are any integer multiple of a
>>> > > + valid sunit value.
>> >
>> > now I'm confused. It's only relevant to a filesystem w/ geometry
>> > specified, but if it wasn't specified, it may be possible . . . ?
>> > And if nothing was specified (i.e. 0 su/sw) then we can only increase
>> > that 0 by a power of 2?
>> >
>> >
>>> > > + For filesystems that have existing data alignment values on
>>> > > + disk (i.e. specified by mkfs), any new valid values passed
>>> > > + in as mount options will overwrite the values stored on
>>> > > + disk. Hence this mount option does not need to be specified
>>> > > + for every mount operation in this case.
>> >
>> > so I think this all needs to clarify whether it works on filesystems
>> > w/o existing geometry, or not. And "why you might want this" would
>> > be helpful too.
> It's obviously too complex to explain everything in a short "what"
> description. I suspect that the best thing to do here is simply
> document it as a method of changing alignment for a device that has
> changed geometry such as a adding a disk to a MD RAID5 device. I'm
> going to drop any reference to sunit/swidth being zero because that
> case was a hack for fixing a CXFS client bug.
>
Ok, fair enough on the what not why.
But FWIW, even if we aren't saying why, just what, the docs seem
inconsistent here.
It talks about existing geometry being required for this option, but also
says what happens if it's not.
If you drop that part, then that sounds good.
Thanks,
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-06-14 0:53 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 10:22 [PATCH 00/27] xfs: current patch queue for 3.11 Dave Chinner
2013-06-12 10:22 ` [PATCH 01/27] xfs: update mount options documentation Dave Chinner
2013-06-13 13:34 ` Eric Sandeen
2013-06-14 0:40 ` Dave Chinner
2013-06-14 0:53 ` Eric Sandeen [this message]
2013-06-12 10:22 ` [PATCH 02/27] xfs: add pluging for bulkstat readahead Dave Chinner
2013-06-12 10:22 ` [PATCH 03/27] xfs: plug directory buffer readahead Dave Chinner
2013-06-12 10:22 ` [PATCH 04/27] xfs: don't use speculative prealloc for small files Dave Chinner
2013-06-12 16:10 ` Brian Foster
2013-06-13 0:50 ` Dave Chinner
2013-06-12 10:22 ` [PATCH 05/27] xfs: don't do IO when creating an new inode Dave Chinner
2013-06-12 10:22 ` [PATCH 06/27] xfs: xfs_ifree doesn't need to modify the inode buffer Dave Chinner
2013-06-12 10:22 ` [PATCH 07/27] xfs: Introduce ordered log vector support Dave Chinner
2013-06-12 10:22 ` [PATCH 08/27] xfs: Introduce an ordered buffer item Dave Chinner
2013-06-12 10:22 ` [PATCH 09/27] xfs: Inode create log items Dave Chinner
2013-06-12 10:22 ` [PATCH 10/27] xfs: Inode create transaction reservations Dave Chinner
2013-06-12 10:22 ` [PATCH 11/27] xfs: Inode create item recovery Dave Chinner
2013-06-12 10:22 ` [PATCH 12/27] xfs: Use inode create transaction Dave Chinner
2013-06-12 10:22 ` [PATCH 13/27] xfs: remove local fork format handling from xfs_bmapi_write() Dave Chinner
2013-06-12 10:22 ` [PATCH 14/27] xfs: move getdents code into it's own file Dave Chinner
2013-06-12 10:22 ` [PATCH 15/27] xfs: reshuffle dir2 definitions around for userspace Dave Chinner
2013-06-17 16:05 ` Christoph Hellwig
2013-06-18 21:12 ` Dave Chinner
2013-06-18 21:35 ` Dave Chinner
2013-06-12 10:22 ` [PATCH 16/27] xfs: split out attribute listing code into separate file Dave Chinner
2013-06-12 10:22 ` [PATCH 17/27] xfs: split out attribute fork truncation " Dave Chinner
2013-06-12 10:22 ` [PATCH 18/27] xfs: split out xfs inode operations " Dave Chinner
2013-06-12 14:05 ` Christoph Hellwig
2013-06-13 1:14 ` Dave Chinner
2013-06-13 8:00 ` Dave Chinner
2013-06-17 15:56 ` Christoph Hellwig
2013-06-17 18:14 ` Ben Myers
2013-06-18 20:40 ` Dave Chinner
2013-06-18 21:37 ` Ben Myers
2013-06-18 22:02 ` Dave Chinner
2013-06-12 10:22 ` [PATCH 19/27] xfs: consolidate xfs_vnodeops.c into xfs_inode_ops.c Dave Chinner
2013-06-12 13:59 ` Christoph Hellwig
2013-06-13 1:39 ` Dave Chinner
2013-06-17 16:02 ` Christoph Hellwig
2013-06-18 20:55 ` Dave Chinner
2013-06-12 10:22 ` [PATCH 20/27] xfs: move xfs_getbmap to xfs_extent_ops.c Dave Chinner
2013-06-12 10:22 ` [PATCH 21/27] xfs: introduce xfs_sb.c for sharing with libxfs Dave Chinner
2013-06-12 10:22 ` [PATCH 22/27] xfs: move xfs_trans_reservations to xfs_trans.h Dave Chinner
2013-06-12 10:22 ` [PATCH 23/27] xfs: sync minor header differences needed by userspace Dave Chinner
2013-06-12 10:22 ` [PATCH 24/27] xfs: move xfs_bmap_punch_delalloc() to xfs_aops.c Dave Chinner
2013-06-12 14:06 ` Christoph Hellwig
2013-06-13 1:39 ` Dave Chinner
2013-06-12 10:22 ` [PATCH 25/27] xfs: split out transaction reservation code Dave Chinner
2013-06-12 10:22 ` [PATCH 26/27] xfs: minor cleanups Dave Chinner
2013-06-12 10:22 ` [PATCH 27/27] xfs: fix issues that cause userspace warnings Dave Chinner
2013-06-17 19:32 ` Brian Foster
2013-06-18 21:42 ` Dave Chinner
2013-06-12 13:06 ` [PATCH 00/27] xfs: current patch queue for 3.11 Brian Foster
2013-06-13 1:40 ` Dave Chinner
2013-06-12 14:17 ` Ben Myers
2013-06-13 1:58 ` 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=51BA6981.407@redhat.com \
--to=sandeen@redhat.com \
--cc=david@fromorbit.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