On 1/11/2013 6:20 AM, Thomas Fjellstrom wrote: > On Thu Jan 10, 2013, Chris Murphy wrote: >> Another thing to look at is if you're using XFS, what your mount options >> are. Invariably with an array of this size you need to be mounting with >> the inode64 option. > > I'm not sure, but I think that's the default. No, inode32 has always been the default allocator. It was decided just recently to make inode64 the default, and the patcheset for this was committed on 9/20/2012, ~3 months ago, into 3.6-rc1-17: http://oss.sgi.com/archives/xfs/2012-09/msg00397.html So with 3.6+ kernels inode64 is the new default. Any current mainstream distro kernel defaults to inode32. Worth noting: if you upgrade the kernel on a system with existing inode32 XFS filesystems the allocator for these will remain inode32 unless the mount option is manually changed. This is the same behavior as with current kernels. New filesystems created after upgrading to a 64 bit kernel w/this patch set will be mounted with inode64. IIRC 32 bit kernels are limited to the inode32 allocator and 32 bit inodes. There are many workloads that prefer, or even require, 32bit inodes, and/or the behavior available with the inode32 allocator. Thus it would not be smart to auto convert them to inode64 after a kernel upgrade. -- Stan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html