6.1 Managing Volume-Specific Mount Parameters

You can manage the NFS Gateway mount parameters by using either iManager or the command line.

6.1.1 Using iManager

The NFS Gateway Mount Parameters page of iManager lets you set the mount parameters for a new volume and also view and change mount parameters.

For details, see Section 7.4, Viewing and Modifying Mount Parameters.

6.1.2 Using Command Line

Use the following syntax to mount a volume:

gymount volumename IPAddress | hostname sharedPath [-shadowVolume value] [-nfsVersion value] [-mountUid value] [-mountGid value] [-anonUid value] [-anonGid value] [-rpcTimeOut value][-rpcRetries value] [-dynamicRPCTimeout | -noDynamicRPCTimeout] [-dirCompFreq value] [-umask value] [-readOnly | -readWrite] [- tossMetadata | -noTossMetadata] [-lowerCaseUnixNames|-noLowerCaseUnixNames] [-forceAnonUidGid|-noForceAnonUidGid] [-readSize value] [-writeSize value] [-maxOutstandingPackets value][dynamicMOP | -noDynamicMOP] [-showDotFiles | -hideDotFiles] [-logLevel value] [-logVerbose | -logNonVerbose] [-entryInNCF|-noEntryInNCF]

IMPORTANT:Load nfsgy with the required parameters before executing the gymount command. Otherwise, gymount auto loads nfsgy with default parameters.

Dynamic Configuration of Parameters on Mounted Volumes

Dynamic configuration means that the changes made in mount parameters are taken into effect automatically and there is no need to dismount a volume and mount it again for the changed parameters to take effect.

The NFS Gateway supports dynamic configuration for certain parameters of mounted volumes.

The following table describes the mount parameters, gives their default values, and specifies if dynamic configuration of that parameter is supported on mounted volumes.

Parameter

Default

Description

Dynamic Configuration Support

volumename

Mandatory

(No default)

Name of the volume that you are mounting.

Range: 2 to 15 characters.

This parameter is mandatory.

No

IPAddress | hostname

Mandatory for the first time

IP Address or hostname of the NFS Server you are importing the shared directory from.

This parameter is mandatory unless the volume was previously mounted with the required syntax and nfsgy.nlm has not been unloaded after that.

No

sharedPath

Mandatory for the first time

Absolute path of the shared directory in the NFS Server.

This parameter is mandatory if you are mounting the volume for the first time after the NFS Gateway is loaded.

No

shadowVolume

Value of shadowVolume option specified in the nfsgy command

Specifies the name of the volume where shadow files are to be stored.

The shadow files are stored in shadowVolume:\gateway directory.

The gateway volume will not be mounted if the specified shadowVolume is not available.

If not specified here, then if the shadowVolume was specified with the nfsgy command, that value is used.

Do not use the mounted Gateway volumes as ShadowVolume when mounting another volume using gymount. For example, if vol1 is a mounted NFS Gateway volume, then do not execute the following:

gymount vol2 -shadowVolume vol1

When shadowVolume is not using the default of sys: and if the trustee information is lost when using a gateway volume in a cluster enabled environment, or using a newly mounted NSS volume as shadowVolume, then in the Section 11.0, Troubleshooting the NFS Gateway for NetWare 6.5 chapter, refer to the troubleshooting scenario.

IMPORTANT:Do not dismount or deactivate the shadow volume specified at any time before the associated Gateway volumes are dismounted. Doing so results in deactivation of volumes imported by NFS Gateway.

No

nfsVersion

3

NFS protocol version that the volume is imported with.

Valid value = 2 or 3

We recommend using NFS version 3 because NFS Gateway for NetWare® 6.5 is optimized for this.

If NFS version 3 is not supported by the NFS Server, then the volume is mounted with NFS version 2.

If you use NFS version 2, then you must tune the gymount parameters based on Section 8.3, Tuning for NFS Version 2.

No

mountUid

0

UID used for mounting the shared path.

Valid Range: 0 to 2147483647

The NFS Gateway also uses this parameter for UID, when NLM™ programs running on the server (for example, EDIT.NLM) access the NFS Gateway volume with NCP™ Connection Number = 0.

Yes

mountGid

1

GID used for mounting the shared path.

Valid Range: 0 to 2147483647

The NFS Gateway also uses this parameter for GID, when NLM programs running on the server (for example, EDIT.NLM) access the NFS Gateway volume with NCP Connection Number = 0.

Yes

anonUid

55555

UID used for users without a UNIX profile in eDirectory™.

Valid Range: 0 to 2147483647

The NFS Gateway also uses this parameter for a user with UID = 0 in the UNIX profile when root access is not given to the NetWare server.

Yes

anonGid

55555

GID used for users without UNIX profile in eDirectory.

Valid Range: 0 to 2147483647

Yes

rpcTimeOut

1

Time interval (in seconds) that the gateway waits for a response from the remote server.

Valid Range: 1 to 2147483647

If the network is heavily loaded or the remote NFS Server is slow in responding to NFS requests, set a high value for this parameter. You might use a value of 6, which is used by some of the other NFS clients.

If the network is moderately loaded or the remote NFS server is fast enough to respond to NFS queries from the NFS Gateway, the default value of 1 is sufficient.

We recommend you try different values to to find which ones work best for your network settings.

If dynamicRPCTimeout is enabled, then the timeout value used for RPC calls varies based on network behavior, with the value given by the user taken as the minimum value.

Yes

rpcRetries

3

Number of times each RPC request is retried, if the reply for a request does not come within the rpcTimeOut period.

Valid Range: 1 to 2147483647

With every RPC retry, the value of the rpcTimeOut for that packet doubles. For example, if the rpcTimeOut is set as 1, then in the second attempt of RPC request, the value of rpcTimeOut doubles to 2.

Yes

dynamicRPCTimeout | noDynamicRPCTimeout

dynamicRPCTimeout

Specifies whether to dynamically set RPC timeouts based on network behavior.

Yes

dirCompFreq

0

Time (in seconds) after which all the cached shadow file contents for this directory are invalidated.

Valid Range: 0 to 2147483647

The default value of 0 indicates that cache is not invalidated until there is a change in the directory content in the NFS server.

Yes

umask

022

File mode creation mask for files and directories created from NFS Gateway.

Valid Range: 000 to 777

This value must be octal.

Yes

readOnly | readWrite

readWrite

Specifies if the Gateway volume is read-only or read/write.

readOnly Usage: If a Gateway volume is mounted with the readOnly parameter, then the volume acts like a NSS ReadOnly volume, similar to a CD-ROM.Modifications, even in the admin mode, are not allowed either to the contents of the file, or to the file meta-data such as trustee rights, NetWare attributes. Using this parameter is not a common practice; it is more useful to use trustee rights management to control access.

If the remote Unix server has exported the path as ro (read only), then by default, NFS Gateway mounts the volume as readWrite.

All the file operations are restriced to read only by the remote Unix server, but the file’s NetWare metadata operations are allowed. Therefore, to avoid unnecessary network traffic, if you have a remote path exported as ro (readOnly) and you do not want to mount the gateway volume as a NetWare ReadOnly volume, then you might want to limit the rights on the volume to RF (Read and FileScan).

No

tossMetaData | noTossMetaData

noTossMetadata (retain)

Invalidates or retains file metadata immediately after the file is closed.

Yes

lowerCaseUnixNames | noLowerCaseUnixNames

noLowerCaseUnixNames (not enforced)

Specifies if the file or directory created from NetWare must have lowercase filenames on UNIX.

When you specify noLowerCaseUnixNames, the filenames created from NetWare side will have the case specified by client even on UNIX side.

Yes

forceAnonUidGid | noForceAnonUidGid

noForceAnonUidGid (not enforced)

Specifies if all NFS requests will be forced to go with anonUid and anonGid.

Even when you specify noForceAnonUidGid, if the user does not have UNIX profile, NFS requests will continue to go with anonUID and anonGid.

Yes

readSize

32

Specifies the read transfer buffer size in KB.

Valid values = 4, 8, 16, 32

If you enter a value other than 4, 8, 16, or 32 but within the range of 4 to 32, then the lower valid value nearest to the value you enter is used.

For example, if you enter 10, then 8 is used.

If you enter an invalid value outside the range of 4 to 32, the default value is used.

This parameter is applicable only for NFS version 3. If the NFS version is 2, then the value 4 is used.

The NFS Gateway checks the following three values and uses the lowest to determine the actual read size to use:

  • Largest UDP Packet Size (parameter in monitor.nlm > Server Parameters > Communications)
  • The preferred read size as specified by the remote NFS Server
  • The readSize specified by the gymount command

To ensure that read transfer buffer size is 32 KB of data, check for the following:

  • The NFS Server has a read preferred size = 32 KB
  • The NFS Gateway gymount parameter readSize = 32 KB
  • The largest UDP packet size on NetWare = 33280 (32768 for data +512 for headers) or greater

The read size value used for RPC calls depends on the maximum UDP packet size defined by the system and the preferred read size of the NFS server. Therefore, the read size in use might differ from the value given by the user.

Verify the parameter value in use, by using the command line utility or the iManager interface.

Yes

writeSize

32

Specifies the write transfer buffer size in KB.

Valid values = 4, 8, 16, 32

If you enter a value other than 4, 8, 16, or 32 but within the range of 4 to 32, then the lower valid value nearest to the value you enter is used.

For example, if you enter 10, then 8 is used.

If you enter any invalid value outside the range of 4 to 32, the default value of 32 is used.

This parameter is applicable only for NFS version 3. If NFS version 2 is specified, then the value 4 is used.

The NFS Gateway checks the following three values and uses the lowest to determine the actual write size to use:

  • Largest UDP Packet Size (parameter in monitor.nlm > Server Parameters > Communications)
  • The preferred write size as specified by the remote NFS Server
  • The writeSize specified by the gymount command.

To ensure that write transfer buffer size is 32 KB of data, check for the following:

  • The NFS Server has a write preferred size = 32 KB
  • The NFS Gateway gymount parameter writeSize = 32 KB
  • The largest UDP packet size on NetWare = 33280 (32768 for data +512 for headers) or greater

The write size value used for RPC calls depends on the maximum UDP packet size defined by the system and the preferred write size of the NFS server. Therefore, the write size in use might differ from the value given by the user.

Verify the parameter value in use, by using the command line utility or the iManager interface.

Yes

maxOutstandingPackets

8

Specifies the maximum number of requests to an individual NFS server that can be concurrently outstanding before the NFS Gateway pauses in sending requests to that particular NFS server. An outstanding packet is an NFS request to which no reply has been received, nor has its timeout period expired.

For example, if the maxOutstandingPackets = 64, then a maximum of 64 requests can be waiting for a response from an individual NFS server.This is irrespective of the number of Gateway volumes imported from that NFS server. If two or more NFS Gateway volumes are imported from the same NFS server, then the value specified in the first gymount command is used. That value is treated as a pool and shared between the two or more gateway volumes.

If two NFS Gateway volumes refer to the same NFS server, then the value specified in the volume mounted first is used between the first and second volume together.

Valid Range: 1 to 2147483647

Consider the following when selecting a value for this parameter:

  • If the number of NFS Server threads is high, then increase the value for this parameter.
  • If the NFS Server is low end (low configuration or less number of NFS Server threads), then decrease the value for this parameter. If it is high end, then increase the value for this parameter.
  • If the network performance is good, then select values 16 or 32; however, the value must not exceed the number of NFS Server threads. If the network performance is not good, then select the value 2 or 4.

If dynamicMOP parameter is set, then the value of maxOutstandingPackets for RPC calls varies according to network behavior, with the value given by the user taken as the maximum value.

IMPORTANT:Use the value 1 for this parameter with caution because it might negatively impact the performance of the NFS Gateway. The value 1 means each NFS request must be answered by the remote NFS server before the NFS Gateway sends another request.

Yes

dynamicMOP | noDynamicMOP

noDynamicMOP

Specifies whether to dynamically set the MOP (Maximum Outstanding Packets) based on network behavior.

If you are unsure about the network behavior and about the ability of the server to handle many parallel requests and you prefer NFS Gateway to automatically take care of tuning the maxOutstandingPackets value, then enable this parameter.

IMPORTANT:Enabling dynamicMOP might significantly reduce the performance

Yes

showDotFiles | hideDotFiles

showDotFiles

Specifies whether to show or hide the hidden files/directories (beginning with dot(.)) of remote machine.

If hideDotFiles is set, then you cannot access hidden files/directories.

Do not attempt to dynamically update this parameter even by dismounting and mounting the volume again.

When changing to using -hideDotFiles (or when changing back from -hideDotFiles to -showDotFiles), NFS Gateway does not automatically recalculate what should be hidden vs not hidden. All files whose information already exists in the shadow files remains hidden or not hidden, as they already were. New files will be effected by the new setting. This is because NFS Gateway cannot accurately determine whether user intervention has altered which files are expected to be hidden or not.

If you want that an NFS Gateway volume start with a "clean slate" and totally re-evaluate which files should be hidden, then it is necessary to delete that volume’s shadow files. Doing this wipes out the NetWare file system trustee rights assigned to that volume. Re-establish those by doing the following:

Execute GYSTOP.NCFDelete sys:\gateway\<volume_name>\*.*Edit GYSTART.NCF and include -hideDotFiles on the appropriate GYMOUNT line.Execute GYSTART.NCFRe-assign any NetWare trustee assignments needed on that Gateway volume.

No

logLevel

value of logLevel optionh specified with nfsgy command

Specifies the logging level to be enabled for the volume.

0, 1, 2, 4 and 8 are the valid log levels. The values indicate the following:

0 = None (Logging is disabled)

1 = Errors

2 = Warning , Errors

4 = Info, Warning, and Errors

8 = Debug, Info, Warning, and Errors

The logLevel = 8 is not recommended in typical cases. Use this only for debugging purposes.

If not specified here, then if the logLevel was specified with the nfsgy command, that value is used.

Yes

logVerbose | logNonVerbose

logNonVerbose

Specifies whether to log verbose information or not.

If not specified, the value specified with the nfsgy command is used.

Yes

entryInNCF | noEntryInNCF

noEntryInNCF

Specifies whether to add gymount entry in the gystart.ncf file or not.

NOTE:noEntryInNCF is ignored when specified as a parameter of a gymount entry when editing gystart.ncf.

Yes