On Linux, the StorNext configuration file uses an XML format (.cfgx). On Windows, the configuration file uses a text format (.cfg). However, the values contained in both files are similar.
You can locate an example StorNext configuration file in the following directory:
- Linux: /usr/cvfs/examples/example.cfgx
-
Windows: C:\Program Files\Stornext\config\example.cfg
If you installed StorNext in a location other than the default installation directory, the example configuration file is located in C:\<install_directory>\config\example.cfg
For additional information about the snfs.cfgx and snfs.cfg files, refer to the “snfs_config” entry in the Man Pages Reference Guide.
Linux Example Configuration File
Below are the contents of the StorNext example configuration file for Linux (example.cfgx):
<?xml version="1.0"?>
<snfs:configDoc xmlns:snfs="https://www.quantum.com/snfs" version="1.0">
<snfs:config configVersion="0" name="example" fsBlockSize="4096" journalSize="67108864">
<snfs:globals>
<snfs:affinityPreference>false</snfs:affinityPreference>
<snfs:allocationStrategy>round</snfs:allocationStrategy>
<snfs:haFsType>HaUnmonitored</snfs:haFsType>
<snfs:bufferCacheSize>268435456</snfs:bufferCacheSize>
<snfs:cvRootDir>/</snfs:cvRootDir>
<snfs:storageManager>false</snfs:storageManager>
<snfs:debug>00000000</snfs:debug>
<snfs:dirWarp>true</snfs:dirWarp>
<snfs:extentCountThreshold>49152</snfs:extentCountThreshold>
<snfs:enableSpotlight>false</snfs:enableSpotlight>
<snfs:spotlightUseProxy>false</snfs:spotlightUseProxy>
<snfs:enforceAcls>false</snfs:enforceAcls>
<snfs:fileLocks>false</snfs:fileLocks>
<snfs:fileLockResyncTimeOut>20</snfs:fileLockResyncTimeOut>
<snfs:forcePerfectFit>false</snfs:forcePerfectFit>
<snfs:fsCapacityThreshold>0</snfs:fsCapacityThreshold>
<snfs:globalSuperUser>true</snfs:globalSuperUser>
<snfs:ignorePermissions>false</snfs:ignorePermissions>
<snfs:inodeCacheSize>131072</snfs:inodeCacheSize>
<snfs:inodeExpandMin>0</snfs:inodeExpandMin>
<snfs:inodeExpandInc>0</snfs:inodeExpandInc>
<snfs:inodeExpandMax>0</snfs:inodeExpandMax>
<snfs:inodeDeleteMax>0</snfs:inodeDeleteMax>
<snfs:inodeStripeWidth>4294967296</snfs:inodeStripeWidth>
<snfs:ioTokens>true</snfs:ioTokens>
<snfs:maintenanceMode>false</snfs:maintenanceMode>
<snfs:maxLogs>4</snfs:maxLogs>
<snfs:namedStreams>false</snfs:namedStreams>
<snfs:remoteNotification>false</snfs:remoteNotification>
<snfs:renameTracking>false</snfs:renameTracking>
<snfs:reservedSpace>true</snfs:reservedSpace>
<snfs:fsmRealTime>false</snfs:fsmRealTime>
<snfs:fsmMemLocked>false</snfs:fsmMemLocked>
<snfs:opHangLimitSecs>180</snfs:opHangLimitSecs>
<snfs:perfectFitSize>131072</snfs:perfectFitSize>
<snfs:quotas>false</snfs:quotas>
<snfs:quotaHistoryDays>7</snfs:quotaHistoryDays>
<snfs:metadataArchive>false</snfs:metadataArchive>
<snfs:metadataArchiveDir></snfs:metadataArchiveDir>
<snfs:metadataArchiveDays>0</snfs:metadataArchiveDays>
<snfs:metadataArchiveSearch>true</snfs:metadataArchiveSearch>
<snfs:metadataArchiveCache>2147483648</snfs:metadataArchiveCache>
<snfs:drCopy>false</snfs:drCopy>
<snfs:audit>false</snfs:audit>
<snfs:restAccess>privileged</snfs:restAccess>
<snfs:securityModel>legacy</snfs:securityModel>
<snfs:stripeAlignSize>-1</snfs:stripeAlignSize>
<snfs:trimOnClose>0</snfs:trimOnClose>
<snfs:useL2BufferCache>true</snfs:useL2BufferCache>
<snfs:unixDirectoryCreationModeOnWindows>755</snfs:unixDirectoryCreationModeOnWindows>
<snfs:unixIdFabricationOnWindows>false</snfs:unixIdFabricationOnWindows>
<snfs:unixFileCreationModeOnWindows>644</snfs:unixFileCreationModeOnWindows>
<snfs:unixNobodyUidOnWindows>60001</snfs:unixNobodyUidOnWindows>
<snfs:unixNobodyGidOnWindows>60001</snfs:unixNobodyGidOnWindows>
<snfs:windowsSecurity>true</snfs:windowsSecurity>
<snfs:windowsIdMapping>ldap</snfs:windowsIdMapping>
<snfs:unixIdMapping>none</snfs:unixIdMapping>
<snfs:globalShareMode>false</snfs:globalShareMode>
<snfs:useActiveDirectorySFU>true</snfs:useActiveDirectorySFU>
<snfs:eventFiles>true</snfs:eventFiles>
<snfs:eventFileDir></snfs:eventFileDir>
<snfs:allocSessionReservationSize>1073741824</snfs:allocSessionReservationSize>
</snfs:globals>
<snfs:diskTypes>
<snfs:diskType typeName="MetaDrive" sectors="99999999" sectorSize="512"/>
<snfs:diskType typeName="JournalDrive" sectors="99999999" sectorSize="512"/>
<snfs:diskType typeName="VideoDrive" sectors="99999999" sectorSize="512"/>
<snfs:diskType typeName="AudioDrive" sectors="99999999" sectorSize="512"/>
<snfs:diskType typeName="DataDrive" sectors="99999999" sectorSize="512"/>
</snfs:diskTypes>
<snfs:autoAffinities/>
<snfs:stripeGroups>
<snfs:stripeGroup index="0" status="up" name="MetaFiles" stripeBreadth="262144" read="true" write="true" alloc="true" metadata="true" journal="false" userdata="false" realTimeIOs="0" realTimeIOsReserve="0" realTimeMB="0" realTimeMBReserve="0" realTimeTokenTimeout="0" multipathMethod="rotate">
<snfs:disk index="0" diskLabel="CvfsDisk0" diskType="MetaDrive" ordinal="0"/>
</snfs:stripeGroup>
<snfs:stripeGroup index="1" status="up" name="JournFiles" stripeBreadth="262144" read="true" write="true" alloc="true" metadata="false" journal="true" userdata="false" realTimeIOs="0" realTimeIOsReserve="0" realTimeMB="0" realTimeMBReserve="0" realTimeTokenTimeout="0" multipathMethod="rotate">
<snfs:disk index="0" diskLabel="CvfsDisk1" diskType="JournalDrive" ordinal="1"/>
</snfs:stripeGroup>
<snfs:stripeGroup index="2" status="up" name="VideoFiles" stripeBreadth="4194304" read="true" write="true" alloc="true" metadata="false" journal="false" userdata="true" realTimeIOs="0" realTimeIOsReserve="0" realTimeMB="0" realTimeMBReserve="0" realTimeTokenTimeout="0" multipathMethod="rotate">
<snfs:affinities exclusive="true">
<snfs:affinity>Video</snfs:affinity>
</snfs:affinities>
<snfs:disk index="0" diskLabel="CvfsDisk2" diskType="VideoDrive" ordinal="2"/>
<snfs:disk index="1" diskLabel="CvfsDisk3" diskType="VideoDrive" ordinal="3"/>
<snfs:disk index="2" diskLabel="CvfsDisk4" diskType="VideoDrive" ordinal="4"/>
<snfs:disk index="3" diskLabel="CvfsDisk5" diskType="VideoDrive" ordinal="5"/>
<snfs:disk index="4" diskLabel="CvfsDisk6" diskType="VideoDrive" ordinal="6"/>
<snfs:disk index="5" diskLabel="CvfsDisk7" diskType="VideoDrive" ordinal="7"/>
<snfs:disk index="6" diskLabel="CvfsDisk8" diskType="VideoDrive" ordinal="8"/>
<snfs:disk index="7" diskLabel="CvfsDisk9" diskType="VideoDrive" ordinal="9"/>
</snfs:stripeGroup>
<snfs:stripeGroup index="3" status="up" name="AudioFiles" stripeBreadth="1048576" read="true" write="true" alloc="true" metadata="false" journal="false" userdata="true" realTimeIOs="0" realTimeIOsReserve="0" realTimeMB="0" realTimeMBReserve="0" realTimeTokenTimeout="0" multipathMethod="rotate">
<snfs:affinities exclusive="true">
<snfs:affinity>Audio</snfs:affinity>
</snfs:affinities>
<snfs:disk index="0" diskLabel="CvfsDisk10" diskType="AudioDrive" ordinal="10"/>
<snfs:disk index="1" diskLabel="CvfsDisk11" diskType="AudioDrive" ordinal="11"/>
<snfs:disk index="2" diskLabel="CvfsDisk12" diskType="AudioDrive" ordinal="12"/>
<snfs:disk index="3" diskLabel="CvfsDisk13" diskType="AudioDrive" ordinal="13"/>
</snfs:stripeGroup>
<snfs:stripeGroup index="4" status="up" name="RegularFiles" stripeBreadth="262144" read="true" write="true" alloc="true" metadata="false" journal="false" userdata="true" realTimeIOs="0" realTimeIOsReserve="0" realTimeMB="0" realTimeMBReserve="0" realTimeTokenTimeout="0" multipathMethod="rotate">
<snfs:disk index="0" diskLabel="CvfsDisk14" diskType="DataDrive" ordinal="14"/>
<snfs:disk index="1" diskLabel="CvfsDisk15" diskType="DataDrive" ordinal="15"/>
<snfs:disk index="2" diskLabel="CvfsDisk16" diskType="DataDrive" ordinal="16"/>
<snfs:disk index="3" diskLabel="CvfsDisk17" diskType="DataDrive" ordinal="17"/>
</snfs:stripeGroup>
</snfs:stripeGroups>
<snfs:auxData/>
</snfs:config>
</snfs:configDoc>
The renameTracking Feature
Some Microsoft applications end up making temporary copies of operational files while they are being updated. For example while a file myDocument.doc is being updated with Word it may be renamed to a random sequence of characters like ABC123DYXab. When Word completes the updates it will save the new myDocument.doc file and remove ABC123DYXab. When Storage Manager recognizes that file ABC123DYXab has been removed it makes it recoverable but with the current temporary name. This makes tracking old instances of myDocument.doc difficult if not impossible to accomplish. To get around this scenario the renameTracking feature is provided. You can enable this feature on in the file system (see the snfs_config(5) man page) and makes tracking of old instances of these temporary files possible.
If you enable the renameTracking feature, as a file is renamed it is made recoverable at that time. For example, in the scenario described above as Word renames myDocument.doc to ABC123DYXab, Storage Manager makes myDocument.doc recoverable with its original name before the rename proceeds; that renamed instance becomes inactive. Then after Word is done, the new myDocument.doc becomes the new instance of the file and the previous instance becomes available for recovery using fsrecover(1) with the correct name.
Note: The renameTracking functionality is NOT a general purpose feature for keeping the Storage Manager database up to date with rename activity. If you enable the feature, then the files that are being renamed are re-stored. This is not, in general, a desirable behavior except in the specific case described.
Windows Example Configuration File
Below are the contents of the StorNext example configuration file for Windows (example.cfg):
# Globals affinityPreference No allocationStrategy Round HaFsType HaUnmonitored fileLocks No brlResyncTimeout 20 bufferCacheSize 256M cvRootDir / dataMigration No debug 0x0 dirWarp Yes ForcePerfectFit No FsBlockSize 4K GlobalSuperUser Yes IgnorePermissions No IoTokens Yes InodeCacheSize 128K InodeExpandMin 0 InodeExpandInc 0 InodeExpandMax 0 InodeDeleteMax 0 InodeStripeWidth 4G JournalSize 64M MaxLogs 4 PerfectFitSize 128K RemoteNotification No ReservedSpace Yes FSMRealtime No FSMMemlock No Quotas No QuotaHistoryDays 7 RestoreJournal No RestoreJournalMaxHours 0 RestoreJournalMaxMB 0 SecurityModel Legacy MetadataArchive No MetadataArchiveDays 0 DrCopy No audit No UnixIdFabricationOnWindows No UnixIdMapping none UnixNobodyUidOnWindows 60001 UnixNobodyGidOnWindows 60001 SecurityModel legacy WindowsIdMapping ldap WindowsSecurity Yes # Disk Types [DiskType MetaDrive] Sectors 99999999 SectorSize 512 [DiskType JournalDrive] Sectors 99999999 SectorSize 512 [DiskType VideoDrive] Sectors 99999999 SectorSize 512 [DiskType AudioDrive] Sectors 99999999 SectorSize 512 [DiskType DataDrive] Sectors 99999999 SectorSize 512 # Disks [Disk CvfsDisk0] Type MetaDrive Status UP [Disk CvfsDisk1] Type JournalDrive Status UP [Disk CvfsDisk2] Type VideoDrive Status UP [Disk CvfsDisk3] Type VideoDrive Status UP [Disk CvfsDisk4] Type VideoDrive Status UP [Disk CvfsDisk5] Type VideoDrive Status UP [Disk CvfsDisk6] Type VideoDrive Status UP [Disk CvfsDisk7] Type VideoDrive Status UP [Disk CvfsDisk8] Type VideoDrive Status UP [Disk CvfsDisk9] Type VideoDrive Status UP [Disk CvfsDisk10] Type AudioDrive Status UP [Disk CvfsDisk11] Type AudioDrive Status UP [Disk CvfsDisk12] Type AudioDrive Status UP [Disk CvfsDisk13] Type AudioDrive Status UP [Disk CvfsDisk14] Type DataDrive Status UP [Disk CvfsDisk15] Type DataDrive Status UP [Disk CvfsDisk16] Type DataDrive Status UP [Disk CvfsDisk17] Type DataDrive Status UP # Stripe Groups [StripeGroup MetaFiles] Status Up StripeBreadth 64 Metadata Yes Journal No Exclusive Yes Read Enabled Write Enabled Alloc Enabled Rtmb 0 Rtios 0 RtmbReserve 0 RtiosReserve 0 RtTokenTimeout 0 MultiPathMethod Rotate Node CvfsDisk0 0 [StripeGroup JournFiles] Status Up StripeBreadth 64 Metadata No Journal Yes Exclusive Yes Read Enabled Write Enabled Alloc Enabled Rtmb 0 Rtios 0 RtmbReserve 0 RtiosReserve 0 RtTokenTimeout 0 MultiPathMethod Rotate Node CvfsDisk1 0 [StripeGroup VideoFiles] Status Up StripeBreadth 1024 Metadata No Journal No Exclusive No Read Enabled Write Enabled Alloc Enabled Rtmb 0 Rtios 0 RtmbReserve 0 RtiosReserve 0 RtTokenTimeout 0 MultiPathMethod Rotate Node CvfsDisk2 0 Node CvfsDisk3 1 Node CvfsDisk4 2 Node CvfsDisk5 3 Node CvfsDisk6 4 Node CvfsDisk7 5 Node CvfsDisk8 6 Node CvfsDisk9 7 Affinity Video [StripeGroup AudioFiles] Status Up StripeBreadth 256 Metadata No Journal No Exclusive No Read Enabled Write Enabled Alloc Enabled Rtmb 0 Rtios 0 RtmbReserve 0 RtiosReserve 0 RtTokenTimeout 0 MultiPathMethod Rotate Node CvfsDisk10 0 Node CvfsDisk11 1 Node CvfsDisk12 2 Node CvfsDisk13 3 Affinity Audio [StripeGroup RegularFiles] Status Up StripeBreadth 64 Metadata No Journal No Exclusive No Read Enabled Write Enabled Alloc Enabled Rtmb 0 Rtios 0 RtmbReserve 0 RtiosReserve 0 RtTokenTimeout 0 MultiPathMethod Rotate Node CvfsDisk14 0 Node CvfsDisk15 1 Node CvfsDisk16 2 Node CvfsDisk17 3
The renameTracking Feature
Some Microsoft applications end up making temporary copies of operational files while they are being updated. For example while a file myDocument.doc is being updated with Word it may be renamed to a random sequence of characters like ABC123DYXab. When Word completes the updates it will save the new myDocument.doc file and remove ABC123DYXab. When Storage Manager recognizes that file ABC123DYXab has been removed it makes it recoverable but with the current temporary name. This makes tracking old instances of myDocument.doc difficult if not impossible to accomplish. To get around this scenario the renameTracking feature is provided. You can enable this feature on in the file system (see the snfs_config(5) man page) and makes tracking of old instances of these temporary files possible.
If you enable the renameTracking feature, as a file is renamed it is made recoverable at that time. For example, in the scenario described above as Word renames myDocument.doc to ABC123DYXab, Storage Manager makes myDocument.doc recoverable with its original name before the rename proceeds; that renamed instance becomes inactive. Then after Word is done, the new myDocument.doc becomes the new instance of the file and the previous instance becomes available for recovery using fsrecover(1) with the correct name.
Note: The renameTracking functionality is NOT a general purpose feature for keeping the Storage Manager database up to date with rename activity. If you enable the feature, then the files that are being renamed are re-stored. This is not, in general, a desirable behavior except in the specific case described.
