From: Eric Sandeen <sandeen@sandeen.net>
To: xfs-oss <xfs@oss.sgi.com>
Subject: [PATCH] enable inode64 by default when possible
Date: Wed, 10 Feb 2010 13:32:39 -0600 [thread overview]
Message-ID: <4B7309D7.5090800@sandeen.net> (raw)
Taking another swing at this.
As XFS continues to position itself as the choice for very
large Linux filesystems, we need to be mindful of the problems
that the 32-bit inode restriction can cause with allocations
and performance.
As such, this patch changes the default to inode64 whenever
XFS_BIG_INUMS is set, which in turn depends on either
CONFIG_LBDAF or 64-bit longs.
Going forward, we may wish to do this unconditionally for all
filesystems by choosing CONFIG_LBDAF by default when xfs is
chosen, but I'll leave that for later.
This patch adds a "noinode64" option for backwards compatibility.
(Minor update to documentation for "nobarrier" as well, which
had not been previously documented).
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
---
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 9878f50..05b845a 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -37,7 +37,10 @@ When mounting an XFS filesystem, the following options are accepted.
Enables the use of block layer write barriers for writes into
the journal and unwritten extent conversion. This allows for
drive level write caching to be enabled, for devices that
- support write barriers.
+ support write barriers. This is the default.
+
+ nobarrier
+ Disables the use of block layer write barriers.
dmapi
Enable the DMAPI (Data Management API) event callouts.
@@ -66,8 +69,16 @@ 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 for 64-bit or CONFIG_LBDAF kernels as of 2.6.33.
+
+ noinode64
+ Indicates that XFS must create inodes in filesystem locations
+ which will not result in inode numbers occupying more than 32
+ bits of significance. This is provided for backwards compatibility,
+ for 32-bit applications which may not use the 64-bit stat interface,
+ such as backup applications that cannot handle large inode numbers.
+ Note that this only affects new inode creation; existing 64-bit
+ inode locations are unaffected.
largeio/nolargeio
If "nolargeio" is specified, the optimal I/O reported in
diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c
index 97c0f5a..7c74965 100644
--- a/fs/xfs/linux-2.6/xfs_super.c
+++ b/fs/xfs/linux-2.6/xfs_super.c
@@ -95,6 +95,7 @@ mempool_t *xfs_ioend_pool;
#define MNTOPT_NOBARRIER "nobarrier" /* .. disable */
#define MNTOPT_OSYNCISOSYNC "osyncisosync" /* o_sync is REALLY o_sync */
#define MNTOPT_64BITINODE "inode64" /* inodes can be allocated anywhere */
+#define MNTOPT_32BITINODE "noinode64" /* inodes allocated in 32-bit range */
#define MNTOPT_IKEEP "ikeep" /* do not free empty inode clusters */
#define MNTOPT_NOIKEEP "noikeep" /* free empty inode clusters */
#define MNTOPT_LARGEIO "largeio" /* report large I/O sizes in stat() */
@@ -196,7 +197,9 @@ xfs_parseargs(
*/
mp->m_flags |= XFS_MOUNT_BARRIER;
mp->m_flags |= XFS_MOUNT_COMPAT_IOSIZE;
+#ifndef XFS_BIG_INUMS
mp->m_flags |= XFS_MOUNT_SMALL_INUMS;
+#endif
/*
* These can be overridden by the mount option parsing.
@@ -317,6 +320,8 @@ xfs_parseargs(
this_char);
return EINVAL;
#endif
+ } else if (!strcmp(this_char, MNTOPT_32BITINODE)) {
+ mp->m_flags |= XFS_MOUNT_SMALL_INUMS;
} else if (!strcmp(this_char, MNTOPT_NOUUID)) {
mp->m_flags |= XFS_MOUNT_NOUUID;
} else if (!strcmp(this_char, MNTOPT_BARRIER)) {
@@ -534,6 +539,7 @@ xfs_showargs(
{ XFS_MOUNT_FILESTREAMS, "," MNTOPT_FILESTREAM },
{ XFS_MOUNT_DMAPI, "," MNTOPT_DMAPI },
{ XFS_MOUNT_GRPID, "," MNTOPT_GRPID },
+ { XFS_MOUNT_SMALL_INUMS, "," MNTOPT_32BITINODE },
{ 0, NULL }
};
static struct proc_xfs_info xfs_info_unset[] = {
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2010-02-10 19:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-10 19:32 Eric Sandeen [this message]
2010-02-10 20:04 ` [PATCH] enable inode64 by default when possible Emmanuel Florac
2010-02-10 20:15 ` Eric Sandeen
2010-02-10 20:42 ` Emmanuel Florac
2010-04-09 22:01 ` Alex Elder
2010-04-10 2:37 ` Stan Hoeppner
2010-04-10 3:34 ` Eric Sandeen
2010-04-12 6:21 ` Dave Chinner
2010-04-13 6:35 ` Stan Hoeppner
2010-04-14 6:57 ` Andi Kleen
2010-04-12 6:12 ` [RFC, PATCH] inode64 feature bit (was Re: [PATCH] enable inode64 by default when possible) 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=4B7309D7.5090800@sandeen.net \
--to=sandeen@sandeen.net \
--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