Manual Chapter :
Troubleshooting Managed Volumes
Applies To:
Show Versions
ARX
- 6.3.0
The ARX records read/write statistics, including latency measures, for each of its filer shares. It keeps these statistics from the moment each share is enabled as part of an ARX volume. (For instructions on configuring and enabling a volume share, refer to the ARX® CLI Storage-Management Guide: Adding a Share, on page 8-8 for direct volumes, or Adding a Share, on page 9-33 for managed volumes.) The statistics are kept at the NSM, which runs the ARXs fastpath processes. Use the show statistics namespace fastpath command to see these statistics:
bstnA> show statistics namespace fastpath
To focus on the share statistics from one namespace, use the namespace argument in the show statistics namespace command, followed by the fastpath keyword:
show statistics namespace name fastpath
name (1-30 characters) identifies the desired namespace, and
fastpath is a required keyword.
bstnA> show statistics namespace wwmed fastpath
You can narrow the focus further to a particular volume. After the namespace name, add the volume path to the show statistics namespace command:
name (1-30 characters) identifies the desired namespace,
volume (1-1024 characters) identifies the volume, and
fastpath is a required keyword.
bstnA> show statistics namespace wwmed /acct fastpath
You can narrow the focus down to a single share in the volume. After the volume path, add the share name to the show statistics namespace command:
name (1-30 characters) identifies the desired namespace,
volume (1-1024 characters) identifies the volume,
share-name (1-64 characters) identifies the specific share, and
fastpath is a required keyword.
bstnA> show statistics namespace wwmed /acct budget fastpath
A managed volume stores metadata about the files that it contains at the back-end. In order for the managed volume to perform effectively, the latency between the managed volume software running on the ARX and the filer share on which the metadata resides must be low. The show statistics metadata command enables you to display a number of metadata read and write statistics for each managed volume associated with the ARX.
where name specifies a namespace for which to display metadata statistics, and volumepath species a volume for which to display metadata statistics.
bstnA# show statistics metadata
Execute the command clear statistics metadata to clear and reset metadata counters for the entire system, or for a specified namespace or volume.
You can move all files from one share (or share farm) to one or more other shares in the same volume, thereby draining the source share(s). A placement rule accomplishes this, and prevents any new files from being created on the source share(s). A placement rule is typically used for moving files to their storage tiers, as described in Placing Files on Particular Shares, on page 14-4 of the ARX® CLI Storage-Management Guide. This is a special use case for a placement rule.
Use place-rule to create a new placement rule, as described in the storage manual. This puts you into gbl-ns-vol-plc mode, where you must choose a source share or share farm, set the storage target for the files, and enable the rule. There are also some optional commands you can invoke from this mode. This section explains the options that are relevant to draining a share.
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
The next step in draining a share or shares is to identify them. The placement rule places all files from the source share(s) onto the target storage. From gbl-ns-vol-plc mode, use the source command to specify the source share(s).
From gbl-ns-vol-plc mode, use one of two source commands to specify the source share(s):
source share share-name
source share-farm share-farm-name
where share-farm-name (1-64 characters) is a group of shares in a share farm.
Use the show global-config namespace command to see the shares or share farms in each volume: see Showing Namespace Configuration, on page 7-24 of the ARX® CLI Storage-Management Guide.
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
bstnA(gbl-ns-vol-plc[wwmed~/acct~emptyRH])# source share it5
The next step in draining shares is to choose the target storage for the shares files. You can choose one target: another share or share farm in the current volume. From gbl-ns-vol-plc mode, use the target rule to set the shares storage target.
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
bstnA(gbl-ns-vol-plc[wwmed~/acct~emptyRH])# target share-farm fm1
bstnA(gbl-ns-vol[archives~/etc])# place-rule move2nas
bstnA(gbl-ns-vol-plc[archives~/etc~move2nas])# target share nas3
To migrate files off of any share that is running low on free space, you can configure auto migration for the share farm. Refer to Auto Migrating Existing Files, on page 15-15 of the ARX® CLI Storage-Management Guide.
to close any files held open by CIFS clients, thereby making it possible to migrate them. For details, refer to Automatically Closing All Open Files (CIFS), on page 14-14 of the ARX® CLI Storage-Management Guide.
to control the bandwidth used for migrations. For details, refer to Limiting Each Migration (optional), on page 14-17 of the same storage guide.
to create a progress report for the drain operation. This is recommended. For details, refer to Configuring Progress Reports, on page 14-21 of the storage guide.
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
bstnA(gbl-ns-vol-plc[wwmed~/acct~emptyRH])# limit-migrate 10G
bstnA(gbl-ns-vol-plc[wwmed~/acct~emptyRH])# report emptyRH_ verbose
Before you enable the rule and start draining the share, you have the option to retain copies of those files. From gbl-ns-vol-shr mode, use the migrate retain-files command to put this safeguard in place:
bstnA(gbl-ns-vol-shr[wwmed~/acct~it5])# migrate retain-files
To disable the feature that retains copies of migrated files, use the no form of the command:
bstnA(gbl-ns-vol-shr[wwmed~/acct~it5])# no migrate retain-files
A tentative rule is configured to appear in the system logs (syslog) as tentative, showing the potential effects of the rule if it was enabled. (The log component, POLICY_ACTION, creates the syslog messages; syslog access and log components are described in Accessing the Syslog.) If you configured reporting for the rule (as shown above), the report shows which files would be migrated if the rule was fully enabled. Tentative rules do not change policy enforcement, but they do consume processing time in the policy software. From gbl-ns-vol-plc mode, use the tentative command to put the placement rule in a tentative state:
To see the simulated rule run, you must enable the rule (as described below). Then use show logs syslog or grep pattern logs syslog to view the syslog.
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
Use the no tentative command to fully activate the drain rule. You can then disable and re-enable the rule (as described below) to start the draining process. For example, the following command sequence activates the emptyRH rule. When the rule is enabled, it performs actual migrations:
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
bstnA(gbl-ns-vol-plc[wwmed~/acct~emptyRH])# no tentative
The final step in draining a share is to enable its placement rule. By default, the rule is disabled and ignored by policy software. Use the enable command to enable the rule. For example, the following command sequence enables the emptyRH rule:
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
Disabling the rule removes it from consideration. Use no enable from gbl-ns-vol-plc mode to disable a placement rule. For example, the following command sequence disables the emptyRH rule:
bstnA(gbl-ns-vol[wwmed~/acct])# place-rule emptyRH
You can use a metadata-only report to verify that the share is empty. Use the nsck ... metadata-only command to generate a report about the share (as described in Focusing on One Share), and then use show reports to view the report. For example, the following command sequence generates a report on the it5 share, proving that it has no files:
bstnA(gbl)# nsck wwmed report metadata-only share it5
bstnA(gbl)# show reports metadata_only.10.rpt
You can remove a rule to both disable it and delete its configuration. From gbl-ns-vol mode, use the no form of the place-rule command to remove a placement/drain rule. For example, the following command sequence removes the drain rule, drainSrvW08, from the medarcv~/rcrds volume:
bstnA(gbl-ns-vol[medarcv~/rcrds])# no place-rule drainSrvW08
You can remove a share from its managed volume without affecting service to the volumes clients. The remove-share migrate command migrates all of the shares files and master directories to another share or share farm in the same volume. (A master directory is the first-imported (or only) instance of a directory in the managed volume.)
Important: This is not recommended in a volume that supports snapshots. In those volumes, you should drain the share first, wait until allretained snapshots have aged out, and then run this command. For instructions on draining all files from a share, recall Draining One or More Shares, above.
Before you remove the share, you must first verify that it is not referenced by any policies or rules; look for the share name in the volumes rules (use the show policy namespace ... volume command, as shown in Focusing on One Volume, on page 14-40 of the ARX® CLI Storage-Management Guide). Also, the share must be online in the namespace: use show namespace status to confirm this (see Monitoring the Import, on page 9-56 of the same manual).
To retain copies of all migrated files, you have the option to use migrate retain-files in the share before you remove it (recall Retaining Copies of Files on the Share (optional)).
From priv-exec mode, use remove-share migrate to remove the share:
namespace (1-30 characters),
volume (1-1024 characters), and
share (1-64 characters) all identify the share to remove, and
destination (1-64 characters) is the destination share or share farm. This command migrates all of the shares files and master directories to the destination. This must be a share or share farm in the same volume.
close-file (optional) causes the operation to close all files open by CIFS clients in order to migrate them. If you omit this option, files opened by CIFS clients cannot migrate off of the selected share. This would leave files stranded on the share and cause the share removal to fail.
exclude fileset (optional if you choose close-file, 1-64 characters) is a fileset to exclude from automatic closure. If a file in this fileset is open through CIFS, the rule places it on a retry queue instead of automatically closing it. If such a file remains open for the duration of the share removal, it never migrates off of the share and the share-removal fails.
async (optional if you specify a destination) makes this command return immediately, rather than waiting for the share removal to finish.
The CLI prompts you with a warning before removing the share; enter yes to proceed. The CLI blocks as the volume migrates the files and directories off of the share, then prints a message indicating the success of the share removal.
bstnA(gbl)# end
bstnA# remove-share migrate wwmed /acct it5 fm1
bstnA# ...
If the share is in a multi-protocol (NFS and CIFS) volume, the volume may require additional processing for the migration. The extra processing guards against a file or directory on the source share colliding with a filer-generated name (FGN) at the destination. The volume does not record filer-side FGNs in its metadata; it deduces when collisions are possible and then uses probes to check for them.
Any file or directory with a back-end FGN is labeled NFS-only; CIFS clients cannot access it through the volume, and the ARX software cannot reliably find its CIFS-side FGN. The CIFS attributes for NFS-only files and directories are therefore inaccessible to the ARX. This is especially important for directories. If the volume cannot find a directorys CIFS attributes, it cannot make a precise duplicate of the directory. The migrations for NFS-only directories therefore fail.
bstnA(gbl)# namespace insur
bstnA(gbl-ns[insur])# volume /claims
bstnA(gbl-ns-vol[insur~/claims])# share shr1-next
bstnA(gbl-ns-vol-shr[insur~/claims~shr1-next])# no strict-attribute-consistency
Strict-attribute consistency is recommended for most situations. Typically, you restore this consistency check after the migration is finished. From gbl-ns-vol-shr mode, use strict-attribute-consistency to enable the consistency checks:
bstnA(gbl)# namespace insur
bstnA(gbl-ns[insur])# volume /claims
bstnA(gbl-ns-vol[insur~/claims])# share shr1-next
bstnA(gbl-ns-vol-shr[insur~/claims~shr1-next])# strict-attribute-consistency
These describe two of the phases in removing a share. The first phase uses a placement rule to drain all files and directories from the share (see Draining One or More Shares). The second phase removes the share from the namespace.
Use show reports type Plc to list all file-placement (and drain-share) reports. To list all of the remove-share reports, use show reports type Rm. For example, this shows the two reports (highlighted in bold text) from removing the it5 share:
bstnA# show reports type Plc
bstnA# show reports type Rm
bstnA# ...
The drain-share report shows the number of files migrated off of the share. Use the show reports command to show it. For example, this shows the numbers of files migrated from the it5 share:
bstnA# show reports drain_share_rule_for_share_it5_201002240213.rpt
bstnA# ...
bstnA# show reports remove.23.it5.8.rpt
bstnA# ...
By default, the CLI waits for the share removal to finish before allowing you to enter any more commands. Add the async flag at the end of the command to return to the CLI immediately after confirming the removal:
bstnA(gbl)# end
bstnA# remove-share migrate wwmed /acct it5 fm1 async
bstnA# ...
You can also remove a share without migrating its files. This may have an impact on clients; any of the shares files that are visible to them will appear to vanish. This is typically reserved for share-import failures (described later in the chapter), or situations where a major change has been announced to the client base. As with the remove-share migrate command, this command migrates the shares master directories.
From priv-exec mode, use the remove-share nomigrate command to remove a share from a namespace without migrating any of its files:
where all of the options are described above. The destination is required for the shares master directories, which must migrate before the share is removed. In multi-protocol volumes, master directories with NFS-only names cannot migrate to the destination share; resolve this as discussed above, in Migrating NFS-Only Directories.
The CLI prompts for confirmation; enter yes to continue. The back-end share does not lose any of its files or directories when you use this command. You can access the share directly when the share-removal completes.
bstnA(gbl)# end
bstnA# remove-share nomigrate medarcv /rcrds oldrx rx async
bstnA# ...
A online-share removal requires a scan of the filer. The scan finds the file attributes (such as ownership and access permissions) for all master directories. In cases where the filer or back-end share is offline, this scan fails and the share cannot be removed. To skip the scan and force the removal, use the force option at the end of the remove-share nomigrate command:
Since the volume cannot scan the file attributes for the master directories, it sets all file attributes to 0 (zero) for the relocated master directories. You must manually correct these attributes by accessing the volume through its virtual servers VIP. To identify the directories that need correction, consult the remove report (described above; see Showing the Remove Report). Each directory that requires attribute resets has an [AR] next to it in the report.
The CLI prompts you with a warning before removing the share; enter yes to proceed. The CLI blocks as the volume removes the share, then prints a message indicating the success of the share removal.
bstnA(gbl)# end
bstnA# remove-share nomigrate ns / defunctShr rx async
Before the share removal begins, the volume scans the back-end filer. This scan collects all attributes for all of the shares master directories, to be duplicated at the destination share. It is possible to cancel the share removal during this scan, which takes longer than the other removal phases. From priv-exec mode, use the cancel remove command to cancel a share removal:
ns (1-30 characters) identifies the namespace.
vol-path (1-1024 characters) is the shares volume.
share-name (1-64 characters) is the share.
bstnA(gbl)# end
bstnA# cancel remove namespace wwmed volume /acct share expir
You can remove an offline, unreachable, or otherwise defunct back-end share from a namespace by using the remove-share offline CLI command in privileged-exec mode. Use this command only for a back-end share that is unreachable on a metadata-based managed volume, not on a direct volume. If the share is still reachable, use remove-share migrate or remove-share nomigrate instead.
When executed, the command creates a report, remove.job-id.share-name.share-id.rpt. Use show reports to view its contents.
The remove-share offline command deletes all of the shares files from the volumes metadata; from the clients perspective, these files disappear. Given that the back-end filer was unreachable to begin with, those files were inaccessible to clients already. Before removing the share, resolve all dependencies on the share. Use the show policy command to verify that no policy rules reference the share.
| namespace (1 - 30 characters) is the name of the namespace. |
| volume (1 - 1024 characters) is the name of the volume. |
| share (1 - 64 characters) is the name of the share. |
| dest (1 - 64 characters) is the new destination share or share farm where the original shares master directories (if any) are to be migrated. A master directory is the first-imported instance of a directory in the managed volume. Use show global-config namespace for a list of shares and share farms in the namespace. |
| async (optional) makes this command return immediately, rather than waiting for the share removal to finish. |
After you enable a namespace volume, the volume reads all of its back-end shares and imports all of their files and directories. If anything goes wrong in any share, the failed share shows a Status of Error in the show namespace status output, and one of the errors in Table 10.1 appears in the more-verbose show namespace output. Use show namespace (not show namespace status) to see the full error message.
| One of the shares directories has a name with Unicode characters that are unsupported by the character-encoding nfs setting. CIFS file names are Unicode and can contain any character, but NFS servers and clients must each configure their character encoding for file names. The volume cannot import a directory with any un-mappable characters in its name. You can use the import rename-directories unmapped-unicode command to allow the volume to rename such directories during import, or you can rename them manually at the filer. Then restart the share import: enter gbl-ns-vol-shr mode and re use the enable (gbl-ns-vol-shr) command. | |||||
| A share with a higher import priority has failed its import, so this share cannot import. If any share import fails, the managed volume cannot import any shares with lower import priorities. Find the import error for the failed share(s), look for the error in this table, and take action as directed. This error is resolved as soon as all higher-priority shares successfully import. | |||||
| For NFS exports, check your back-end filer configuration: the back-end share should allow root access to all of the ARXs proxy IP addresses. Use the show exports command examine all permission settings at the filer. Use the show ip proxy-addresses command to list all configured proxy IP addresses. For CIFS shares, the switch uses the namespaces proxy user (username and password). The proxy-user credentials must belong to the Administrators group at every filer behind the namespace. Use the probe exports command to check this. The proxy-user (gbl-ns) command sets the proxy user credentials for a namespace. This may also indicate that the ARX is examining a read-only directory, such as the ~snapshot directory in a NetApp filer. Such directories should be ignored during import. The gbl-filer ignore-name command identifies these types of directories. After you find and fix the error, you can restart the share import: enter gbl-ns-vol-shr mode for this share and re use the enable (gbl-ns-vol-shr) command. | |||||
| This share is a parent to an already-imported share. Namespace shares cannot overlap. Use the filer command to change the path or share name. | |||||
| The shares root directory has attributes (such as owner, group, and permission settings) that are inconsistent with those of the already-imported shares. You can access the back-end filer directly to change these attributes, or you can use the import sync-attributes command to allow the volume to change the attributes for you. Then re-enable the share (enable (gbl-ns-vol-shr)) to restart its import. | |||||
| For NFS exports, check your back-end filer configuration: the back-end share should allow root access to all of the ARXs proxy IP addresses. Use the show exports command examine all permission settings at the filer. Use the show ip proxy-addresses command to list all configured proxy IP addresses. For CIFS shares, the switch uses the namespaces proxy user (username and password). The proxy-user credentials must belong to the Administrators group at every filer behind the namespace. The proxy-user (gbl-ns) command sets the proxy user credentials for a namespace. After you find and fix this issue, you can restart the share import: enter gbl-ns-vol-shr mode for this share and re use the enable (gbl-ns-vol-shr) command. | |||||
| The share cannot be found on the external filer. Use the filer command to change the path or share name for this share, then re-enable the share (enable (gbl-ns-vol-shr)) to retry the import. | |||||
| (CIFS) The volume supports cifs access-based-enum (ABE), and attempted to replicate ABE settings between its back-end shares. This replication process failed. The same process also checks for CIFS subshares (filer-subshares), so you can use sync subshares from-namespace ... tentative to get a full report on this issue. This often occurs because the ARX does not have proper permissions to check for ABE support on this back-end share. The ARX uses the namespaces proxy user (username and password) as its identity when it checks for ABE support. The proxy-user credentials must belong to the Administrators group at this back-end filer. You can use the proxy-user (gbl-ns) command to choose new proxy user credentials for the namespace. After you find and fix this issue, use nsck ... rebuild volume to reimport all shares in the volume. | |||||
| (CIFS) This is a CIFS error that is not an access or network error, but prevented the import. The syslog shows the specific error. Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog. After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import. | |||||
| (multi-protocol) The volume software encountered an NFS symbolic link on this back-end share, and the volume has cifs deny-symlinks enabled. You can resolve this issue by using the no cifs deny-symlinks command to allow the volume software to follow these links. Alternatively, you can remove all NFS symbolic links from the back-end share. | |||||
| (CIFS) The back-end filer returned an unexpected CIFS error during import. The syslog shows the specific error. Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog. You may need to escalate to F5 Support. After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import. | |||||
| (CIFS) The filer returned an unexpected error during the import, and the error indicates a problem at the filer itself. The syslog shows the specific error. (Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog.) Check the filer itself and correct the problem there. After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import. | |||||
| (CIFS) The back-end share returned an error indicating that it does not support a CIFS option that the ARX requires. Consult the F5 Data Solutions Compatibility Matrix (included in this doc set) to confirm that the filer has been qualified for use behind the ARX. If the share cannot possibly support CIFS behind an ARX, you can use no share to remove the share from the volume. | |||||
| (CIFS) The namespace software attempted to write a test file to the share and failed. Go to the filer and check permissions for the namespaces proxy-user (gbl-ns); the proxy user must be part of the Backup Operators and/or Administrators group on the filer. After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import. | |||||
| (CIFS) The volume supports filer-subshares and/or cifs access-based-enum (ABE), and attempted to replicate subshares, subshare ACLs, and/or ABE settings between its back-end shares. This replication process, also known as subshare synchronization, failed. As a result, any front-end export of the failed subshare will be degraded. The output of show cifs-service fqdn shows all of the degraded subshares in a given fqdn service. Use sync subshares from-namespace ... tentative to get a full report on this issue. To repair it, use the sync subshares from-namespace or sync subshares from-service command without the tentative option. | |||||
| Use the proxy-user command to add or edit these credentials, and use the proxy-user (gbl-ns) command to apply them to a namespace. After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import. | |||||
| You can use show cifs-service open-files to find the open file, close cifs file to close it, and then retry the share import (with enable (gbl-ns-vol-shr)). | |||||
| Failure to update file attributes can be caused by loss of connectivity during the import. Use the show exports command and/or ping to check the connection to the filer. After you correct the error, re-enable the share (enable (gbl-ns-vol-shr)) to retry the import. | |||||
| Two or more of the volumes shares had common file names that either collided or had NFS/CIFS naming inconsistencies, and this volume disallows import if it encounters either of these problems. As an example of a collision, suppose share A and share B had the same file in the same path, \docs\index.htm: these files would collide. A naming inconsistency can only occur for a directory in a multi-protocol (NFS and CIFS) namespace; the CIFS-side directory name has unicode characters that are inexpressible on the NFS-side (see the documentation for the character-encoding nfs command). The volume must be allowed to modify the directory (or one of the colliding files) for the import to succeed: the directory or file must be renamed. All duplicate files and naming inconsistencies are recorded in the import reports for each share. These reports are named import.job-id.share-name.share-id.rpt. Use show reports to list all import reports and read their contents. Using the import report for each share, resolve all file collisions and naming inconsistencies before re-importing. Go to the filers and rename the files, move them, and/or resolve that certain file renames are acceptable. Once the issues are cleared, use the gbl-ns-vol reimport-modify and modify commands to allow modification (renames) on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) To rename inconsistent NFS/CIFS directories, use the import rename-directories unmapped-unicode command, too. | |||||
| To retry the import, you can use the enable (gbl-ns-vol-shr) command on this share. | |||||
| Remove all DFS links from the back-end share. Then use the enable (gbl-ns-vol-shr) command to retry the import. | |||||
| To allow the volume to modify directory attributes on import, you can use modify on the volume and import sync-attributes on the share. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) Then use the enable (gbl-ns-vol-shr) command to retry the import. | |||||
| This can only occur for NFS-only directories, with names that are illegal in CIFS. If possible, change the directory name(s) so that they are accessible from CIFS. As an alternative, you can use no strict-attribute-consistency to remove the requirement for strict-attribute consistency; this reduces all undiscovered CIFS attributes to zero. Once the volume has stopped importing any shares, you can do this for all shares in the volume. Then restart this share import with the enable (gbl-ns-vol-shr) command. | |||||
| To allow the volume to correct this by changing the directory name on import, you can use modify on the volume and import rename-directories on the share. Alternatively, you can directly access the filer(s) and correct the problem there. Retry this share import (with enable (gbl-ns-vol-shr)) after you address the issue. | |||||
| Two or more of the volumes shares had common file/directory names that somehow collided, causing one of the shares to fail its import. The following collisions can cause this failure:
All duplicate files and naming inconsistencies are recorded in the import reports for the share. These reports are named import.job-id.share-name.share-id.rpt. Use show reports type Imp to list all import reports, and use show reports report-name to read a report. Using the import report for this share, resolve all file collisions and naming inconsistencies before re-importing. Go to the filers and rename the files, move them, and/or resolve that certain file renames are acceptable. You can also use some share-import options to have the volume automatically rename files, rename directories, or reset directory attributes in this share during import (import rename-files, import rename-directories, or import sync-attributes). If you use any share-import options, use the gbl-ns-vol reimport-modify and modify commands to allow modification (renames) on import. Then re-import the share with the enable (gbl-ns-vol-shr) command. | |||||
| The share import failed for an undetermined reason. Run the collect diag-info CLI command to collect diagnostic information, then contact F5 Support. | |||||
| An internal import operation timed out, possibly due to a filer-connectivity issue. Use the show exports command and/or ping to troubleshoot the connection to the filer. | |||||
| The managed volume software supports a maximum of 1024 hard links per file. One or more files on this back-end share exceed this limit. These files are recorded in the shares import report, named import.job-id.share-name.share-id.rpt. Use show reports type Imp to list all import reports, and use show reports report-name to read a particular report. Then access the filer directly to reduce the number of hard links for all of these files. | |||||
| If this happens to all shares after a switch replacement, the old switchs UUID was not properly applied to the replacement switch. Consult the appropriate Hardware Installation manual for switch-replacement instructions. | |||||
| Check the share configuration at the filer: the ARX requires read/write access throughout the shares directory tree. Use the show exports command to examine all permission settings at the filer.
Once the permissions issue is resolved, you can re-import the share with the enable (gbl-ns-vol-shr) command. | |||||
| Once some space is free, you can use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| This indicates permissions problems at the back-end filer. Use the show exports command to examine all permission settings at the filer.
Once the permissions issue is resolved, you can re-import the share with the enable (gbl-ns-vol-shr) command. | |||||
| The back-end device could not be located with the IP address configured for the filer. From gbl-ext-filer mode, use the ip address command to reset the filers address. Use the show exports command, expect traceroute, and/or ping to check the connection to the filer. After the filer connection is re-established, you can use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| (NFS) These errors indicate an NFS-server problem at the filer. Once the filers NFS service is restored, you can use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| This may indicate a full disk on the back-end filer or permissions problems. Use the show exports command to examine all permission settings at the filer.
Once the permissions issue or space issue is resolved, you can re-import the share with the enable (gbl-ns-vol-shr) command. | |||||
| You can use show cifs-service open-files to find the open file, close cifs file to close it, and then retry the share import (with the enable (gbl-ns-vol-shr) command). | |||||
| (NFS) These errors indicate an NFS-server problem at the filer. Once the filers NFS service is fully restored, you can use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| The back-end device could not be located with the filer name or IP address configured for the filer. From gbl-ext-filer mode, use the ip address command to reset the filers address. Use the show exports command and/or ping to troubleshoot the connection to the filer. After the filer connection is re-established, you can use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| (CIFS) The namespace supports Kerberos authentication (see cifs authentication), but the namespace software is unable to confirm that the share is configured to support Kerberos, too. Check the connection to the back-end filer with show exports and/or ping. Restart the import (with enable (gbl-ns-vol-shr)) after you correct the problem. | |||||
| The share import failed due to an internal-software conflict, possibly due to a timing issue or a brief filer-connectivity issue. Retry the import by using the enable (gbl-ns-vol-shr) command on this share. If this error returns, contact F5 Support. | |||||
| (NFS) Persistent errors from a back-end share caused the mount to fail. Check the NFS service at the back-end filer. Once the filers NFS service is fully restored, you can use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| A file on this share has the same name and path as a file on an already-imported share. To fix this, you can manually go to the filer and rename the file, or you can set the modify flag on this volume. By setting the modify flag, you allow the volume to rename the file on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) You must also have the default settings for import rename-files and import rename-directories on this share. Then restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| Check the directory at the back-end share, and rename it so that both versions have the same name. Alternatively, you can set the modify flag on this volume. By setting the modify flag, you allow the volume to rename the directory on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) You may also need to set import rename-directories unmapped-unicode for this share; this allows the volume to rename directories whose CIFS names do not map to the character encoding for NFS. Then restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| A file on this share has the same name and path as a file on an already-imported share. To fix this, you can manually go to the filer and rename the file, or you can set the modify flag on this volume. By setting the modify flag, you allow the volume to rename the file on import. (If any other shares are still importing, you must wait for their imports to finish before you can use the modify command.) You must also have the default settings for import rename-files and import rename-directories on this share. | |||||
| Clear some free space at the filer share, then restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| Rename the file at the filer share, then use nsck ... rebuild volume to reimport all shares in the volume. | |||||
| The protocol(s) configured for the back-end share are not actually supported at the filer. Use the show exports command to check the protocols supported by the filer. Use the show global-config namespace command to view the required protocols for the namespace. The share must support all of the namespaces protocols. You can remove the share from the volume (with no share), or you can add protocol support at the back-end filer. If you add the protocol support to the filer, you can then restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| This may indicate a disk failure at the external filer. Correct the filer issue and retry the import (with the enable (gbl-ns-vol-shr) command). | |||||
| The import report shows the name of the conflicting file or directory. The name appears with an FC notation. The report is named import.job-id.share-name.share-id.rpt. Use show reports to list all import reports and read their contents. Using the import report, resolve all of these name collisions before re-importing. Go to the filer to rename the files and/or directories. Then use enable (gbl-ns-vol-shr) to re-import the share. | |||||
| The back-end filer behind this share returned an error that the ARX does not recognize. You can use the show logs syslog command to view the system log and learn more about the circumstances around the failure. We recommend that you contact F5 Support if you see this import error. You may be requested to run the collect command, which assembles diagnostic information for F5 Engineering. | |||||
| The import failed because the back-end filer returned a link count of zero or a negative number for a file, which is invalid. A files link count should be one or more. The ARX syslog contains the file with the invalid link count; use grep link count logs syslog to find the path. Use this path to help diagnose and correct the filer issue. Then use the enable (gbl-ns-vol-shr) command to retry the import. | |||||
| Use the show exports command and/or ping to check the connection to the filer. Restart the import (with enable (gbl-ns-vol-shr)) after the connection is restored. | |||||
| You can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| This share contains more files than the volume can hold. Use the auto reserve files command to automatically increase the number of files that this volume can hold as the volume grows. If you prefer to manually set the maximum files for the volume, use reserve files to manually increase the maximum. Then restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| A volumes metadata share requires gigabytes of free space; the one chosen for this volume has less than one-half gigabyte. Choose a metadata share with more free space: use the metadata share command to configure a new metadata share. After you choose another metadata share, or clear up several gigabytes of free space on the current metadata share, you can use the enable (gbl-ns-vol-shr) command to restart the import. | |||||
| These errors each indicate an internal software problem. Run the collect diag-info CLI command to collect diagnostic information, then contact F5 Support. Once the issue is understood, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| The specific directory and file name appears in a syslog message labeled ERROR_MAX_HASH_COLLISIONS. Use grep ERROR_MAX_HASH_COLLISIONS logs syslog to search for this error in the syslog. After you clear enough colliding files from the directory, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| Once all of the shares paths are below 1024 characters, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| There was a database I/O failure for the share. This may be caused by a transient network error, or a filer problem. You can use the show exports command to check the filer and connection for common problems. Once the external problem is resolved, use nsck ... rebuild volume to reimport all shares in the volume. | |||||
| Use nsck ... rebuild volume to re-initialize the metadata share and reimport all shares in the volume. | |||||
| The switch could not contact the metadata share. Use the show exports command and/or ping to check the connection to the metadata shares filer. The show export command also verifies that the share is accessible by root (for NFS shares) or the namespaces proxy-user (gbl-ns) (for CIFS shares). After the connection is re-established, restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| (multi-protocol) The NFS character-encoding setting for the namespace does not match the character encoding supported at the filer. If this share was imported, lost NFS files could result. Reset the namespace character encoding (using the character-encoding nfs command) and retry the import. You can use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| (multi-protocol) The filer command specified an NFS export and a CIFS share over two different directory trees. This is unsupported. Retry the command with the correct share and export names, then retry the import with enable (gbl-ns-vol-shr). | |||||
| (multi-protocol) During import, the volume creates a test file through CIFS and then attempts to read it through NFS. The volume was unable to read the file as root. Check the NFS configuration at the back-end share, correct the problem, and retry the import (enable (gbl-ns-vol-shr)). | |||||
| (multi-protocol) During import, the volume creates a test file through CIFS and then attempts to delete it through NFS. The volume could read and write the file (as root), but was unable to remove it. This may indicate a permissions problem in the top-level directory for the share. Check the NFS configuration at the back-end share, correct the problem, and retry the import (enable (gbl-ns-vol-shr)). | |||||
| (multi-protocol) During import, the volume creates a test file through CIFS and then attempts to write to it through NFS. The volume could read the file, but was unable to write to it (as root). Check the NFS configuration at the back-end share, correct the problem, and retry the import (enable (gbl-ns-vol-shr)). | |||||
| After the filers NFS service is fully restored, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| (NFS) The back-end share does not support the NFS version(s) configured for the external filer. Use the show exports command to check the protocols supported by the filer. Use the filer command to change the configured NFS version(s) for the share/export. | |||||
| Use the show exports command, expect traceroute, and/or ping to troubleshoot the connection to the filer. After the filer connection is re-established, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| (CIFS) A connection error occurred in the middle of a CIFS-permissions test. Use the show exports command, expect traceroute, and/or ping to troubleshoot the connection to the filer. Once the connection is fully restored, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| The namespaces proxy-user does not have adequate privileges to write to this CIFS share, so the import failed. The proxy user must belong to the Administrators group on this filer. You can choose new, more-privileged credentials for your proxy user, or you can go to the filer and add the current proxy user to a more-privileged group. The probe exports command can verify that the new proxy-user credentials pass this write test. Then restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| Clear some free space at the filer share, then restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| An administrator issued the cancel import command to stop this share import. You can restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| For NFS exports, check your back-end filer configuration: the back-end share should allow access to all of the ARXs proxy IP addresses. Use the show exports command to check the filers permissions and configuration. Use the show ip proxy-addresses command to list all configured proxy IP addresses. For CIFS shares, the switch uses the proxy user for the namespace; the proxy-user (gbl-ns) command sets these credentials. The proxy user must belong to the Administrators group. After the permissions problem is corrected, you can restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| (CIFS) The back-end filer returned an unexpected CIFS error during import. The syslog shows the specific error. Use show logs syslog to read the syslog, or grep string logs syslog to search for a specific string in the syslog. You may need to escalate to F5 Support. | |||||
| (multi-protocol) The proxy user is a Windows username and password that the volume can use as its identity for share import and for policy operations. In a multi-protocol (CIFS and NFS) namespace, the proxy user on the Windows side must map to the root user on the UNIX side. You can select a new proxy user for the namespace with the command. If necessary, map the proxy user to root at the filer itself; the ARX Site Planning Guide has instructions for creating this mapping on common multi-protocol filers. | |||||
| An administrator failed to remove the share with no share because client-visible files are still present on the share. Use the remove-file-entries option to remove all of the file entries from the volume; this produces a client-visible effect, so do this with caution. Alternatively, you can use remove-share nomigrate. | |||||
| Check your back-end filer configuration: the back-end share should have no-root-squash set for all of the ARXs proxy IP addresses. (On some filers, you accomplish this by mapping the anonymous user to UID 0 (zero).) Use the show exports command to check the filers permission settings. Use the show ip proxy-addresses command to list all configured proxy IP addresses. Once the filers root-squash option is disabled, you can restart the import with the enable (gbl-ns-vol-shr) command. | |||||
| After the filers NFS service is fully restored, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| (CIFS) The CIFS attributes set for the volume (with compressed-files, named-streams, persistent-acls, sparse-files, and/or unicode-on-disk) are not all supported at the back-end share. Use the show exports command to check the supported CIFS attributes for the share. You can remove the share from the volume (with no share) or disable the conflicting CIFS attribute(s) in the managed volume. If you elect to keep the share in the volume, use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| (CIFS) The namespace supports Kerberos authentication (see cifs authentication), but this share does not. The share must support extended security negotiations for the import to succeed. Also, the ARX needs the correct service-principal name (SPN) for the filer; you can use show exports ... capabilities to verify that the ARX has discovered the correct SPN for the filer, or you can use the spn command to set it manually. After you ensure that the filer support Kerberos and the ARX has the filers SPN, you can restart the import (enable (gbl-ns-vol-shr)). Alternatively, you can remove the share from the volume with no share. | |||||
| Each back-end share must support all of the namespaces configured protocols (any combination of NFSv2, NFSv3(/UDP), NFSv3/TCP, and CIFS). Use the show global-config namespace command to view the namespaces protocols. You can remove the share from the volume (with no share) or enable the missing service(s) at the filer. If you elect to keep the share in the volume, use the enable (gbl-ns-vol-shr) command to restart the share import. | |||||
| The export name is incorrect in the external-filer configuration. Use the filer command to change the configured name for the share/export. | |||||
| You can restart the share import with enable (gbl-ns-vol-shr) after you resolve the filer issue. | |||||
| From gbl-ns-vol-shr mode in the CLI, use no filer to detach from the back-end share. Then choose another back-end path with the filer command, or use no share to remove the share from the volume. To restart the import (with or without this share), use nsck ... rebuild volume to reimport all shares in the volume. | |||||
| Someone attempted to remove a share (with no filer, no share, remove-share migrate, remove-share nomigrate, or remove service), and an internal error caused the removal to fail. Contact F5 Support if you see this message. | |||||
| The connection to the back-end CIFS share failed due to possible configuration errors or a broken connection to the back-end filer. Use the show exports command, expect traceroute, and/or ping to troubleshoot the connection to the filer. Once the connection is fully established, you can restart the share import with the enable (gbl-ns-vol-shr) command. | |||||
| Once the filer issue is corrected, use nsck ... rebuild volume to reimport all shares in the volume. | |||||
| A CIFS-permission test failed at the filer for an undetermined reason. This may be a filer issue or a connectivity issue. Check the filer and the connection, and retry the share import (with enable (gbl-ns-vol-shr)). If this error stops the import a second time, run the collect diag-info CLI command to collect diagnostic information and contact F5 Support. | |||||
| (CIFS) A file on this share has the same name and path as a file on an already-imported share, based on a case-blind comparison, and the volume is configured with no cifs case-sensitive. That is, some of the characters have differing cases, but the characters match (for example, index.htm matches index.HTM). If the volume is not case-sensitive, it cannot see the difference between the two names.
Then retry the import with the enable (gbl-ns-vol-shr) command. | |||||
| An administrator stopped the import with the cancel import command. You may be able to restart the import with no enable (gbl-ns-vol-shr) and then enable. If the import was stopped too far in the process, you must first use nsck ... destage to shut down the volume, remove and re-add the share, then enable the volume again. | |||||
| Internal Error (number) | Internal problem; contact F5 personnel. | ||||
| No imports are possible unless the volume is enabled. Use the enable (gbl-ns, gbl-ns-vol) command to enable the volume. | |||||
| The metadata share for the volume failed to import. Use metadata share to designate a new dedicated share for metadata. | |||||
| An administrator stopped the share removal with the cancel remove command. To restart the removal process, use remove-share migrate, remove-share nomigrate, no share, or no filer. | |||||
| The import process was interrupted by an nsck ... rebuild force. The rebuild operation will re-import the share. | |||||
| DNAS, the internal name for volume software, is shutting down. This may be the result of administrative action, such as a remove service, during the import. The volume has stopped running, so the import is canceled. | |||||
| Use the filer command to assign a filer to the share, then retry the import. |
In most cases, you can restart a failed import by re-enabling it. For details on enabling a share in a managed volume, refer to Enabling the Share, on page 9-45 of the ARX® CLI Storage-Management Guide.
For example, this command sequence successfully restarts an import for the wwmed~/acct~budget share:
bstnA(gbl)# namespace wwmed
bstnA(gbl-ns[wwmed])# volume /acct
bstnA(gbl-ns-vol[wwmed~/acct])# share budget
You can remove the volume from the share as a first step to retrying the import, or as a final step.
Use the remove-files migrate command to migrate all files and directories to another share before removing it from the volume. This command was described above; see Removing an Imported Share.
bstnA(gbl)# end
bstnA# remove-share migrate wwmed /acct budget bills
bstnA# ...
To keep imported directories in the volume but remove any of the shares imported files, use the remove-files nomigrate command. This was described in Removing Shares Without File Migration. This moves all of the shares master directories into another share in the same volume, then removes the share from the volume. Any imported files disappear from client view.
bstnA(gbl)# end
bstnA# remove-share nomigrate wwmed /acct budget bills
bstnA# ...
To remove all traces of the share, you must remove all of the shares directories from the volumes directory tree. This is a serious change in the volumes metadata, and it requires that you take the volume offline. Use nsck ... destage to take the volume offline (recall De-Staging a Single Volume), remove the share from the volume, then re-enable all of the volumes remaining shares (as shown in Enabling All Shares in the Volume, on page 9-54 of the storage-management manual).
bstnA(gbl)# end
bstnA# nsck wwmed destage volume /acct
bstnA# global
bstnA(gbl)# namespace wwmed
bstnA(gbl-ns[wwmed])# volume /acct
bstnA(gbl-ns-vol[wwmed~/acct])# no share budget
bstnA(gbl-ns-vol[wwmed~/acct])# enable shares
bstnA(gbl)# namespace wwmed
bstnA(gbl-ns[wwmed])# volume /acct
bstnA(gbl-ns-vol[wwmed~/acct])# share budget
bstnA(gbl-ns-vol-shr[wwmed~/acct~budget])# filer das1 nfs3 /exports/budget
The entire volume fails if its metadata-share fails or if its only share fails. In either case, you use nsck ... rebuild volume to delete the volumes metadata and completely rebuild it (as described in Rebuilding a Volume).
bstnA(gbl)# end
bstnA# nsck wwmed rebuild volume /it
bstnA# ...
You can use a single command to remove a namespace, all of its volumes, all the global servers and services that export its volumes, and any other configuration objects that are used only by this namespace. All of these components together comprise a single namespace service. From priv-exec mode, use remove service command to remove the full namespace service:
namespace (1-30 characters) is the namespace to remove,
seconds (optional, 300-36,000) sets a time limit for the removal of each namespace component, and
sync (optional) waits for the removal to finish before returning. With this option, the CLI lists the namespace and global-server components as it removes them.
The CLI prompts for confirmation before removing the namespace and all of its services. Enter yes to continue.
This operation generates a report, remService_namespace_date.rpt, which catalogs all of the actions that it took. The namespace in the file name identifies the removed namespace, and the date is the date and time when the command started. The CLI shows the report name after you invoke the command. Use show reports to see the file listing; use show, tail, or grep to read the file. To save the report off to an external site, use the copy ... ftp or copy ... scp command from priv-exec mode.
The command does not create the report if you use the sync option; it shows its actions at the command line instead.
bstnA(gbl)# end
bstnA# remove service medco
bstnA# ...
bstnA# show reports remService_medco_201002240751.rpt
bstnA# ...
You can use a single command to remove all rules, share farms, and other policy objects from a namespace. The remove namespace command has been described in the ARX® CLI Storage-Management Guide: see Removing a Direct Volume, on page 8-31, Removing a Managed Volume, on page 9-68, or Removing a Namespace, on page 7-26. Add the optional policy-only keyword to remove only the policy objects:
name (1-30 characters) is the name of the namespace,
policy-only is the option to remove only the policy objects,
seconds (optional, 300-10,000) sets a time limit on each of the removals component operations, and
sync (optional) waits for the removal to finish before returning. With this option, the CLI lists the policy objects as it removes them.
The CLI prompts for confirmation before removing the policy objects. Enter yes to continue. This operation generates a report named removeNs_namespace_date.rpt if you omit the sync option.
prtlndA(gbl)# end
prtlndA# remove namespace insur_bkup policy-only timeout 600 sync
prtlndA# ...
name (1-30 characters) is the name of the namespace,
volume (1-1024 characters) is the path name of the volume,
policy-only is the option to remove only the policy objects, and
seconds (optional, 300-10,000) sets a time limit on each of the removals component operations, and
sync (optional) waits for the removal to finish before returning, as described above.
bstnA(gbl)# end
bstnA# remove namespace insur volume /claims policy-only
When a managed volume is enabled, the ARX takes inventory from all of the volumes back-end shares and includes their files into the volume. An important part of this process is to ensure that there is only a single instance of any given path or file name. If you have a path or file name that is identical on more than one back-end share, there is an import collision; only one of the files can be imported into the managed volume. The redundant file is renamed as follows:
file-name is the files original name, without its extension (for example, myfile from myfile.doc),
share is the name of the namespace share,
jobid is an integer identifying the job that imported the share, and
.ext is the files original extension (for example, doc), if there is one.
where index is a number starting at 1.
To find any files that have collided and been renamed, you can view the report that was generated during import. Each share generates one import report each time it imports (import occurs when the share and volume are first enabled, or if you use nsck ... rebuild to rebuild the volume). Use the show reports type Imp command to see all import reports.
bstnA(cfg)# show reports type Imp
Use show reports file-name to view the import report. A collision appears in the File Scan Phase section, with a Type of R (Rename) and NC (name collision). For example, the following report shows three collided files (highlighted in bold):
bstnA(cfg)# show reports import.3.bills2.7.rpt
Volumes that support CIFS have an additional possible naming-collision obstacle, caused by back-end servers keeping an extra name for some files and directories. Windows once ran on file systems (such as FAT12 and FAT16) that supported only short file names, sometimes called 8.3 names. An 8.3 name uses the following format:
base-name[.ext]
| base-name is 1-8 characters, |
| . is optional, and |
| ext is 1-3 characters. |
Newer Windows servers run NTFS, which supports file and directory names of any length. Other file systems that support CIFS also support names of any length. For backwards compatibility, these contemporary file systems continue to support an alternate 8.3 name for any file or directory that does not fit the above pattern. The alternate name is sometimes called a filer-generated name (FGN) since it is created by the filer. The longer name is called the primary name. Contemporary Windows clients see the primary name while older Windows applications see only the alternate name, the 8.3 FGN. Contemporary applications can use either name to access the file or directory, though, by default, they do not see the alternate name.
name-with-tilde[.ext]
| name-with-tilde (2-8 characters) has one tilde (~) character (such as RANDOM~2), and |
| ext is optional and has 1-3 characters. |
name-without-tilde[.ext]
| name-without-tilde (exactly 8 characters) has no tilde (~) character (such as 0000D773), and |
| ext is optional and has 1-3 characters. |
Run an nsck-inconsistencies report (recall Finding Metadata Inconsistencies) to identify 8.3 name collisions. Each file with this issue is flagged with F8, and each directory is flagged with D8.
bstnA# nsck medarcv report inconsistencies /rcrds outputfile rcrdsIssues
bstnA# show reports rcrdsIssues.rpt
bstnA# ...
 | The volume also blocks some client operations inside a directory with a trailing-period name. For example, creating the file, \myvol\mydir.\newFile.txt, could fail because of the period at the end of the parent directorys name, \mydir.. The volume would block this if it meant that the volume would have to replicate \mydir. on a filer that would change it into an FGN. |
The final case is subtle, and may require a search through the syslog file (recall Accessing the Syslog) to prove that a trailing-period is at fault. Search for the string TRAIL for syslog messages about illegal trailing periods. Use grep TRAIL logs syslog to search for messages about trailing periods, or grep ip-address logs syslog to find all messages concerning a client at ip-address.
bstnA# show reports import.6.charts.12.rpt
bstnA# ...
You can use the show namespace command to find if a particular share converts trailing-period names into FGNs: the no-trail-period flag appears in the shares Features field.
bstnA# show namespace swic volume /users share samba1
bstnA# ...
| file migrations through file-placement rules (see Placing Files on Particular Shares, on page 14-4 of the ARX® CLI Storage-Management Guide), |
| file or directory replications to a shadow volume (see Configuring a Shadow-Copy Rule (Source Switch), on page 16-9 of the same manual). |
NFS-only entries, under rare circumstances, can also impede volume performance. The volume does not record any FGNs from its filers; instead, it probes for FGNs only when a collision with an FGN is possible. An FGN collision can only occur in a directory that has one of two problems: either it contains NFS-only entries, or it contains a name that matches an FGN pattern (like FILE~2.txt).
If CIFS clients complain about access issues or slow performance, you should identify the NFS-only entries in the volume and work toward changing their names. This is especially true for directory names, which can obscure multiple files and directories from CIFS users. Run an nsck-inconsistencies report with the multi-protocol flag (recall Focusing on Multi-Protocol Issues) to reveal all NFS-only file names and directory names. Each of them is flagged with an NF. For example, this command sequence generates and shows an inconsistencies report for the insur namespace, which reveals several NFS-only files and directories:
bstnA# nsck insur report inconsistencies multi-protocol outputfile insur_fgns
bstnA# show reports insur_fgns._claims.rpt
A case-blind collision occurs when two or more entries in the same parent directory have names that differ only in case (for example, index.html and INDEX.html). CIFS does not support case collisions, but NFS does. These are created by NFS clients, either before import or while the volume is in service.
Note: If a directory contains more than 1,024 case collisions, its parent directory incurs an additional performance penalty if it checks for FGN collisions during metadata-intensive operations (share import, restore data, all nsck operations, and sync). The FGN-collision check was described in Performance Issues.
The following characters are legal in NFS file names but illegal in their CIFS counterparts: any control character, /, \, :, *, ?, >, <, , or |. Additionally, a trailing period (.) or a trailing space character is illegal in a CIFS name; recall Fixing File/Directory Names with Trailing Periods. Files and directories with any of these illegal CIFS characters are NFS-only. Like case collisions, these are created by NFS clients.
(!) nnn_changed-file-name
nnn is a different number for every AGN in this directory. This number is padded so that it is always at least three digits long.
changed-file-name is the original file name (or directory name), with all illegal characters replaced with an underscore character (_).
The ARX only generates CIFS-side AGNs. NFS-side AGNs are not possible in the current implementation.
Some illegal file or directory names may have been created by CIFS clients before import. CIFS natively supports all Unicode characters in its file or directory names, but NFS servers must specifically have their character encoding configured to support them. Otherwise, many Unicode characters are non-mappable to NFS. A multi-protocol filer set for Latin1 character encoding may have allowed CIFS clients to use Unicode characters (such as Korean or Japanese characters) in entry names. If so, the filer accepted the CIFS name and created an FGN for its NFS clients.
where C is a character that is not supported by the filers NFS character encoding.
[ NI NM ] [shr1-old ] /images/file012b/ (Characters: U+012b)
A directory may contain a large tree of subdirectories and files, so the import process takes greater care in keeping it accessible and easily recognizable from both CIFS and NFS. If the volume is allowed to modify its imported shares and rename directories in the particular share, it renames the directory based on its CIFS name. The import for the share fails if the volume is not allowed to both modify and rename directories; this is discussed in Preventing Directory Renames During Import, on page 9-38 of the ARX® CLI Storage-Management Guide.
where new-dirname is the original CIFS-side name, but with (U+nnnn) in place of each unmappable character. The nnnn is the Unicode number for the character, shown in hexadecimal format. The name is truncated if it exceeds 256 characters. For example, dir(U+30D2)(U+30AA)_myshare-2.
Any NFS-only directory is called a split directory. All descendents of split directories are flagged with an SP in the inconsistencies report; they are flagged because they are inaccessible to CIFS clients. For example, here is a split directory and its descendents:
[ SP] [shr1-old ] /tools/extractCdDocs.pl
[ SP] [shr1-old ] /tools/cleanBU.csh
Some multi-protocol directories are marked in the metadata for FGN-collision checking. A directory is marked for this processing if it contains entries with either of the following name issues:
If the directory contains either of these name types, the volume must check for FGN collisions every time a client creates a name of the other type. The FGN-collision check was described earlier, in Performance Issues. This check occurs for all types of clients, including the policy engine; that is, the volume also performs extra checking before migrating any FGN-related files or subdirectories from one back-end share to another.
A directory remains marked for this checking even if clients remove all NFS-only and FGN-matching entries from it. You can remove the mark by emptying the directory completely, or by cleaning out all entries with FGN issues and running sync files on it. The latter option is described later in this section.
Another disadvantage for a marked directory can be extra back-end copies (called stripes) for some of its NFS-only subdirectories. Before the policy engine migrates any NFS-only file (such as newFile in a directory that already contains NEWFILE), it stripes all of its subdirectories that fit an FGN pattern (such as DIR~3) to the target share. Then it migrates the file. This ensures that the subdirectories remain open to both CIFS and NFS. It also creates extra, unexpected directory stripes on the back-end target share.
After the rename(s), you must run the sync files ... recurse command to remove the NFS-only flags from the volumes renamed files and directories. The sync utility probes all of the volumes shares to confirm that no FGN collisions exist. This also removes the marks from any directories that no longer contain any NFS-only entries. The sync files command was described in an earlier chapter: recall Synchronizing Metadata with Actual Files.
bstnA(gbl)# end
bstnA# sync files insur volume /claims path / recurse
bstnA# ...
All file migrations are concerned with file attributes in addition to the files themselves. File attributes are permission settings, the name or ID of the user who owns the file, the group or groups who have access to the file, last-modified times, named streams, and other external data associated with the file. File-attribute migrations require special semantics in a multi-protocol namespace (that is, a namespace whose shares support both NFS and CIFS access). If your namespace is NFS-only or CIFS-only, you can skip this section.
If the ARX migrates the filer from Filer X to Filer Y (made by two different vendors), it takes these different semantics into account. This ensures that the NFS and CIFS file attributes are preserved as much as possible as they are migrated from one vendor to another. In some cases, file attributes are interpreted differently on the destination filer. The sections below share the details of attribute migration.
| copied, then reset after file is transferred through CIFS | ||||
| all copied after SD | ||||
| copied, then reset after file is transferred through CIFS | ||||
| copied after UNIX attributes | ||||
| all copied after SD | ||||
| copied after UNIX attributes | ||||
| copied, then reapplied after the file is transferred through CIFS | ||||
From any mode, you can use the show policy history command to show all of the policy transactions for a given managed volume:
namespace (1-30 characters) is the namespace, and
vol-path (1-1024 characters) identifies the volume to examine.
bstnA(gbl)# show policy history namespace wwmed volume /acct
namespace (1-30 characters) is the namespace,
vol-path (1-1024 characters) identifies the volume to examine, and
rl-name (1-1024 characters) is one rule or share farm.
bstnA(gbl)# show policy history namespace wwmed volume /acct rule docs2das8
bstnA(gbl)# ...
bstnA(gbl)# show policy history namespace wwmed volume /acct rule fm1
bstnA(gbl)# ...
Any files that are waiting to be migrated appear in the policy queue. Use the show policy queue command to see if any migrations are pending:
namespace (1-30 characters) is the namespace, and
vol-path (1-1024 characters) identifies the volume to examine.
bstnA# show policy queue namespace medarcv volume /rcrds
You can configure a file-placement rule to automatically close any open files and hold them closed until the file is migrated. This makes it possible for the rule to migrate the file without interference from client writes. This feature is discussed in of the Automatically Closing All Open Files (CIFS), on page 14-14 of the ARX® CLI Storage-Management Guide.
To see all files that are currently held closed, add the auto-close option to the end of the show policy queue command:
bstnA# show policy queue namespace medarcv volume /rcrds auto-close
bstnA# ...
To cancel a volumes pending migrations, go to priv-exec mode and use the cancel migration command:
namespace (1-30 characters) identifies the namespace, and
vol-path (1-1024 characters) is the managed volume with pending migrations.
bstnA(gbl)# end
bstnA# cancel migration insur volume /claims
bstnA# ...
cancel migration file file-name
where file-name (1-1024 characters) is a full virtual path to the file, including the path name of the managed volume that contains it. This is the file path that clients see.
bstnA(gbl)# end
bstnA# cancel migration file /claims/y2kclaims/artwork/bigpict.tif
bstnA# ...
The nsck... report inconsistencies command compares the attributes of the master directory to the attributes of each secondary directory and reports any discrepancies.
The nsck... report inconsistencies command also compares the state of striped directory attributes to the inconsistent-attributes flag in the metadata. Any discrepancies that are found are reported.
Use the nsck... sync directories command to synchronize inconsistency directory attributes.
