From: Mark Tinguely <tinguely@sgi.com>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Update mount options documentation
Date: Thu, 18 Oct 2012 10:50:18 -0500 [thread overview]
Message-ID: <5080253A.9060906@sgi.com> (raw)
In-Reply-To: <1350574138-30305-1-git-send-email-cmaiolino@redhat.com>
On 10/18/12 10:28, Carlos Maiolino wrote:
> Once inode64 is the default allocation mode now, kernel documentation should be
> updated to match this behaviour.
>
> Signed-off-by: Carlos Maiolino<cmaiolino@redhat.com>
> ---
> Documentation/filesystems/xfs.txt | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
> index 3fc0c31..1718775 100644
> --- a/Documentation/filesystems/xfs.txt
> +++ b/Documentation/filesystems/xfs.txt
> @@ -72,8 +72,15 @@ When mounting an XFS filesystem, the following options are accepted.
> Indicates that XFS is allowed to create inodes at any location
> in the filesystem, including those which will result in inode
> numbers occupying more than 32 bits of significance. This is
> - provided for backwards compatibility, but causes problems for
> - backup applications that cannot handle large inode numbers.
> + the default allocation option. Applications which do not handle
> + inode numbers bigger than 32 bits, should use inode32 option.
> +
> + inode32
> + Indicates that XFS is limited to create inodes at locations which
> + will not result in inode numbers with more than 32 bits of
> + significance. This is provided for backwards compatibility, since
> + 64 bits inode numbers might cause problems for some applications
> + that cannot handle large inode numbers.
>
> largeio/nolargeio
> If "nolargeio" is specified, the optimal I/O reported in
An engineer that documents!
Would "Indicates that XFS is allowed to create inodes at locations up to
32 bits of significance .."
Do you want to add that it can still read/write/unlink the inodes
numbered > 32 bits that were created via inode64?
--Mark Tinguely.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-10-18 15:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-18 15:28 [PATCH] xfs: Update mount options documentation Carlos Maiolino
2012-10-18 15:50 ` Mark Tinguely [this message]
2012-10-18 16:00 ` Dave Howorth
2012-10-18 16:05 ` Mark Tinguely
2012-10-18 17:04 ` Carlos Maiolino
2012-10-18 17:15 ` Mark Tinguely
2012-10-18 18:40 ` Carlos Maiolino
2012-11-08 17:47 ` Ben Myers
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=5080253A.9060906@sgi.com \
--to=tinguely@sgi.com \
--cc=cmaiolino@redhat.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