snfs_config(5) [osx man page]

snfs_config(5)                                                  snfs_config(5)

NAME

       snfs_config - Xsan Volume Configuration File

SYNOPSIS

       /Library/Preferences/Xsan/*.cfg

DESCRIPTION

       The Xsan Volume configuration file describes to the File System Manager
       (FSM) the physical and logical layout of an individual volume.

FORMAT OPTIONS

       There is a new XML format for the Xsan Volume configuration  file  (see
       snfs.cfgx.5).   This  is  supported  on linux MDCs and is required when
       using the Storage Manager web-based GUI.

       The old format (see snfs.cfg.5) used in previous versions  is  required
       on  Windows  MDCs,  and is valid on linux MDCs, but the Storage Manager
       GUI will not recognize it.

       Linux MDCs will automatically have  their  volume  configuration  files
       converted  to  the new XML format on upgrade.  Old config files will be
       retained in the  /Library/Logs/Xsan/data/VolName/config_history  direc-
       tory.

       This manpage seeks to describe the configuration file in general.  For-
       mat specific information can be found in snfs.cfgx.5 and snfs.cfg.5.

GLOBAL VARIABLES

       The file system configuration has several global variables that  affect
       the  size,  function  and  performance  of the Xsan File System Manager
       (FSM).  (The FSM is the controlling program that tracks file allocation
       and  consistency  across  the  multiple clients that have access to the
       volume via a Storage Area Network.) The following global variables  can
       be modified.

     o XML: abmFreeLimit <true/false>

       Old: ABMFreeLimit 

       The  ABMFreeLimit variable instructs the FSM how to process the Alloca-
       tion Bit Map.  The default value of no causes the  software  to  use  a
       newer  method  for  handling  allocation  bit map entries.  Setting the
       value to yes reverts to the older method, causing cvupdatefs(1) to fail
       when  a bitmap fragmentation threshold is exceeded.  When that limit is
       exceeded, FSM memory usage and startup time may be excessive under  the
       older method.

     o XML: allocSessionReservationSize <value>

       Old: AllocSessionReservationSize <value>

       The Allocation Session Reservation feature allows a file system to ben-
       efit from optimized allocation behavior for certain rich media  stream-
       ing  applications,  and  potentially other workloads.  The feature also
       focuses on reducing free space fragmentation.

       This feature is disabled by default.

       An old, deprecated parameter, AllocSessionReservation, when set to  yes
       used a 1 GB segment size with no rounding.

       The  new  parameter, AllocSessionReservationSize, allows you to specify
       the size this feature should use when allocating segments  for  a  ses-
       sion.  The value is expressed in bytes so a value of 1073741824 is 1 GB
       and is a well tested value.  The value must be a multiple of MBs.   The
       XML  file  format  must be in bytes.  The old configuration file format
       can use multipliers such as m for MBs or g for GBs.  If the  multiplier
       is  omitted  in the old configuration file, the value is interpreted as
       bytes as in the XML format.

       A value of 0 is the default value, which means the  feature  is  turned
       off.  When enabled, the value can range from 128 MB (134217728) to 1 TB
       (1099511627776).  (The largest value would indicate segments are  1  TB
       in size, which is extremely large.)  The feature starts with the speci-
       fied size and then may use rounding to better handle  user's  requests.
       See also InodeStripeWidth.

       There  are  3  session  types:  small,  medium, and large.  The type is
       determined by the file offset and  requested  allocation  size.   Small
       sessions  are  for  sizes  (offset+allocation  size)  smaller than 1MB.
       Medium sessions are for sizes 1MB through 1/10th of  the  AllocSession-
       ReservationSize.  Large sessions are sizes bigger than medium.

       Here  is another way to think of these three types: small sessions col-
       lect or organize all small files into small session chunks; medium ses-
       sions  collect  medium  sized files by chunks using their parent direc-
       tory; and large files collect their own chunks and are allocated  inde-
       pendently of other files.

       All  sessions are client specific.  Multiple writers to the same direc-
       tory or large file on different clients will  use  different  sessions.
       Small files from different clients use different chunks by client.

       Small  sessions  use a smaller chunk size than the configured AllocSes-
       sionReservationSize.  The small chunk size is  determined  by  dividing
       the  configured  size by 32.  For 128 MB, the small chunk size is 4 MB.
       For 1 GB, the small chunk size is 32 MBs.

       Files can start using one session type and then move to another session
       type.   If a file starts in a medium session and then becomes large, it
       "reserves" the remainder of the session chunk it was using for  itself.
       After  a  session is reserved for a file, a new session segment will be
       allocated for any other medium files in that directory.

       When allocating subsequent pieces  for  a  session,  they  are  rotated
       around to other stripe groups that can hold user data.  This is done in
       a similar fashion to InodeStripeWidth.  The direction  of  rotation  is
       determined  by  a  combination  of the session key and the index of the
       client in the client table.  The session key is based on the inode num-
       ber  so  odd  inodes  will  rotate  in  a different direction from even
       inodes.  Directory session keys are based on the inode  number  of  the
       parent directory.

       If  this  capability  is  enabled,  StripeAlignSize is forced to 0.  In
       fact, all stripe alignment requests are disabled because they can cause
       clipping and can lead to severe free-space fragmentation.

       The old AllocSessionReservation parameter is deprecated and replaced by
       AllocSessionReservationSize.

       If any of the following "special" allocation  functions  are  detected,
       AllocSessionReservationSize is turned off for that allocation: Perfect-
       Fit, MustFit, or Gapped files.

       When this feature is enabled,  if  AllocationStrategy  is  not  set  to
       Round, it will be forced to Round.

     o XML: allocationStrategy <strategy>

       Old: AllocationStrategy <strategy>

       The  AllocationStrategy  variable  selects  a method for allocating new
       disk file blocks in the volume.  There  are  three  methods  supported:
       Round,  Balance,  and  Fill.  These methods specify how, for each file,
       the allocator chooses an initial storage pool to allocate blocks  from,
       and  how  the allocator chooses a new storage pool when it cannot honor
       an allocation request from a file's current storage pool.

       The default allocation strategy is Round.  Round means that when  there
       are  multiple storage pools of similar classes (for example two storage
       pools for non-exclusive data), the  space  allocator  should  alternate
       (round  robin)  new  files through the available storage pools.  Subse-
       quent allocation requests for any one file are  directed  to  the  same
       storage pool.  If insufficient space is available in that storage pool,
       the allocator will choose the next storage  pool  that  can  honor  the
       allocation request.

       When the strategy is Balance, the available blocks of each storage pool
       are analyzed, and the storage pool with the most total free  blocks  is
       chosen.  Subsequent requests for the same file are directed to the same
       storage pool.  If insufficient space is available in that storage pool,
       the  allocator  will  choose  the  storage pool with the most available
       space.

       When the strategy is Fill, the  allocator  will  initially  choose  the
       storage pool that has the smallest free chunk large enough to honor the
       initial allocation request.  After that it will allocate from the  same
       storage  pool until the storage pool cannot honor a request.  The allo-
       cator then reselects a storage pool using the original criteria.

       If the Allocation Session Reservation feature is enabled, the  strategy
       is forced to Round if configured otherwise.

     o XML: fileLockResyncTimeOut <value>

       Old: BRLResyncTimeout <value>

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

     o XML: bufferCacheSize <value>

       Old: BufferCacheSize <value>

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

       This  variable  defines  how  much memory to use in the FSM program for
       general metadata information caching.  The amount of memory consumed is
       up to 2 times the value specified.

       Increasing  this  value can improve performance of many metadata opera-
       tions by performing a memory cache access to  directory  blocks,  inode
       info  and  other  metadata  info.  This is about 10 - 1000 times faster
       than performing I/O.

     o XML: cvRootDir <path>

       Old: CvRootDir <path>

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

       The  CvRootDir  variable  specifies  the directory in the StorNext file
       system that will be mounted by clients. The specified path is an  abso-
       lute  pathname  of a directory that will become the root of the mounted
       file system. The default value for the CvRootDir path is  the  root  of
       the  file  system,  "/".  This  feature  is available only with Quantum
       StorNext Appliance products.

     o XML: debug <debug_value>

       Old: Debug <debug_value>

       The Debug variable turns on debug functions for the FSM. The output  is
       sent to /Library/Preferences/Xsan/data/<file_system_name>/log/cvfs_log.
       These data may be useful when a problem  occurs.   The  following  list
       shows  which value turns on a specific debug trace.  Multiple debugging
       options may be selected by calculating the bitwise OR of  the  options'
       values  to  use  as  debug_value.  Output from the debugging options is
       accumulated into a single file.

          0x00000001     General Information
          0x00000002     Sockets
          0x00000004     Messages
          0x00000008     Connections
          0x00000010     File system (VFS) requests
          0x00000020     File system file operations (VOPS)
          0x00000040     Allocations
          0x00000080     Inodes
          0x00000100     Tokens
          0x00000200     Directories
          0x00000400     Attributes
          0x00000800     Bandwidth Management
          0x00001000     Quotas
          0x00002000     Administrative Tap Management
          0x00004000     I/O
          0x00008000     Data Migration
          0x00010000     B+Trees
          0x00020000     Transactions
          0x00040000     Journal Logging
          0x00080000     Memory Management
          0x00100000     QOS Realtime IO
          0x00200000     External API
          0x00400000     Windows Security
          0x00800000     RBtree
          0x01000000     Once Only
          0x02000000     Extended Buffers
          0x04000000     Extended Directories
          0x08000000     Queues
          0x10000000     Extended Inodes
          0x20000000     In-core binary trees
          0x40000000     In-core allocation trees
          0x80000000     Development debug

       NOTE: The performance of the volume is dramatically affected by turning
       on debugging traces.

     o XML: dirWarp 

       Old: DirWarp 

       Enables  a readdir optimization for pre-StorNext 3.0 file systems.  Has
       no effect on volumes created on StorNext 3.0 or newer.

     o XML: enforceAcls 

       Old: EnforceACLs 

       Enables Access Control List enforcement on XSan clients.   On  non-XSan
       MDCs,  WindowsSecurity  should also be enabled for this feature to work
       with XSan clients.

     o XML: enableSpotlight 

       Old: EnableSpotlight 

       Enable SpotLight indexing on XSan system

     o XML: eventFiles 

       Old: EventFiles 

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

       Enables event files processing for Data Migration

     o XML: eventFileDir <path>

       Old: EventFileDir <path>

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

       Specifies the location to put Event Files

     o XML: extentCountThreshold <value>

       Old: ExtentCountThreshold <value>

       When a file has this many extents, a RAS event is triggered to warn  of
       fragmented  files.  The default value is 49152.  A value of 0 or 1 dis-
       ables the RAS event.   This  value  must  be  between  0  and  33553408
       (0x1FFFC00), inclusive.

     o XML: fileLocks 

       Old: FileLocks 

       The  variable enables or disables the tracking and enforcement of file-
       system-wide file locking.  Enabling the File locks feature allows  file
       locks  to  be  tracked  across all clients of the volume. The FileLocks
       feature supports both the POSIX file locking model and the Windows file
       locking model.

     o XML: forcePerfectFit 

       Old: ForcePerfectFit 

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

       Enables a specialized allocation mode where all files are automatically
       aligned  and  rounded  to  PerfectFitSize  blocks.  If this is enabled,
       AllocSessionReservationSize is ignored.

     o XML: fsBlockSize <value>

       Old: FsBlockSize <value>

       The File System Block Size defines  the  granularity  of  the  volume's
       allocation  size.  The  block size can be from 4K to 512K inclusive and
       must be a power of two.  Best practice for both  space  efficiency  and
       performance  is  typically 16K.  Higher values may be selected to opti-
       mize volume startup time, but at a cost of  space  efficiency.   Values
       greater than 64K will severely degrade both performance and space effi-
       ciency.

     o XML: fsCapacityThreshold <value>

       Old: FsCapacityThreshold <value>

       When a file system is over Fs Capacity Threshold percent  full,  a  RAS
       event is sent to warn of this condition.  The default value is 0, which
       disables the RAS event.  This value must be between 0 and  100,  inclu-
       sive.

     o XML: globalSuperUser 

       Old: GlobalSuperUser 

       The  Global  Super  User variable allows the administrator to decide if
       any user with super-user privileges may use  those  privileges  on  the
       file  system.  When  this  variable  is set to true, any super-user has
       global access rights on the volume. This may be  equated  to  the  map-
       root=0  directive in NFS. When the Global Super User variable is set to
       false, a super-user may only modify files where it has access rights as
       a normal user. This value may be modified for existing volumes.

     o XML: haFsType 

       Old: HaFsType 

       The  Ha Fs Type configuration item turns on Xsan High Availability (HA)
       protection for a file system, which prevents split-brain scenario  data
       corruption.   HA  detects  conditions where split brain is possible and
       triggers a hardware reset of the server to remove  the  possibility  of
       split  brain  scenario.  This occurs when an activated FSM is not prop-
       erly maintaining its brand of an arbitration block (ARB) on  the  meta-
       data  LUN.   Timers  on  the  activated and standby FSMs coordinate the
       usurpation of the ARB so that the activated server will relinquish con-
       trol  or perform a hardware reset before the standby FSM can take over.
       It is very important to configure all file systems correctly  and  con-
       sistently between the two servers in the HA cluster.

       There  are currently three types of HA monitoring that are indicated by
       the HaShared, HaManaged, and HaUnmanaged configuration parameters.

       The HaShared dedicated file system holds shared data for the  operation
       of the StorNext File System and Stornext Storage Manager (SNSM).  There
       must be one and only one HaShared  file  system  configured  for  these
       installations.   The running of SNSM processes and the starting of man-
       aged file systems is triggered by activation of the HaShared file  sys-
       tem.   In  addition  to  being  monitored for ARB branding as described
       above, the exit of the HaShared FSM triggers a hardware reset to ensure
       that  SNSM  processes  are  stopped  if  the  shared file system is not
       unmounted.

       The HaManaged file systems are not started until the HaShared file sys-
       tem activates.  This keeps all the managed file systems collocated with
       the SNSM processes.  It also means that they cannot  experience  split-
       brain  corruption  because  there is no redundant server to compete for
       control, so they are not monitored and cannot trigger a hardware reset.

       The  HaUnmanaged file systems are monitored.  The minimum configuration
       necessary for an HA cluster is to: 1) place this type in all the  FSMs,
       and  2)  enter  the  peer  server's  IP address in the ha_peer(4) file.
       Unmanaged FSMs can activate on either server and fail over to the  peer
       server without a hardware reset under normal operating conditions.

       On non-HA setups, the special HaUnmonitored type is used to indicate no
       HA monitoring is done on the file systems.  It is only to  be  used  on
       non-HA setups.

     o XML: inodeCacheSize <value>

       Old: nodeCacheSize <value>

       This variable defines how many inodes can be cached in the FSM program.
       An in-core inode is approximately 800 - 1000 bytes per entry.

     o XML: inodeDeleteMax <value>

       Old: InodeDeleteMax <value>

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

       Sets  the trickle delete rate of inodes that fall under the Perfect Fit
       check (see the Force Perfect Fit option for more information.  If Inode
       Delete  Max  is set to 0 or is excluded from the configuration file, it
       is set to an internally calculated value.

     o XML: inodeExpandMin <file_system_blocks>

       Old: InodeExpandMin <file_system_blocks>

     o XML: inodeExpandInc <file_system_blocks>

       Old: InodeExpandInc <file_system_blocks>

     o XML: inodeExpandMax <file_system_blocks>

       Old: InodeExpandMax <file_system_blocks>

       The inodeExpandMin, inodeExpandInc and inodeExpandMax variables config-
       ure the floor, increment and ceiling, respectively, for the block allo-
       cation size of a dynamically expanding file.  The new  format  requires
       this value be specified in bytes and multipliers are not supported.  In
       the old format, when the value is specified without a  multiplier  suf-
       fix, it is a number of volume blocks; when specified with a multiplier,
       it is bytes.

       The first time a file requires space, inodeExpandMin blocks  are  allo-
       cated.  When  an  allocation is exhausted, a new set of blocks is allo-
       cated equal to the size of the previous allocation to  this  file  plus
       inodeExpandInc   additional  blocks.  Each  new  allocation  size  will
       increase until the allocations reach inodeExpandMax blocks. Any  expan-
       sion  that  occurs thereafter will always use inodeExpandMax blocks per
       expansion.

       NOTE: when inodeExpandInc is not a factor of  inodeExpandMin,  all  new
       allocation  sizes  will be rounded up to the next inodeExpandMin bound-
       ary. The allocation increment rules are  still  used,  but  the  actual
       allocation size is always a multiple of inodeExpandMin.

       NOTE:  The  explicit use of the configuration variables inodeExpandMin,
       inodeExpandInc and inodeExpandMax are being deprecated in favor  of  an
       internal table driven mechanism.  Although they are still supported for
       backward compatibility, there may be warnings during the conversion  of
       an old configuration file to an XML format.

     o XML: inodeStripeWidth <value>

       Old: InodeStripeWidth <value>

       The  Inode  Stripe  Width variable defines how a file is striped across
       the volume's data storage pools.  After the  initial  placement  policy
       has  selected a storage pool for the first extent of the file, for each
       Inode Stripe Width extent the allocation is changed to prefer the  next
       storage  pool  allowed  to  contain file data.  Next refers to the next
       numerical stripe group number going up  or  down.   (The  direction  is
       determined  using  the  inode number: odd inode numbers go up or incre-
       ment, and even inode numbers go down or decrement).   The  rotation  is
       modulo the number of stripe groups that can hold data.

       When  Inode  Stripe  Width is not specified, file data allocations will
       typically attempt to use the same storage pool as the  initial  alloca-
       tion  to the file.  For an exception, see also AllocSessionReservation-
       Size.

       When used with an Allocation Strategy setting of Round, files  will  be
       spread  around  the allocation groups both in terms of where their ini-
       tial allocation is and in how the file contents are spread out.

       Inode Stripe Width is intended for  large  files.   The  typical  value
       would  be  many  times  the  maximum Stripe Breadth of the data storage
       pools. The value cannot be less than the maximum Stripe Breadth of  the
       data  storage  pools.  Note that when some storage pools are full, this
       policy will start to prefer the storage pool  logically  following  the
       full  one.  A typical value is 1 GB (1073741824) or 2 GBs (2147483648).
       The size is capped at 1099511627776 (1TB).

       If this value is configured too small, fragmentation can  occur.   Con-
       sider using a setting of 1MB with files as big as 100 GBs.  Each 100 GB
       file would have 102,400 extents!

       The new format requires this value be specified in bytes, and multipli-
       ers  are not supported.  In the old format, when the value is specified
       without a multiplier suffix, it is a  number  of  volume  blocks;  when
       specified with a multiplier, it is bytes.

       When  AllocSessionReservationSize is non-zero, this parameter is forced
       to be >= AllocSessionReservationSize.  This includes the case where the
       setting is 0.

       If  Inode  Stripe  Width  is  greater than AllocSessionReservationSize,
       files larger than AllocSessionReservationSize  will  use  Inode  Stripe
       Width as their AllocSessionReservationSize for allocations with an off-
       set beyond AllocSessionReservationSize.

     o XML: journalSize <value>

       Old: JournalSize <value>

       Controls the size of the volume journal.   cvupdatefs(1)  must  be  run
       after changing this value for it to take effect.

     o XML: maxConnections <value>

       Old: MaxConnections <value>

       The maxConnections value defines the maximum number of Xsan clients and
       Administrative Tap (AT) clients that may be connected to the FSM  at  a
       given time.

     o XML: maxLogs <value>

       Old: MaxLogs <value>

       The  maxLogs  variable  defines  the  maximum  number of logs a FSM can
       rotate through when they get  to  MaxLogSize.   The  current  log  file
       resides in /Library/Logs/Xsan/data/<file_system_name>/log/cvlog.

     o XML: maxLogSize <value>

       Old: MaxLogSize <value>

       The  maxLogSize  variable defines the maximum number of bytes a FSM log
       file    should    grow    to.    The    log     file     resides     in
       /Library/Logs/Xsan/data/<file_system_name>/log/cvlog.    When  the  log
       file grows to the specified size, it is moved to cvlog_<number>  and  a
       new  cvlog is started. Therefore, maxLogs the space will be consumed as
       specified in <value>.

     o XML: namedStreams 

       Old: NamedStreams 

       The namedStreams parameter enables or disables support for Apple  Named
       Streams.   Named  Streams are utilized by Apple Xsan clients.  If Named
       Streams support is enabled, storageManager and snPolicy  must  be  dis-
       abled.   Enabling Named Streams support on a file system is a permanent
       change.  It cannot be disabled once enabled.   Only Apple Xsan  clients
       should  be  used  with  named  streams enabled volumes.  Use of clients
       other than Apple Xsan may result in loss of named streams data.

     o XML: opHangLimitSecs <value>

       Old: OpHangLimitSecs <value>

       This variable defines the time threshold used by  the  FSM  program  to
       discover  hung  operations.  The default is 180.  It can be disabled by
       specifying 0.  When the FSM program detects an I/O hang, it  will  stop
       execution in order to initiate failover to backup system.

     o XML: perfectFitSize <value>

       Old: PerfectFitSize <value>

       For  files  in  perfect fit mode, all allocations will be rounded up to
       the number of volume blocks set by this variable.  Perfect fit mode can
       be  enabled  on  an  individual  file  by an application using the Xsan
       extended API, or for an entire file system by setting  forcePerfectFit.

       If  InodeStripeWidth  or  AllocSessionReservationSize  are non-zero and
       Perfect fit is not being applied to an  allocation,  this  rounding  is
       skipped.

     o XML: quotas 

       Old: Quotas 

       The  quotas  variable enables or disables the enforcement of the volume
       quotas. Enabling the quotas feature allows storage usage to be  tracked
       for  individual  users  and groups. Setting hard and soft quotas allows
       administrators to limit the amount of storage consumed by a  particular
       user/group  ID.  See  cvadmin(1) for information on quotas feature com-
       mands.

       NOTE: Enabling the quotas feature  automatically  enables  windowsSecu-
       rity.   When  quotas  is enabled, the meta-data controller must stay on
       either Windows or a non-Windows machine.

     o XML: quotaHistoryDays <value>

       Old: QuotaHistoryDays <value>

       When the quotas variable (see  above)  is  turned  on,  there  will  be
       nightly  logging of the current quota limits and values.  The logs will
       be placed  in  the  /Library/Logs/Xsan/data/<volume_name>/quota_history
       directory.  This variable specifies the number of days of logs to keep.
       Valid values are 0 (no logs are kept) to 3650 (10 years of nightly logs
       are kept).  The default is 7.

     o XML: remoteNotification RemoteNotification 

       The  remoteNotification  variable controls the Windows Remote Directory
       Notification feature.  The default value is no which disables the  fea-
       ture.   Note:  this  option  is not intended for general use.  Only use
       when recommended by Apple Support.

     o XML: reservedSpace 

       Old: ReservedSpace 

       The reservedSpace parameter allows the  administrator  the  ability  to
       control  the  use of delayed allocations on clients.  The default value
       is Yes.  reservedSpace is a performance feature that allows clients  to
       perform  buffered writes on a file without first obtaining real alloca-
       tions from the FSM.  The allocations are later performed when the  data
       are flushed to disk in the background by a daemon performing a periodic
       sync.

       When reservedSpace is true, the FSM reserves enough disk space so  that
       clients  are  able  to  safely  perform these delayed allocations.  The
       meta-data server reserves a minimum of 4GB per stripe group and  up  to
       280 megabytes per client per stripe group.

       Setting  reservedSpace  to  false allows slightly more disk space to be
       used, but adversely affects buffer cache performance and may result  in
       serious fragmentation.

     o XML: stripeAlignSize <value>

       Old: StripeAlignSize <value>

       The  stripeAlignSize  statement  causes  the allocator to automatically
       attempt stripe alignment and rounding of allocations  greater  than  or
       equal to this size.  The new format requires this value be specified in
       bytes and multipliers are not supported.  In the old format,  when  the
       value  is specified without a multiplier suffix, it is a number of vol-
       ume blocks; when specified with a multiplier, it is bytes.  If  set  to
       default  value  (-1),  it  internally  gets  set to the size of largest
       stripeBreadth found for any stripeGroup that can  hold  user  data.   A
       value  of 0 turns off automatic stripe alignment.  Stripe-aligned allo-
       cations are rounded up so that allocations are one  stripe  breadth  or
       larger.

       If  an  allocation fails with stripe alignment enabled, another attempt
       is made to allocate the space without stripe alignment.

       If AllocSessionReservationSize is enabled, stripeAlignSize is set to  0
       to  reduce  fragmentation  within  segments  which occurs when clipping
       within segments.

     o XML: threadPoolSize <value>

       Old: ThreadPoolSize <value>

       The threadPoolSize variable defines the number of client  pool  threads
       that  will be activated and used by the FSM. This variable also affects
       performance. There should be at least two threads per client, but  more
       threads  will  improve  volume  response time in operations that affect
       allocation and meta-data functions.

       The number of threads active in the FSM may affect performance  of  the
       system  it  is running on. Too many threads on a memory-starved machine
       will cause excessive swapping. It is recommended that system monitoring
       be  used  to  carefully watch FSM activity when analyzing system sizing
       requirements.

     o XML: trimOnClose <value>

       Old: TrimOnClose <value>

       NOTE: Not intended for general use.  Only use when recommended by Apple
       Support.

     o XML: unixDirectoryCreationModeOnWindows <value>

       Old: UnixDirectoryCreationModeOnWindows <value>

       The  unixDirectoryCreationModeOnWindows  variable  instructs the FSM to
       pass this value back to Microsoft Windows clients.   The  Windows  Xsan
       clients will then use this value as the permission mode when creating a
       directory.  The default value is 0755.  This value must  be  between  0
       and 0777, inclusive.

     o XML: unixFileCreationModeOnWindows <value>

       Old: UnixFileCreationModeOnWindows <value>

       The  unixFileCreationModeOnWindows  variable  instructs the FSM to pass
       this value back to Microsoft Windows clients. The Windows Xsan  clients
       will  then  use this value as the permission mode when creating a file.
       The default value is 0644.  This value must  be  between  0  and  0777,
       inclusive.

     o XML: unixIdFabricationOnWindows 

       Old: UnixIdFabricationOnWindows 

       The  unixIdFabricationOnWindows  variable  is  simply  passed back to a
       Microsoft Windows client. The client  uses  this  information  to  turn
       on/off  "fabrication"  of  uid/gids  from  a Microsoft Active Directory
       obtained GUID for a given Windows user.  A value of yes will cause  the
       client  for  this volume to fabricate the uid/gid and possibly override
       any specific uid/gid already in Microsoft Active Directory for the Win-
       dows  user.  This setting should only be enabled if it is necessary for
       compatibility with Apple MacOS clients.  The default is  false,  unless
       the  meta-data  server  is  running on Apple MacOS, in which case it is
       true.

     o XML: unixNobodyGidOnWindows <value>

       Old: UnixNobodyGidOnWindows <value>

       The unixNobodyGidOnWindows variable instructs  the  FSM  to  pass  this
       value  back to Microsoft Windows clients. The Windows Xsan clients will
       then use this value as the gid for a Windows user when no  gid  can  be
       found  using  Microsoft  Active Directory.  The default value is 60001.
       This value must be between 0 and 2147483647, inclusive.

     o XML: unixNobodyUidOnWindows <value>

       Old:

       The unixNobodyUidOnWindows variable instructs  the  FSM  to  pass  this
       value  back to Microsoft Windows clients. The Windows Xsan clients will
       then use this value as the uid for a Windows user when no  uid  can  be
       found  using  Microsoft  Active Directory.  The default value is 60001.
       This value must be between 0 and 2147483647, inclusive.

     o XML: windowsSecurity 

       Old: WindowsSecurity 

       The WindowsSecurity variable enables or disables the use of the Windows
       Security  Reference  Monitor  (ACLs)  on Windows clients. This does not
       affect the behavior of Unix clients.  In  a  mixed  client  environment
       where  there  is no specific Windows User to Unix User mapping (see the
       Windows control panel), files under Windows security will be  owned  by
       NOBODY  in  the  Unix  view.  The default of this variable is false for
       configuration files using the old format and true when  using  the  new
       XML format.  This value may be modified for existing volumes.

       NOTE: Once windowsSecurity has been enabled, the volume will track Win-
       dows access lists for the life of the volume  regardless  of  the  win-
       dowsSecurity value.

DISKTYPE DEFINITION

       A  diskType  defines  the  number  of  sectors  for  a category of disk
       devices, and optionally the number of bytes  per  disk  device  sector.
       Since  multiple  disks  used in a file system may have the same type of
       disk, it is easier to consolidate that information  into  a  disk  type
       definition rather than including it for each disk definition.

       For example, a 9.2GB Seagate Barracuda Fibre Channel ST19171FC disk has
       1778311 total sectors. However, using most drivers, a  portion  of  the
       disk  device  is  used for the volume header. For example, when using a
       Prisa adapter and driver, the maximum number of  sectors  available  to
       the volume is 11781064.

       When  specified,  the  sector size must be between 512 and 65536 bytes,
       and it must be a power of 2.  The default sector size is 512 bytes.

DISK DEFINITION

       Note: The XML format defines disks in the stripeGroup section. The  old
       format defines disks in a separate section and then links to that defi-
       nition with the node variable in the stripe group. The general descrip-
       tion below applies to both.

       Each  disk  defines  a  disk device that is in the Storage Area Network
       configuration. The name of each disk device must be  entered  into  the
       disk  device's volume header label using cvlabel(1).  Disk devices that
       the client cannot see will not be accessible, and any stripe group con-
       taining  an  inaccessible  disk  device  will not be available, so plan
       stripe groups accordingly.  Entire disks must be specified here; parti-
       tions may not be used.

       The  disk  definition's  name must be unique, and is used by the volume
       administrator programs.

       A disk's status may be up or down.  When down, this device will not  be
       accessible.  Users may still be able to see directories, file names and
       other meta-data if the disk is in a stripe  group  that  only  contains
       userdata,  but  attempts  to  open  a  file affected by the downed disk
       device will receive an Operation Not Permitted (EPERM) failure.  When a
       volume  contains  down data storage pools, space reporting tools in the
       operating system will not count these storage pools  in  computing  the
       total  volume  size  and  available  free blocks.  NOTE: when files are
       removed that only contain extents on down storage pools, the amount  of
       available free space displayed will not change.

       Each  disk definition has a type which must match one of the names from
       a previously defined diskType.

       NOTE: In much older releases there was also a DeviceName option in  the
       Disk  section.  The DeviceName was previously used to specify a operat-
       ing system specific disk name, but this has been  superseded  by  auto-
       matic  volume  recognition  for  some  time and is no longer supported.
       This is now for internal use only.

STRIPEGROUP DEFINITION

       The stripeGroup defines individual storage pools.  A storage pool is  a
       collection  of  disk  devices. A disk device may only be in one storage
       pool.

       The stripeGroup has a name name  that  is  used  in  subsequent  system
       administration functions for the storage pool.

       A storage pool can be set to have it's status up or down.  If down, the
       storage pool is not used by the file system, and anything on that stor-
       age pool is inaccessible.  This should normally be left up.

       A storage pool can contain a combination of metadata, journal, or user-
       data.  There can only be one storage pool that contains a  journal  per
       file  system.   Typically,  metadata and journal are kept separate from
       userdata for performance reasons.  Ideally, the journal will be kept on
       its own stripe group as well.

       When  a  collection  of disk devices is assembled under a storage pool,
       each disk device is logically striped into chunks  of  disk  blocks  as
       defined  by  the  stripeBreadth  variable.  For example, with a 4k-byte
       block-size and a stripe breadth of 86 volume blocks, the first  352,256
       bytes  would  be  written  or read from/to the first disk device in the
       storage pool, the second 352,256 bytes would  be  on  the  second  disk
       device and so on. When the last disk device used its 352,256 bytes, the
       stripe would start again at drive zero. This allows  for  more  than  a
       single disk device's bandwidth to be realized by applications.

       The allocator aligns an allocation that is greater than or equal to the
       largest stripeBreadth of any storage pool that can hold data.  This  is
       done if the allocation request is an extension of the file.

       A  storage  pool  can  be  marked up or down.  When the storage pool is
       marked down, it is not available for data access.  However,  users  may
       look  at  the  directory  and meta-data information. Attempts to open a
       file residing on a downed storage pool will receive a Permission Denied
       failure.

       There  is  an  option  to  turn off reads to a stripe group.  NOTE: Not
       intended for general use.  Only use when recommended by Apple  Support.

       A  storage  pool can have write access denied.  If writes are disabled,
       then any new allocations are disallowed as well.  When  a  volume  con-
       tains data storage pools with writes disabled, space reporting tools in
       the operating system will show all blocks for the storage pool as used.
       Note  that  when  files are removed that only contain extents on write-
       disabled storage pools, the amount of available  free  space  displayed
       will  not  change.  This is typically only used during Dynamic Resource
       Allocation procedures (see the StorNext User Guide for more details).

       Affinities can be used to target allocations at specific stripe groups,
       and  the stripe group can exclusively contain affinity targeted alloca-
       tions or have affinity  targeted  allocations  co-existing  with  other
       allocations.  See snfs.cfg(5) and snfs.cfgx(5) for more details.

       Each  stripe  group  can  define a multipath method, which controls the
       algorithm used to allocate disk I/Os on paths to the storage  when  the
       volume  has multiple paths available to it. See cvadmin(1) for details.

       Various realtime I/O parameters can be specified on a per stripe  group
       basis  as  well.  These define the maximum number of I/O operations per
       second available to real-time applications for the stripe  group  using
       the Quality of Service (QoS) API.  There is also the ability to specify
       I/Os that should be reserved for applications not using  the  QoS  API.
       Realtime I/O functionality is off by default.

       A  stripe  group  contains  one or more disks on which to put the meta-
       data/journal/userdata.  The disk has an index that defines the  ordinal
       position  the  disk has in the storage pool. This number must be in the
       range of zero to the number of disks in the storage pool minus one, and
       be  unique  within  the  storage pool. There must be one disk entry per
       disk and the number of disk entries defines the stripe depth.  For more
       information about disks, see the DISK DEFINITION section above.

       NOTE:  The StripeClusters variable has been deprecated.  It was used to
       limit I/O submitted by a single process, but was removed when asynchro-
       nous I/O was added to the volume.

       NOTE: The Type variable for Stripe Groups has been deprecated.  Several
       versions ago, the Type parameter was  used  as  a  very  course-grained
       affinity-like  control  of how data was laid out between stripe groups.
       The only valid value of Type for several releases of SNFS has been Reg-
       ular, and this is now deprecated as well for the XML configuration for-
       mat.  Type has been superceded by Affinity.

FILES

       /Library/Preferences/Xsan/*.cfgx
       /Library/Preferences/Xsan/*.cfg

SEE ALSO

       snfs.cfgx(5), snfs.cfg(5), sncfgedit(1), cnvt2ha.sh(1), cvfs(1),  cvad-
       min(1), cvlabel(1), cvmkdir(1), cvmkfile(1), ha_peer(4), mount_acfs(1)

Xsan File System                 December 2011                  snfs_config(5)