When installing TPSSM on a Windows client, you must choose Custom install and uncheck the TPSSM RDAC option. This will prevent the RDAC pseudo/virtual LUNs from being installed onto the system (installing these LUNs would have a detrimental affect on XVM failover V2 for the Windows client).

This section describes the differences and limitations of a CXFS filesystem on a Windows node from a UNIX perspective:

This section describes the differences and limitations of a CXFS filesystem on a Windows node in comparison to other Windows filesystems from a Windows perspective:

SGI recommends that you enable the forced unmount feature on CXFS filesystems. See “Enable Forced Unmount” in Chapter 2 and “Forced Unmount of CXFS Filesystems” in Chapter 10.

A forced unmount causes all processes that have open files on the specified filesystem to be unconditionally killed and therefore permit the filesystem to be unmounted without delay.

Windows, and therefore CXFS, may not detect any LUNs on a storage device if LUN 0 is not defined on the storage device. This problem may occur when CXFS Info reports that XVM is up, but one or more filesystems are not mounted and CXFS therefore retries the mount continuously. This problem has occurred on Windows XP CXFS clients. For more information about this issue, see the following (the problem exists for all supported Windows platforms):

http://support.microsoft.com/kb/821666/en-us

You can memory-map a file much larger than 2 GB under Windows, but only up to 2 GB of that file in one or more parts can be mapped into a process at any one time on a 32-bit platform. See the Windows Platform Software Development Kit for more details.

Windows does not support the CXFS mount scripts.

If Norton Ghost is installed on a node, CXFS cannot mount filesystems on the mount-point driver letter. You must uninstall Norton Ghost in order to use CXFS.

Under Windows XP, users may define their own local set of drive letter mappings that can override the global settings for the host. When identifying the filesystem mapped to a drive letter, Windows XP will check the local mappings and may hide CXFS from the user. Users and administrators of CXFS Windows nodes must avoid mapping network and CXFS drives to the same drive letter.

A Windows node running CXFS has the following filesystem limitations:

Support for unwritten extents is limited on Windows nodes. However, reading and writing unwritten extents will work correctly in the absence of concurrent reading and writing of the same file extent elsewhere in the cluster.

By default, User Account Control is enabled for Windows Vista, but it is not appropriate for use with CXFS. You must therefore disable user account control. See step 4 in “Client Software Installation for Windows”.

The CXFS software supports several user identification mechanisms, which are described in “User Identification Mapping Methods for Windows”. Windows user and group names that match entries in the configured user list will be mapped to those user IDs (UIDs) and group IDs (GIDs).

The following additional mappings are automatically applied:

A user's default UNIX GID is the default GID in the passwd listing for the user and is not based on a Windows group mapped to a UNIX group name.

You can display the users and groups that have been successfully mapped by looking at the tables for the User Map and Group Map tabs in the CXFS Info window.

The following sections assume that a CXFS Windows node was configured with the following passwd and group files:

C:\> type %ProgramFiles%\CXFS\passwd
root::0:0:Super-User:/root:/bin/tcsh
guest::998:998:Guest Account:/usr/people/guest:/bin/csh
fred::1040:402:Fred Costello:/users/fred:/bin/tcsh
diane::1052:402:Diane Green:/users/diane:/bin/tcsh

C:\> type %ProgramFiles%\CXFS\group
sys::0:root,bin,sys,adm
root::0:root
guest:*:998:
video::402:fred,diane
audio::403:fred

User identification can be performed by one choosing one of the following methods for the User ID mapping lookup sequence item of the Enter CXFS Details window:

For an example of the window, see Figure 9-6.

You must select one of these as the primary mapping method during installation, but you can change the method at a later time, as described in “Modifying the CXFS Software for Windows”.

Optionally, you can select a secondary mapping method that will be applied to users that are not covered by the first method. If you choose a primary and a secondary mapping method, one of them must be files.

For example, suppose the user has selected ldap_generic as the primary method and files as the secondary method. A user mapping will be created for all suitable ldap_generic users and this mapping will be extended with any additional users found in the secondary method (files). The primary method will be used to resolve any duplicate entries.

Suppose the primary method (ldap_generic) has users for UIDs 1, 2 and 3, and the secondary method (files ) has users for UIDs 2 and 4. The username for UIDs 1, 2 and 3 will be determined by the ldap_generic method and the username for UID 4 will be determined by the files method. If the LDAP lookup failed (such as if the LDAP server was down), a user mapping for UIDs 2 and 4 would be generated using the files method.

The default behavior is to use the files method to map Windows usernames to UNIX UIDs and GIDs, with no secondary method selected.

Regardless of the method used, the consistent mapping of usernames is a requirement to ensure consistent behavior on all CXFS nodes. Most platforms can be configured to use an LDAP database for user identification.

Access controls are enforced on the CXFS metadata server by using the mapped UID and GID of the user attempting to access the file. Therefore, a user can expect the same access on a Windows node as any other node in the cluster when mounting a given filesystem. Access is determined using the file's ACL, if one is defined, otherwise by using the file's mode bits.

ACLs that are set on any files or directories are also enforced as they would be on any Linux node. The presentation of ACLs is customized to the interfaces of Windows Explorer, so the enforcement of the ACL may vary from an NTFS ACL that is presented in the same way. A new file will inherit the parent directory default ACL, if one is defined.

The user Administrator has read and write access to all files on a CXFS filesystem, in the same way that root has superuser privileges on a UNIX node.

The following example is a directory listing on the metadata server:

MDS# ls -l
drwxr-x---    2 fred   video           6 Nov 20 13:33 dir1
-rw-r-----    1 fred   audio           0 Nov 20 12:59 file1
-rw-rw-r--    1 fred   video           0 Nov 20 12:59 file2

Users will have the following access to the contents of this directory:

File permissions may be viewed and manipulated in two different ways when using Windows Explorer:

The only file attribute that is supported by CXFS is the read-only attribute, other attributes will not be set by CXFS and changes to those attributes will be ignored.

If the user is not permitted to write to the file, the read-only attribute will be set. The owner of the file may change this attribute and modify the mode bits. Other users, including the user Administrator , will receive an error message if they attempt to change this attribute.

Marking a file read-only will remove the write bit from the user, group, and other mode bits on the file. Unsetting the read-only attribute will make the file writable by the owner only.

For example, selecting file properties on file1 using Windows Explorer on a CXFS Windows node will display the read-only attribute unset if logged in as Administrator or fred, and it will be set for diane and guest.

Only user fred will be able to change the attribute on these files, which will change the files under UNIX to the following:

-r--r-----    1 fred   audio           0 Nov 20 12:59 file1
-r--r--r--    1 fred   video           0 Nov 20 12:59 file2

If fred then unset these flags, only he could write to both files:

-rw-r-----    1 fred   audio           0 Nov 20 12:59 file1
-rw-r--r--    1 fred   video           0 Nov 20 12:59 file2

By selecting the Security tab in the File Properties window of a file, a user may view and change a file's permissions with a high level of granularity.

Windows Explorer will list the permissions of the file's owner and the file's group. The Everyone group, which represents the mode bits for other users, will also be displayed if other users have any access to the file. Not all Windows permission flags are supported.

The permissions on file1 are displayed as follows:

audio (cxfs1\audio)           Allow: Read
Fred Costello (cxfs1\fred)    Allow: Read, Write

Using the Advanced button, file1 is displayed as follows:

Allow    Fred Costello (cxfs1\fred)    Special
Allow    audio (cxfs1\audio)           Read

User fred is listed as having Special access because the permission flags in the next example do not exactly match the standard Windows permissions for read and write access to a file. Select Fred Costello and then click View/Edit to display the permission flags listed in Table 9-1. (The table displays the permissions in the order in which they appear in the View/Edit window). You can choose to allow or deny each flag, but some flags will be ignored as described in Table 9-1.

The permissions for file2 are displayed as follows:

Everyone                      Allow: Read
video (cxfs1\video)           Allow: Read, Write
Fred Costello (cxfs1\fred)    Allow: Read, Write

The permissions for dir1 are displayed as follows:

Fred Costello (cxfs1\fred)    Allow:
Video (cxfs1\video)           Allow:

---

Note: In this example, the permission flags for directories do not match any of the standard permission sets, therefore no Allow flags are set.

---

In general, you must click the Advanced button to see the actual permissions of directories. For example:

Allow   Fred Costello   Special                 This folder only
Allow   video           Read & Execute          This folder only

The dir1 directory does not have a default ACL, so none of these permissions are inherited, as indicated by the This folder only tag, when a new subdirectory or file is created.

If the file or directory has an ACL, the list may include other users and groups, and the CXFS ACL Mask group that represents the Linux ACL mask. See the chacl(1) man page for an explanation of Linux ACLs and the mask bits. The effective permissions of all entries except for the owner will be the intersection of the listed permissions for that user or group and the mask permissions. Therefore, changing the CXFS ACL Mask permissions will set the maximum permissions that other listed users and groups may have. Their access may be further constrained in the specific entries for those users and groups.

By default, files and directories do not have an ACL, only mode bits, but an ACL will be created if changes to the permissions require an ACL to be defined. For example, granting or denying permissions to another user or group will force an ACL to be created. Once an ACL has been created for a file, the file will continue to have an ACL even if the permissions are reduced back to only the owner or group of the file. The chacl(1) command under Linux can be used to remove an ACL from a file.

For example, fred grants diane read access to file1 by adding user diane using the file properties dialogs, and then deselecting Read & Execute so that only Read is selected. The access list now appears as follows:

audio (cxfs1\audio)           Allow: Read
Diane Green (cxfs1\diane)     Allow: Read
Fred Costello (cxfs1\fred)    Allow: Read, Write

After clicking OK, the properties for file1 will also include the CXFS ACL Mask displayed as follows:

audio (cxfs1\audio)           Allow: Read
CXFS ACL Mask (cxfs1\CXFS...) Allow: Read
Diane Green (cxfs1\diane)     Allow: Read
Fred Costello (cxfs1\fred)    Allow: Read, Write

---

Note: You should select and deselect entries in the Allow column only, because UNIX ACLs do not have the concept of Deny. Using the Deny column will result in an ACL that allows everything that is not denied, even if it is not specifically selected in the Allow column, which is usually not what the user intended.

---

The effective access of user diane and group audio is read-only. Granting write access to user diane as in the following example does not give diane write access because the mask remains read-only. However, because user fred is the owner of the file, the mask does not apply to his access to file1.

For example:

audio (cxfs1\audio)                   Allow: Read
CXFS ACL Mask (cxfs1\CXFS...)         Allow: Read
Diane Green (cxfs1\diane)             Allow: Read, Write
Fred Costello (cxfs1\fred)            Allow: Read, Write

If the users and groups listed in a file's permissions (whether mode bits and/or ACL entries) cannot be mapped to users and groups on the Windows node, attempts to display the file permissions in a file properties window will fail with an unknown user or group error. This prevents the display of an incomplete view, which could be misleading.

Both the owner of the file and the user Administrator may change the permissions of a file or directory using Windows Explorer. All other users will get a permission denied error message.

---

Note: A user must use a node that is not running Windows to change the ownership of a file because a Windows user takes ownership of a file with Windows Explorer, rather than the owner giving ownership to another user (which is supported by the UNIX access controls).

---

When a new file or directory is created, normally the mode bits are set using a mask of 022. Therefore, a new file has a mode of 644 and a new directory of 755, which means that only the user has write access to the file or directory.

You can change this mask during CXFS installation or later by modifying the installation. For more information, see “Client Software Installation for Windows” and “Inheritance and Default ACLs for Windows”.

The four umask options available during installation or modification correspond to the following umask values:

Therefore, creating a file on a UNIX CXFS client results in a mode of 644 for a mask of 022:

admin% ls -lda .
drwxr-xr-x    3 fred     video           41 Nov 21 18:01 ./

admin% umask
0022

admin% touch file3
admin% ls -l file3
-rw-r--r--    1 fred     video            0 Nov 21 18:23 file3

For more information, see the umask man page.

Creating a file in Windows Explorer on a Windows node will have the same result.

A Linux directory ACL may include a default ACL that is inherited by new files and directories, instead of applying the umask. Default ACLs are displayed in the Windows Explorer file permission window if they have been set on a directory. Unlike a Windows inheritable ACL on an NTFS filesystem, a Linux default ACL applies to both new files and subdirectories, there is no support for an inheritable ACL for new files and another ACL for new subdirectories.

The following example applies an ACL and a default ACL to dir1 and then creates a file and a directory in dir1 :

admin% chacl -b "u::rwx,g::r-x,u:diane:r-x,o::---,m::r-x" \
           "u::rwx,g::r-x,u:diane:rwx,o::---,m::rwx" dir1
admin% touch dir1/newfile
admin% mkdir dir1/newdir
admin% ls -D dir1
newdir [u::rwx,g::r-x,u:diane:rwx,o::---,m::r-x/
        u::rwx,g::r-x,u:diane:rwx,o::---,m::rwx]
newfile [u::rw-,g::r-x,u:diane:rwx,o::---,m::r--]

The permissions for dir1 will be as follows:

CXFS ACL Mask (cxfs1\CXFS...)  Allow:                     
Diane Green (cxfs1\diane)      Allow:                
Fred Costello (cxfs1\fred)     Allow: Read & Exec, List, Read, Write
Video (cxfs1\video)            Allow: Read & Exec, List, Read

After clicking on Advanced, the permissions displayed are as follows:,

Allow  Fred Costello   Special                 This folder, subfolders and files
Allow  video           Read & Execute          This folder, subfolders and files
Allow  Diane Green     Read, Write & Exec      Subfolders and files
Allow  CXFS ACL Mask   Read, Write & Exec      Subfolders and files
Allow  Diane Green     Read & Exec             This folder only
Allow  CXFS ACL Mask   Read & Exec             This folder only

If an ACL entry is the same in the default ACL, a single entry is generated for the This folder, subfolders and files entry. Any entries that are different will have both Subfolders and files and This folder only entries.

Adding the first inheritable entry to a directory will cause CXFS to generate any missing ACL entries like the owner, group, and other users. The mode bits for these entries will be generated from the umask.

Adding different Subfolders Only and Files Only entries will result in only the first entry being used because a Linux ACL cannot differentiate between the two.

In order to configure system tuning settings, you must to modify the registry. Do the following:

---

Caution: Only the parameters documented here may be changed to modify the behavior of CXFS. All other registry entries for CXFS must not be modified or else the software may no longer function.

---

The default umask that is set up during installation can be configured to a value not supported by the installer. For more information on the umask, see “Inheritance and Default ACLs for Windows”.

In the Registry Editor (regedit), navigate and edit the following value:

This value specifies the umask in hexadecimal (and decimal), not its normal octal representation used on UNIX platforms.

CXFS for Windows prior to CXFS 3.2 broke down large direct I/O requests into requests no larger than 4 MB, which would result in additional network traffic to the metadata server and potentially multiple extents on disk when it could allocate a single extent. This limit has been increased to 16 MB and can be configured by modifying a new registry key in CXFS 3.2 and later.

In regedit, navigate and edit the following value:

Create a new DWORD key called MaxDMASize and specify the maximum I/O request size in bytes. If this parameter is not defined, it defaults to 0x1000000, which is 16 MB. The upper bound for Windows is just under 64 MB.

By default, a CXFS Windows client enforces memory-mapping coherency by preventing other clients and the CXFS metadata server access to the file while it is mapped. This can cause problems for some applications that do not expect this behavior.

Microsoft Office applications and Notepad.exe use memory-mapped I/O to read and write files, but use byte-range locks to prevent two people from accessing the same file at the same time. The CXFS behavior causes the second Office application to hang until the file is closed by the first application, without displaying a dialog that the file is in use.

Backup applications that search the filesystem for modified files will stall when they attempt to back up a file that has been memory-mapped on a CXFS Windows node.

In regedit, navigate and edit the following value:

You can disable this behavior in CXFS by changing the DisableMemMapCoherency parameter from 0 to 1 to avoid these problems. However, CXFS can no longer ensure data coherency if two applications memory-map the same file at the same time on different nodes in the cluster.

---

Caution: Use this option with extreme caution with multiple clients concurrently accessing the same files.

---

The Directory Name Lookup Cache (DNLC) in a CXFS Windows client allows repetitive lookups to be performed without going to the metadata server for each component in a file path. This can provide a significant performance boost for applications that perform several opens in a deep directory structure.

In regedit, navigate and edit the following value:

The DnlcSize parameter is set to 4096 by default. You can change it to a value from 0 (which disables the DNLC) to 100000. Values outside this range will be reset to 4096.

---

Note: Increasing the DNLC size can have a significant memory impact on the Windows node and the metadata server because they maintain data structures for every actively opened file on the CXFS clients. You should monitor the memory usage on these nodes before and after changing this parameter because placing nodes under memory pressure is counter-productive to increasing the DNLC size.

---

By default, byte-range locks across the cluster are advisory locks, which do not prevent a rogue application from reading and writing to locked regions of a file.

---

Note: Windows filesystems (NTFS and FAT) implement a mandatory locking system that prevents applications from reading and writing to locked regions of a file. Mandatory locks are enabled within a Windows client.

---

In regedit, navigate and edit the following value:

To enable mandatory byte-range locks across the cluster, set the ForceMandatoryLocks parameter to 1. Setting this parameter will adversely affect performance of applications using these locks.

User identification maps are updated automatically by the following triggers:

The most common trigger in a typical environment is when an unmapped user logs into the system; the other two triggers are generally static in nature.

Updating the map can be a resource-intensive operation in a domain environment. Therefore, by default, an update is triggered only when an unmapped user logs in and not more often than every 5 minutes.

To configure the minimum update interval, select the following:

In the regedit menu:

Enter MinMapGenTime for the name. Press Enter to edit the value, which is the minimum time between updates in minutes. The minimum time is 1 minute.

The maximum size of I/O issued by the QLogic HBA defaults to only 256 KB. Many applications are capable of generating much larger requests, so you may want to increase this I/O size to the HBA's maximum of 1 MB.

To increase the size of the I/O, do the following:

Command Tag Queueing (CTQ) is used by HBAs to manage the number of outstanding requests each adapter port has to each target. Adjusting this value (up or down) can improve the performance of applications, depending on the number of clients in the cluster and the number of I/O requests they require to meet the required quality of service.

You should only modify this setting for HBA ports that are to be used by CXFS. Do not modify ports used for local storage.

While it is possible to change this value with the volume mounted, I/O will halt momentarily and there may be problems if the node is under a heavy load.

---

Note: The Windows QLogic HBA will not recognize the CTQ setting placed on the disk by Linux nodes.

---

To configure the CTQ for the QLogic HBA, do the following:

If you do not have SANsurfer Manager installed, you can also set the execution throttle in the QLogic BIOS during boot-up. To do this, press ctrl-q when you see the QLogic BIOS message. See the QLogic HBA card and driver documentation.

---

Note: Unlike CTQ, you cannot have separate depths per LUN. Execution throttle limits the number of simultaneous requests for all targets in the specified port.

---

The MmapFlushTimeSeconds tunable allows the CXFS memory manager to periodically relinquish references to files that are currently memory-mapped but are not in use. This enables other clients in the cluster to access the files.

The MmapFlushTimeSeconds registry value specifies the length of time in seconds that a CXFS flushing thread periodically awakens to flush the memory-mapped files that are not in use. The larger the value the longer the client will hold onto the tokens for that file. The default is 30 seconds. Setting the value to 0 disables the flushing of memory-mapped files. (A negative value is invalid and will cause the setting to return to the default 30 seconds.)

---

Caution: Change the value for this parameter with caution. Increasing the MmapFlushTimeSeconds time can cause other clients to increase their access wait time if memory-mapping coherency is enabled. Decreasing the value might cause unnecessary flushing and invalidation operations, which will hurt the system performance.

---

In regedit, navigate and edit the following value:

The following procedure provides an overview of the steps required to add a private network to the Windows node. You may skip some steps, depending upon the starting conditions at your site.

Do the following:

The location of the host information is:

%SystemRoot%\system32\drivers\etc\hosts

It is very important, especially in the presence of private network failover, to ensure that the hostnames and IP addresses for the various network interfaces are properly configured on both the Windows node and the CXFS metadata servers. (For more information about configuring private network failover, see the CXFS Administration Guide for SGI InfiniteStorage.)

For example, problems may occur if the cluster is configured using hostnames and the primary network interface on the Windows node is used for the CXFS private network. In this situation, the Windows node may associate the computer name to the primary network interface rather than the private network name configured in DNS.

To avoid such problems, SGI recommends that you specify the private network addresses for the Windows node using IP addresses rather than hostnames.