enable inode64 by default when possible

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.

Le Wed, 10 Feb 2010 13:32:39 -0600 vous écriviez:

Quoted 3 lines

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.

But doesn't it cause problems specially for NFS sharing ?

Quoted 2 lines

But doesn't it cause problems specially for NFS sharing ?

For some clients, yes - as do other NFS servers.

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.

32 bits to represent. So at this point it's not possible

(Minor update to documentation for "nobarrier" as well, which had not been previously documented).

Signed-off-by Eric Sandeen <[email protected]>

---

Documentation/filesystems/xfs.txt +14 -3

index 9878f50..05b845a 100644
@@ -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

fs/xfs/linux-2.6/xfs_super.c +6 -0

index 97c0f5a..7c74965 100644
@@ -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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

OK, it's been about two months since Eric proposed this, and I'm finally getting around to writing up a response.

I discussed this with a few people within SGI, and there were two main concerns that were mentioned:
- This may be a problem for some NFS clients
- This may be a problem for some backup software
We don't believe there are any direct issues with DMF or CXFS in making this change.

I understand that the change is only in the default behavior, and that forcing 32-bit inodes will still be an available option.

Alex Elder put forth on 4/9/2010 5:01 PM:

Quoted 10 lines

OK, it's been about two months since Eric proposed this, and I'm finally getting around to writing up a response.

I discussed this with a few people within SGI, and there were two main concerns that were mentioned:
- This may be a problem for some NFS clients
- This may be a problem for some backup software
We don't believe there are any direct issues with DMF or CXFS in making this change.

Quoted 3 lines

I understand that the change is only in the default behavior, and that forcing 32-bit inodes will still be an available option.

Hi Alex,

How will this change affect those people running 32bit CPUs and kernels, if at all? Or is this change related not to the word width of the hardware/OS but to the size of the filesystem and/or number of files/inodes contained within? You mentioned possible issues with NFS. Are there any issues with Samba?

Intel Atom (32bit x86) CPUs and XFS on multi terabyte disks are popular with many folks running Linux based media PCs, streaming their ripped DVDs and other large media files from their XFS filesystems. I don't personally do this, but I also have 32bit only systems that won't be replaced with 64bit CPUs for some time to come.

Thanks.

Alex Elder put forth on 4/9/2010 5:01 PM:

Quoted 10 lines

OK, it's been about two months since Eric proposed this, and I'm finally getting around to writing up a response.

I discussed this with a few people within SGI, and there were two main concerns that were mentioned:
- This may be a problem for some NFS clients
- This may be a problem for some backup software
We don't believe there are any direct issues with DMF or CXFS in making this change.

Quoted 3 lines

I understand that the change is only in the default behavior, and that forcing 32-bit inodes will still be an available option.

Hi Alex,

How will this change affect those people running 32bit CPUs and kernels, if at all? Or is this change related not to the word width of the hardware/OS but to the size of the filesystem and/or number of files/inodes contained within? You mentioned possible issues with NFS. Are there any issues with Samba?

Intel Atom (32bit x86) CPUs

Quoted 1 line

Intel Atom (32bit x86) CPUs

No, I think Atom is 64 bit.

/me checks his mailserver

Yup, it's running a 64 bit kernel and 64 bit userspace. No 32 bit issues there....

Quoted 2 lines

Intel Atom (32bit x86) CPUs

No, I think Atom is 64 bit.

Quoted 11 lines · Eric Sandeen

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.

Quoted 5 lines

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.

OK, it's been about two months since Eric proposed this, and I'm finally getting around to writing up a response.

I discussed this with a few people within SGI, and there were two main concerns that were mentioned:
- This may be a problem for some NFS clients
- This may be a problem for some backup software
We don't believe there are any direct issues with DMF or CXFS in making this change.

I understand that the change is only in the default behavior, and that forcing 32-bit inodes will still be an available option.

On NFS, there is a "fileid" automatic variable in nfs_do_filldir() that holds the inode number, and that variable was not made to have an explicitly 64-bit type (it had been "unsigned long") until Linux 2.6.24. Therefore, on 32-bit systems prior to that release there may be problems with 64-bit inodes.

On backup software, there was at one time a restriction with EMC Networker backup that required that only 32-bit inodes be used in a file system in order to work correctly. This was reportedly a very difficult requirement to work around. (I made a small effort to get confirmation that this either is still the case--or that it has since been resolved--but so far I don't know the answer.)

There could be other issues, but the point is that there do exist "reasonable" scenarios that still require that the file system enforce all inode numbers fit into 32 bits.

There is no on-disk recording of whether any >32-bit inode numbers are already allocated in a given XFS file system (although a scan of inodes on large file systems could determine whether any is in use). There is also no way for user space (or NFS for that matter) to query whether a particular file system has inodes that require

Quoted 1 line

32 bits to represent. So at this point it's not possible

for scenarios that have 32-bit inode number requirements to defend themselves against a file system that doesn't satisfy the requirement.

I am in favor of changing the default as you propose. There's no reason we couldn't add the new "32-bit inodes" mount option first before changing which is used by default.

I would really like to develop a way to indicate whether a given file system uses large (>32 bit) inode numbers, and have an implementation in place before committing to the 64-bit default. We could record a ">32 bit inode present" condition on the superblock somehow, or otherwise determine it at mount time, for example. Applications may find it useful to expose this information to user space as well.

Beyond that, my only comment on your patch is that I think I'd prefer "inode32" rather than "noinode64" as the name of the new mount option, and choose an appropriate mechanism for selecting which or rejecting a mount if both are specified.

What do you think?