Re: recommended way to add ssd cache to mdraid array

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux