**** Work in Progress ****
The volumename.cfg file holds all the settings that tie all those LUNs together into a volume as we know it. It resides in the config folder of your metadata controller (/Library/Filesystems/Xsan/config/) and is definitely something you should back up!
Below is a .cfg file copied into the wiki, I will go through and explain what each line means and what role it plays.
Text in Red, I have added.
# ****************************************************************************
# A global section for defining file system-wide parameters.
# ****************************************************************************
FileLocksYes
GlobalSuperUserYes
(Dis)Allows clients local super users (eg root) to override permissions.
Enables quotas to be set and enforced.
WindowsSecurityYes
ForceStripeAlignmentYes
RAID arrays have a stripe size (block size x stripe breadth) where they give optimum performance, for example this cfg has a 2MB stripe size. The first 1MB of a LUN is used for the CV label, and without Force Stripe Alignment the first stripe written to the discs would be half way through a physical stripe. When set to 'YES' the first stripe would be written to the discs at the 2MB mark, aligning it with the physical stripe as to not half fill two stripes on the disk.
UnixIdFabricationOnWindowsYes
EnforceACLsYes
Enables ACLs to be set and enforced.
Sets the debug flags, this will cause the volume to produce large logs and degrade performance.
Sets storage pool allocation strategy between; Round, Balance & Fill.
The amount of blocks initially allocated when a file requests additional space, in this case 1MB (8 x 128k).
As a file grows, it is allocated space in chunks (of blocks), the size of which is stated above (always rounded up to the nearest integer multiple of the InodeExpandMin).
1st Growth 40 (5MB)
2nd Growth 72 (9MB)
3rd Growth 104 (13MB)
Nth Growth 8+(Nx32)
The maximum number of blocks the inode can expand to before a new one is created. (This is will be rounded up to the nearest integer multiple of the InodeExpandMin)
The buffer cache reduces metadata latency as the fsm can read some of the metadata from RAM instead of the discs. The larger the cache, the less is read from the storage and the lower the overall filesystem latency. The RAM used by the cache is actually twice the stated amount. If this cache exceeds the available physical RAM then it will placed into swap space, impeding performance.
The journal size can be tweaked up to 64MB to improve latency (16MB the lowest and default), however it can be at the detriment of volume startup times and failover performance.
How large the blocks of data the file system writes, this is the smallest a file can be on the specific volume. All files are rounded up to integer multiples of this value.
Very similar to the Buffer Cache but specifically for caching inodes. To get the true value of the size of the cache you need to multiply the stated cache size by 800-1000. It is recommended that you don't go above 64k.
The amount of concurrent connections from clients to the fsm allowed.
This sets how large a volumes cvlog file (located in - /Library/Filesystems/Xsan/data/volume/log/ ) can grow before a new file is started and a number suffixed to the now 'full' cvlog.
This setting sets how many threads the fsm can run concurrently. Gains can be made by increasing this number, as theads that can be executed by using data from the caches could end up cued behind active threads which are waiting for data from the metadata LUN in smaller pools. Each thread consumes 512k of memory and set this value too high and you could hit the OS maximum and cause the fsm to crash.
UnixNobodyUidOnWindows-2
UnixNobodyGidOnWindows-2
# ****************************************************************************
# A disktype section for defining disk hardware parameters.
# ****************************************************************************
In my volume I have 6 LUNs, outlined below are the LUN sizes defined as sectors size and amount of them.
[DiskType metaType]
Sectors 976608427
SectorSize 512
[DiskType video1Type]
Sectors 5860595679
SectorSize 512
[DiskType video3Type]
Sectors 5860595679
SectorSize 512
[DiskType video5Type]
Sectors 5860595679
SectorSize 512
[DiskType video4Type]
Sectors 5860595679
SectorSize 512
[DiskType video2Type]
Sectors 5860595679
SectorSize 512
# ****************************************************************************
# A disk section for defining disks in the hardware configuration.
# ****************************************************************************
[Disk meta]
Status Up
Type metaType
[Disk video1]
Status Up
Type video1Type
[Disk video3]
Status Up
Type video3Type
[Disk video5]
Status Up
Type video5Type
[Disk video4]
Status Up
Type video4Type
[Disk video2]
Status Up
Type video2Type
# ****************************************************************************
# A stripe section for defining stripe groups.
# ****************************************************************************
[StripeGroup Meta]
Name of the stripe group.
Group is enabled. An example where you could need to play with this is where a storage pool linked to a affinity had died through the loss of a LUN and you wanted to try and recover data that was not spread across the failed LUN.
This stripe group / storage pool is exclusive to one task, in this case metadata so user data is not written to it.
This stripe group / storage pool has been set aside for Metadata & Journaling.
Fairly self explanatory.
Fairly self explanatory.
The strategy in which selects which LUN to write to next.
How many blocks are written to a LUN before moving onto the next.
LUN(s) added to the group / pool, in this case just the one.
[StripeGroup Video]
Status Up
Exclusive No
The Exclusive tag in data-based stripe groups (Storage Pools) is whether the storage pool is part of the general Allocation Strategy of the Volume (no) or whether data can flow to in only if an affinity is set somewhere on the volume (yes).
Does not hold metadata or journaling, as we have a dedicated LUN for that.
Affinity Video
Read Enabled
Write Enabled
MultiPathMethod Rotate
StripeBreadth 16
Node video1 0
Node video3 1
Node video5 2
Node video4 3
Node video2 4
LUN(s) added to the group / pool, when the Multi Path Method is set to rotate, the filesystem will write to these LUNs in the order they are numbered (not the numbers in the cvlabel, rather the numbers added in the cfg after the LUN name). This config has been laid out to avoid hitting two controllers which are housed in the same chassis sequentially, as the cache coherence in an active-active failover performs best when time between the controllers being hit is evenly spaced.