StorNext File System Known Issues

Table 1 lists known issues specific to the StorNext File System process.

**Table 1:** StorNext File System Known Issues
Operating System	Change Request Number	Service Request Number	Description/Workaround
All	54834	3505208, 3516356	If a file is being copied to the StorNext file system using Windows Explorer and Windows Explorer crashes before it finishes copying all the data, the file may contain data blocks from old, deleted files. This problem occurs because Windows Explorer sets EOF to the size of the file before it writes the data to the file. This leaves a gap of uninitialized data in the file. Note: This problem can also occur with other programs that set EOF beyond the end of data. This problem does not occur if Windows Explorer encounters an error while writing the file; Windows Explorer will delete the partially written file. Workaround: To prevent this problem from occurring on StorNext, you can use the StorNext "client configuration" application's advanced mount option "Restrict Pre-allocation API" on Window systems and the "`protect_alloc=yes`" mount option on Linux systems. This option will set the unwritten parts of the file to zero. When this option is set, non-root users are unable to use the preallocation ioctl. This option also implies `sparse=yes`. For more information on this option, see the man page `mount_cvfs(8)`. The sparse option will introduce some overhead when using Windows Explorer. Before setting the `protect_alloc` option, see the sparse option in `mount_cvfs(8)` for a description of how it changes StorNext behavior.
All	64963	n/a	See Conditions for Mounting an Xsan Volume as a StorNext Distributed LAN Client (DLC).
Mac OS	66948	322824, 336945	If you access StorNext file systems from Apple Xsan clients, then you might encounter I/O error messages in the system log that do not contain details about real I/O errors detected on the Xsan client. Workaround If you encounter the errors on an Xsan client, contact Apple.

Conditions for Mounting an Xsan Volume as a StorNext Distributed LAN Client (DLC)

Beginning with Apple's OS X El Capitan (10.11), support is provided to mount Xsan volumes as StorNext DLC clients. This section provides additional information which should clarify the conditions necessary for this mount to succeed.

When the StorNext services are loaded, the environment is scanned to determine the default mount type - storage area network (SAN) with access to data disks, or DLC with proxy access to data disks through a StorNext gateway node.

If a fibre channel card is detected or internet Small Computer Systems Interface (iSCSI) logical unit numbers (LUNs) are present, the default mode is SAN. If neither or these conditions are true, the default mode is DLC.

In the case that a SAN mount is attempted and not all data LUNs for the file system are present, the mount fails and no error message is logged. If a DLC mount is desired, there are several ways to accomplish this.

First, if the presence of iSCSI LUNs is causing the SAN mount attempt, and these LUNs are not needed, the iSCSI targets can be disconnected. If this is done, the StorNext service must be unloaded and loaded to detect the change.

Example of unload and load:

sh-3.2# launchctl unload /System/Library/LaunchDaemons/com.apple.xsan.plist

sh-3.2# launchctl load -w /System/Library/LaunchDaemons/com.apple.xsan.plist

If iSCSI LUNs or a fibre channel card are present, the DLC mount is accomplished by indicating this to the driver. There are two ways to achieve this:

Set the Xsan Preferences Payload "preferDLC" for the Volume that is to be DLC Mounted
Set the diskproxy=client Mount Options in the /etc/fstab File

Set the Xsan Preferences Payload "preferDLC" for the Volume that is to be DLC Mounted

Example of setting preferDLC payload and verifying:

sh-3.2# defaults read /Library/Preferences/com.apple.xsan
{
    enableSpotlightServer = 1;
}
sh-3.2# defaults write /Library/Preferences/com.apple.xsan preferDLC '(snfs1)'
sh-3.2# defaults read /Library/Preferences/com.apple.xsan
{
    enableSpotlightServer = 1;
    preferDLC =     (
        snfs1
    );
}

For more information on the preferDLC payload and Xsan configuration profiles, see https://support.apple.com/en-us/HT205333.

Set the diskproxy=client Mount Options in the /etc/fstab File

An alternative way to indicate to the driver that a DLC mount is desired to set the diskproxy=client mount options in the /etc/fstab file.

Example of the diskproxy=client mount options in /etc/fstab file:

sh-3.2# cat /etc/fstab
LABEL=snfs1	none	acfs	rw,diskproxy=client
sh-3.2#

In either of the above scenarios, a driver unload and load must be performed to enact the change. Once the Volume is mounted, its status as a DLC client can be verified by using the sub-command who of the cvadmin CLI. First select the file system, then enter who. Look for the C after the CLI in the client entry.

Example of the cvadmin who sub-command:

Xsanadmin (snfs1) > select snfs1 Xsanadmin (snfs1) > who Who (File System "snfs1") # acfs I.D. Type Location Up Time License Expires -- ---------- ---- --------------- --------- --------------- 0> FSM smw-rhel64.mdh.quantum.com 4d 23h 33m N/A 4> 50569B3B7F CLI S smw-rhel64.mdh.quantum.com 4d 23h 33m *10-27-2016 23:59:59 9> ADM smw-elcapitan.mdh.quantum.com 0d 0h 0m N/A 17> CLI C smw-elcapitan.mdh.quantum.com 0d 0h 6m N/A 1 active connection out of 65535 licensed connections 0 active connections out of 65535 licensed proxy connections 1 active gateway connection 1 active client-licensed connection Xsanadmin (snfs1) >