Applies To:

Show Versions Show Versions

Manual Chapter: Namespace Check nsck and Sync
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

37 
You can use the nsck ... migrate-metadata command to move a managed volumes metadata from one back-end share to another. Use this command to cancel a metadata migration that is currently in progress.
cancel migrate-metadata namespace volume volume
namespace (1-30 characters) and
volume (1-1024 characters) specify the volume whose metadata is migrating between back-end shares. The nsck utility performs metadata migrations; use the show nsck command for a list of volumes where the nsck utility is running.
The CLI prompts for confirmation before canceling the metadata migration; enter yes to continue. This stops the volumes metadata from migrating and returns the volume to service. The managed volume uses its original metadata share after the cancellation.
Use the nsck ... migrate-metadata command to start a metadata migration.
bstnA# cancel migrate-metadata insur volume /claims
You can use the nsck ... migrate-volume command to move an ARX volume from one volume-group to another. Use this command to cancel a volume migration that is currently in progress.
cancel migrate-volume namespace volume volume
namespace (1-30 characters) and
volume (1-1024 characters) specify the volume that is migrating between volume groups.
The CLI prompts for confirmation before canceling the volume migration; enter yes to continue. This stops the volume from migrating and returns the volume to service in its original volume group. The cancellation may take a long time in a large volume.
You can use show volume-group to show the current volume group for every volume. Use the show nsck command to monitor the progress of a volume migration.
bstnA# cancel migrate-volume medarcv volume /rcrds
nsck-id (1-2,147,483,647) identifies one nsck-report job that is currently running. The job ID appears if you run show nsck without any options.
bstnA# cancel nsck report 22
If a file or directory changes on a back-end filer without the managed volumes awareness, the volume metadata is inconsistent for that file. A sync operation discovers which files or directories are inconsistent and re-synchronizes them with the metadata; the cancel sync command stops a sync operation.
cancel sync {files | directories} namespace volume volume path dir-path
files | directories chooses the type of sync operation to cancel.
namespace (1-30 characters) is the namespace where the sync is occurring. Use the show sync command for a list of namespaces that are being synchronized.
volume (1-1024 characters) specifies the managed volume where the sync is occurring.
dir-path (1-1024 characters) specifies the directory that is being synchronized within the volume, if any. This path is relative to the volume root, above. Use forward slashes (/) for NFS or CIFS paths.
Use the sync files command to find files with metadata inconsistencies and repair them, or the sync directories command to find new directories on the filer that are not recorded in the metadata. Sync operations happen in the background while you continue to use the CLI; you can use the wait-for sync command to block the CLI until the sync is complete. To show all sync operations, use show sync.
bstnA# cancel sync files wwmed volume /acct path /jsmith
clear nsck [nsck-id]
nsck-id (optional, 1-2,147,483,647) identifies the nsck job to clear. The job ID appears in the report name for the nsck job. If you do not include an ID, the command clears all nsck jobs.
Use the show nsck command to view all nsck jobs that have run on this switch. After you issue this command, show nsck does not show any pending or complete nsck jobs.
bstnA# clear nsck 4
clear sync {files | directories} namespace volume vol-path
clear sync {files | directories} namespace volume vol-path path path
files | directories is a required choice. This selects the type of sync-operation records to clear.
The namespace, vol-path, and path arguments mimic the ones used in the sync files and sync directories commands. These identify one or more sync operations; if you omit all of them, the command clears all sync-files or sync-directories operations from the switch.
namespace (1-30 characters) specifies a namespace where one or more sync operations have occurred.
vol-path (optional, 1-1024 characters) specifies a volume. Use forward slashes (/) for all volumes, including CIFS.
path (optional, 1-1024 characters) identifies a particular path that has been synchronized. As with volumes, use forward slashes in all paths.
Use show sync to show all recorded sync operations. This command clears them; after you run it, the show sync command no longer displays the cleared operation(s).
The sync files and sync directories commands each start a sync operation (which runs in the background while you continue to use the CLI), cancel sync cancels a running sync, and wait-for sync blocks the CLI until a running sync completes.
bstnA# clear sync files wwmed
bstnA# clear sync directories
clears all sync-directories operations on the switch. The show sync directories command displays nothing after you do this.
Use the nsck destage command to release all back-end shares from a managed volume. Once destaged, you can access the volumes filer(s) directly without risking any metadata inconsistencies.
nsck name destage [force]
nsck name destage volume-group id [force]
nsck name destage volume volname[force]
name (1-30 characters) is the name of the namespace where the destage occurs. Use the show namespace command to see a list of configured namespaces.
destage directs the nsck utility to destage the namespace metadata and prepare it for re-import.
volume-group id (optional) chooses all of the volumes in the given volume group. A volume group shares CPU and memory resources, and can fail over from one chassis to another in a redundant configuration. It is also a failure domain for a group of volumes in the same namespace. Use the show volume-group command to show all volume groups and their volumes. Before a volume is enabled, you can use volume-group to assign it to a group. This command destages all of the volumes assigned to the group that you choose.
volume volname (optional, 1-256 characters) is the volume to destage (for example, /var).
force (optional) indicates that you want to force the destage even if another nsck job is currently under way. You can force any nsck job with this option except nsck ... migrate-metadata or nsck ... migrate-volume; you must cancel those jobs explicitly (with cancel migrate-metadata or cancel migrate-volume) before you can destage the volume.
The CLI asks for confirmation before releasing any volumes shares; enter yes to continue. This stops all client access to any of the destaged volumes.
Once the filer or share(s) have been removed and/or restored to health, you can use the enable shares command to re-import all shares into a managed volume (see enable (gbl-ns, gbl-ns-vol)). After the re-import, all NFS clients must unmount and remount any of the volumes front-end NFS exports (export (gbl-nfs)).
Note: Nsck turns off a volumes modify flag before it destages the volume, making the volume read-only (see modify). Before you run the nsck ... destage command, you can avoid this by running the gbl-ns-vol reimport-modify command.
If a volumes metadata share supports NFS and that NFS mount is hung, all of the volumes in the same volume group will eventually become unusable. The show volume-group command shows the volume-group assignments for your volumes. You can use the volume-group clause in this command to destage those specific volume groups, then reload the ARX to initiate a failover. The destaged volumes must re-import after this failover, but no other volumes are affected. NFS clients must un-mount and re-mount the NFS front-end exports for these volumes; CIFS clients are unaffected by the re-import. This re-establishes storage service on the peer ARX with minimal disruption to clients.
bstnA# nsck archives destage volume /mktg
Use the nsck migrate-metadata command to move a managed-volumes metadata from one share to another.
nsck name migrate-metadata volume volname target filer-name {nfs3 | nfs3tcp | cifs} path
name (1-30 characters) is the name of the namespace.
migrate-metadata is required.
volume volname (1-256 characters) is the chosen managed volume.
target filer-name (1-64 characters) is the new filer or file server for the volumes metadata. Use the show external-filer command for a list of configured filers.
nfs3 | nfs3tcp | cifs is the protocol for accessing the above filer (NFSv3 over UDP, NFSv3 over TCP, or CIFS). This can be different from the protocol(s) for the managed volume, though you cannot choose a CIFS share for a managed volume in an NFS-only namespace.
path (1-1024 characters) is the path to the back-end filer share, or a CIFS-share name (possibly with a sub-path). Use forward slashes (/) for Unix exports or CIFS shares.
The migration report is named migrate_metadata.nsck-job-id.rpt. Use show reports to list all reports, including this one. To follow the progress of the migration, you can use tail reports report-name follow. For a sample report, see Figure 37.1 on page 37-13.
The metadata share command establishes a metadata share for a managed volume. If you decide later to move the metadata to a new share, you can use this command (nsck ... migrate-metadata) to perform the metadata migration.
bstnA# nsck wwmed migrate-metadata volume /acct target nas3 nfs3 /exports/meta7
bstnA# show reports migrate_metadata.39.rpt
Every ARX volume resides in a volume group, where it shares CPU and memory resources with the other volumes in the same group. Each volume group is a single failure domain, where certain catastrophic failures affect the other volumes in the same group but do not affect any volumes outside the group. As your deployment grows, you may want to redistribute your volumes to mitigate possible down time. Use the nsck migrate-volume command to move a volume from one volume-group to another.
nsck name migrate-volume volname volume-group id [check-limits]
name (1-30 characters) is the name of the namespace.
migrate-volume volname (1-256 characters) is the volume to migrate.
volume-group id chooses the destination volume group. Use the show volume-group command to show all currently-existing volume groups and their volumes. Choose a volume group from the same namespace as the source volume, or choose a new one. This volume group must be able to support the new volume without exceeding any of its licensed limits. To confirm that the migration meets all these criteria, you can use the check-limits option (below).
check-limits verifies that the volume migration is possible without actually migrating the volume. You can use this option to run a test before you perform the migration. This checks the licensed limits at the destination volume group and any other possible obstacles for a successful migration.
Very large volumes may take a long time to migrate. The command returns immediately, providing you with the name of a detailed report. You can continue using the CLI while the migration occurs in the background. The show nsck command shows the current status of the migration, along with the status of all other nsck operations. After the nsck job is complete, the front-end service(s) require a few additional seconds before they allow client access to the volume.
The migration report is named migrate_volume_group.nsck-job-id.rpt. Use show reports to list all reports, including this one. To follow the progress of the migration, you can use tail reports report-name follow. For a sample report, see Figure 37.2 on page 37-15.
bstnA# nsck medarcv migrate-volume /test_results volume-group 3 check-limits
bstnA# nsck medarcv migrate-volume /test_results volume-group 3
migrates medarcv~/test_results to volume group 3. See Figure 37.2 for a sample report. This is a direct volume, so the report does not include any information about metadata.
bstnA# show reports migrate_volume_group.40.rpt
The namespace-check (nsck) utility finds and repairs inconsistencies between a managed volumes metadata and actual files on back-end storage. An nsck rebuild operation deletes all metadata and re-imports all shares. Use the nsck rebuild command to re-initialize all managed volumes in a namespace, or a particular volume.
nsck name rebuild [volume volname] [force]
name (1-30 characters) is the name of the namespace to rebuild. Use the show namespace command to see a list of configured namespaces.
volume volname (optional, 1-256 characters) limits the rebuild to the chosen volume (for example, /home).
force (optional) indicates that you want to force the destage even if another nsck job is currently under way. You can force any nsck job with this option except nsck ... migrate-metadata or nsck ... migrate-volume; you must cancel those jobs explicitly (with cancel migrate-metadata or cancel migrate-volume) before you can rebuild the volume.
You can use the nsck ... report inconsistencies command to check the namespace, volume, or share for inconsistencies without changing any metadata. To attempt to repair inconsistencies, you can use the sync files command to synchronize the metadata with actual files, or the sync directories command to find any new directories and add them to the metadata. If a sync fails, nsck ... rebuild is a last resort. This operation stops all volume processing, rebuilds all metadata, and re-syncs all filer subshares; this causes a complete service interruption.
Each managed volume has a modify flag that you can set with the gbl-ns-vol modify command. This flag, if raised, allows the volume to rename any imported files or directories with the same pathname as previously-imported files. If lowered, such files and directories are not imported and clients cannot write to the volume.
The nsck ... rebuild command lowers this flag for each managed volume that it rebuilds. By default, it keeps the flag lowered after the rebuild is over. This is a safety feature to avoid renamed files when they might not be expected. To allow modifications, you can run the gbl-ns-vol reimport-modify command for each desired volume. This command tells nsck to re-instate the modify flag after the rebuild.
If your volume has tiered shares, where some shares reside on faster and/or more reliable filers than others, we recommend placing all of your master directories onto your Tier 1 shares. Whenever two or more directories have the same name and path, one is considered master and the others are called stripes. The volumes clients cannot access a directory if its master instance is unavailable from the back end, so it is important to keep the masters on reliable filers.
Use a place-rule to select all directories in the volume, place them onto one or more Tier 1 shares, and promote them to master. The rebuild process follows all directory-place rules during the re-import. Additionally, set all of your Tier 1 shares to import priority 1, to force the volume to scan those shares before the lower-priority shares. This ensures that all master directories for the volume are on Tier 1 shares.
The optional force flag is useful for working through a hung nsck job. An nsck job may hang if one of the back-end shares or filers goes offline at the wrong time.
bstnA# nsck ns rebuild
bstnA# nsck archives rebuild force
bstnA# nsck archives rebuild volume /etc
A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. You can use the nsck report dir-structure command to get a report of a volumes directory structure from its metadata. This is faster than the full nsck ... report metadata-only command, and the report provides a quick overview of the volumes directory layout.
nsck name report dir-structure [path] [norecurse] [summary] [outputfile outputfile]
name (1-30 characters) is the namespace on which to report. Use the show namespace command for a list of configured namespaces.
path (optional, 1-256 characters) narrows the scope of the report to a specific virtual path in the namespace (for example, /home/jrandom). If you omit this, the command generates one report per volume.
norecurse (optional) specifies to not recurse into subdirectories during the report. The directory listing therefore only includes the root of the volume, or the path if you chose that option.
summary (optional) removes the table of directories from the report.
outputfile outputfile (optional; 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_dir.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
path - the root of the namespace (all volumes).
outputfile outputfile - dir_structure.nsck-id.rpt. The nsck-id is a unique number assigned to each nsck job.
The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands.
bstnA# nsck medarv report dir-structure /rcrds
bstnA# nsck insur report dir-structure
bstnA# show reports dir_structure.34.rpt
bstnA# show reports dir_structure.43.rpt
A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. If a client has direct access to one of the volumes back-end shares (that is, access that does not go through the volume), the volumes metadata is likely to be inconsistent. Metadata inconsistencies can also occur in a multi-protocol (NFS and CIFS) volume without any client intervention: on a multi-protocol filer, a file or directory name may differ between NFS and CIFS.
Use the nsck report inconsistencies command to find (but not repair) any inconsistencies in a namespaces metadata, or to prove that there are none.
nsck name report inconsistencies [path] [share share-name] [norecurse] [nofilehandles] [multi-protocol] [outputfile outputfile]
name (1-30 characters) is the namespace on which to report. Use the show namespace command for a list of configured namespaces.
path (optional, 1-256 characters) narrows the scope of the report to a specific virtual path in the namespace (for example, /home/jrandom).
share share-name (optional, 1-64 characters) limits the report to a single share in the volume.
norecurse (optional) specifies to not recurse into subdirectories during the report.
nofilehandles (optional) specifies to not validate file handles during the report.
multi-protocol (optional) focuses the report on inconsistencies between NFS names and CIFS names. This only applies to a volume in a multi-protocol (NFS and CIFS) namespace.
outputfile outputfile (optional; 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_inconsistencies.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
path - the root of the namespace (all volumes).
outputfile outputfile - inconsistencies.nsck-id.rpt. The nsck-id is a unique number assigned to each nsck job.
share-name - all shares in the volume.
The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands.
The ARX CLI Maintenance Guide discusses all of these inconsistency types in detail, and describes methods for addressing each inconsistency type.
bstnA# nsck wwmed report inconsistencies
bstnA# nsck medarcv report inconsistencies outputfile medarcv5-6
bstnA# nsck insur report inconsistencies /claims
bstnA# show reports inconsistencies.1.rpt
bstnA# show reports inconsistencies.25.rpt
A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. Use the nsck report metadata-only command to show a namespaces or volumes metadata.
nsck name report metadata-only [path] [share share-name] [norecurse] [outputfile outputfile]
name (1-30 characters) specifies a namespace on which to report. Use the show namespace command for a list of configured namespaces.
path (optional, 1-256 characters) narrows the scope of the report to a specific managed volume or path in the namespace (for example, /eng/share).
share share-name (optional, 1-64 characters) limits the report to a single share in the volume.
norecurse (optional) specifies to not recurse into subdirectories during the report.
outputfile outputfile (optional, 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_inconsistencies.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
path - the root of the namespace (all managed volumes).
share-name - all shares in the volume.
outputfile outputfile - metadata_only
import.share-id.share-name.job-id.rpt
Use the find command to show the physical location of a single file.
The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands.
You can use the nsck ... report dir-structure command for a faster report that focuses on the volumes directory structure.
This identifies the back-end locations of all the volumes files as of now; for file locations in the past, you can use file tracking. This can be useful for finding the correct filer-backup tape for a lost or compromised file.
The file-tracking feature requires some configuration before you can make any file queries. Specifically, a managed volume requires a snapshot rule to regularly copy its configuration and metadata to a file-history archive. After some copies of metadata have been archived, you can use the show file-history virtual-service command to query file locations at different dates.
bstnA# nsck wwmed report metadata-only
bstnA# nsck archives report metadata-only /arch
bstnA# nsck archives report metadata-only /arch share fs6
bstnA# nsck acopia3 report metadata-only outputfile 6-5mdata
bstnA# show reports metadata_only.5.rpt
A managed volumes metadata is its background information about its files and directories, such as their physical locations on back-end filers. The metadata also contains a flag for all NFS symbolic link (symlink) files. A multi-protocol (CIFS and NFS) volume uses this flag to support symlink de referencing for its CIFS clients. Use the nsck report symlinks command to show all of the NFS symlinks that are identified in the current volumes metadata.
nsck name report symlinks [path] [share share-name] [norecurse] [outputfile outputfile]
name (1-30 characters) specifies a namespace on which to report. Use the show namespace command for a list of configured namespaces.
path (optional, 1-256 characters) narrows the scope of the report to a specific managed volume or path in the namespace (for example, /claims/common for the /common directory in the /claims volume).
share share-name (optional, 1-64 characters) limits the report to a single share in the volume.
norecurse (optional) specifies to not recurse into subdirectories during the report.
outputfile outputfile (optional, 1-255 characters) specifies a prefix for a customized file name (for example, jrandom_symlinks.rpt), as opposed to the default. Use the show reports command to display the file in the maintenance directory.
path - the root of the namespace (all managed volumes).
share-name - all shares in the volume.
outputfile outputfile - symlinks
The name of the nsck report appears after you issue the command. Use tail to follow the report as it is written. Use show reports file-name to read the report. You can search through the report with grep. To copy or delete it, use the copy or delete commands.
RF indicates that the symlink resolves to (or points to) a file.
RD shows that the symlink resolves to a directory.
RS means that the symlink resolves to another symlink.
RX indicates a symlink error: the symlink points to a non-existent file or directory.
ER indicates an error in querying the filer for symlink information. The report includes specific error information in parentheses.
The NL condition is typically transitory: it indicates that the nsck software is currently unable to get a lock on the parent directory for the given file or directory. This typically indicates high client activity (such as file creates and deletes) in the parent directory, which may lead to temporarily-inaccurate metadata readings in the report. The volume updates its metadata as soon as it is able to get the lock.
bstnA# nsck insur report symlinks outputfile insur_symlinks
bstnA# show reports insur_symlinks._claims.rpt
nsck namespace sync directories dir-path [share share-name]
namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces.
dir-path (1-256 characters) narrows the scope of the sync operation to a specific managed volume and path (for example, /vol/var/log). The path must describe a valid volume in the namespace, or one of its subdirectories. Use forward slashes (/) for NFS or CIFS paths.
share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume.
share share-name is unspecified, so all shares in the volume are synchronized and repaired.
This invokes the same software used by the sync directories command. Follow the Guidelines for that command.
bstnA# nsck medarcv sync directories /lab_equipment path /
If a file changes on a back-end filer without the managed volumes awareness, the volume metadata is inconsistent for that file. Use the nsck ... sync files command to report on metadata inconsistencies and repair them. This is equivalent to the sync files command.
nsck namespace sync files dir-path [share share-name] [recurse] [rename-files]
namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces.
dir-path (1-256 characters) narrows the scope of the sync operation to a specific managed volume and path (for example, /vol/var/log). The path must describe a valid volume in the namespace, or one of its subdirectories. Use forward slashes (/) for NFS or CIFS paths.
share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume.
recurse (optional) causes the sync operation to descend into subdirectories.
rename-files (optional) determines that, if a file-collision is discovered, the sync operation can rename the newly-discovered file. All collisions and renames are included in the sync report.
recurse is off; the sync only examines the dir-path without descending into any child directories.
rename-files is off; collisions are noted in the sync report, and the metadata is not repaired.
share share-name is unspecified, so all shares in the volume are synchronized and repaired.
This invokes the same software used by the sync files command. Follow the Guidelines for that command.
bstnA# nsck wwmed sync files /acct recurse
Use the show nsck command to show the current state of all nsck report, nsck rebuild, and sync operations.
show nsck [nsck-id | namespace name | all]
nsck-id (optional) identifies one nsck or sync job to show. The job ID appears if you run show nsck without any options.
name (optional, 1-30 characters) shows the nsck and/or sync job(s) in one namespace.
all (optional) shows a detailed view of all nsck and sync jobs.
The show nsck command shows the operation ID (Op ID), the type of operation (Op Type), the namespace and path where the operation is running, and the current Status of the operation. Possible status lines appear below.
The show nsck all and show nsck nsck-id commands add detail to the output, including the name of the job report and the switch where the report resides. The latter is useful in redundant pairs, where a report could be generated on either peer.
Use the clear nsck command to clear one nsck job (or all nsck jobs). The clear sync command clears sync jobs.
Complete indicates a successful nsck operation.
Pending shows that the nsck operation is starting.
Rebuild in progress shows that the nsck operation is rebuilding a namespace or managed volume (nsck ... rebuild).
Destage in progress appears for the nsck ... destage command.
Report in progress indicates that the nsck job is writing a report, such as an inconsistencies report (nsck ... report inconsistencies) or metadata report (nsck ... report metadata-only).
Cancelled means that someone stopped the nsck operation.
Migrate in progress (x%) indicates that someone is migrating a managed-volumes metadata from one metadata share to another. The percentage shows the progress of the migration.
Cancel in progress appears if someone stopped the metadata migration.
Synchronizing appears for the sync files command.
Canceling appears if someone stopped the synchronization job with the cancel sync command.
Error: Path not found - A virtual tree has a file or directory that is missing from its physical counterpart.
Error: Out of memory - The namespace software ran out of memory during the nsck operation.
Error: Temporary database - The namespace software encountered an error creating, opening, or deleting a temporary database.
Error: Resolving database entry - An error occurred while resolving an entry in the operations temporary database.
Error: Bad storage type - The namespace software could not determine whether a file-system entry was a file or a directory.
Error: Attributes not found - The namespace software failed to access file attributes from one of the back-end-directory trees.
Error: Incomplete - The switch rebooted before the nsck job was finished.
Error: Incomplete at force time - An nsck ... rebuild force interrupted the nsck job.
Error: Bad report type specified - The user specified an invalid report name in the nsck command.
Error: Migration failed - The metadata migration failed. All metadata still resides on its original share. You can use the nsck ... migrate-metadata command to invoke a metadata migration.
Error: Unable to open report - This is an internal error. Contact customer support.
bstnA# show nsck
bstnA# show nsck namespace medarcv
bstnA# show nsck 1
bstnA# show nsck
bstnA# show nsck namespace medarcv
bstnA# show nsck 1
Use the show sync command to show the results of all sync operations.
show sync {files | directories} namespace volume vol-path
show sync {files | directories} namespace volume vol-path path path
files | directories is a required choice. This selects the type of sync operation to show.
namespace (optional, 1-30 characters) is the name of a namespace. Use show namespace for a list of all configured namespaces. If you omit this (and all other options), the output includes all recorded sync-files or sync-directories operations.
vol-path (optional, 1-1024 characters) focuses on a particular volume. Use forward slashes (/) for all volumes, including CIFS.
path (optional, 1-1024 characters) narrows the focus further, to a particular path within the volume. As with volumes, use forward slashes in all paths.
Namespace is a namespace where at least one sync operation occurred.
Volume is one volume where someone invoked a sync.
Path is the path where a sync operation occurred. This contains details about the operation:
Options are recurse and/or rename-files. This does not appear unless the user selected one of these options. They are options in the sync files command only.
Type appears only for auto-sync operations. An auto-sync occurs only in a volume that is enabled to run them with auto sync files. A client triggers an auto-sync operation by getting an error that indicates metadata inconsistency. The value for this field is Automatic.
Status is Pending, Syncronizing, Pending Cancel, Canceling, Success, or Failed. A typical sync operation goes from Pending to Syncronizing to Success. Use the cancel sync command to cancel the sync operation. For details on the sync operations progress, you can look at the sync report, described below.
Report Name is the name of a detailed report about the sync operation. You can use the show reports command to view the report.
Share only appears if the share was specified (see the documentation for sync files or sync directories).
Lost Items are the files or directories that were recorded in metadata but are missing from the back-end filer.
Found Items are the reverse: these were found on the filer and needed to be added to the metadata.
Synchronized Items is the total repaired files and directories. Ideally, this should be the sum of the lost and found items above.
Processed Items is the total number of files and directories processed.
This output grows with every run of the sync files or sync directories command. Use clear sync to clear all sync operations from this output (without deleting any of the detailed sync reports; use delete reports to remove those).
bstnA# show sync files
bstnA# show sync directories
bstnA# show sync files medarcv volume /rcrds
bstnA# show sync files
bstnA# show sync directories
bstnA# show sync files medarcv volume /rcrds
sync directories namespace volume volume path path [share share-name]
namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces.
volume (1-1024 characters) specifies the namespace volume. All of the namespaces volumes appear in the show namespace output.
path (1-1024 characters) chooses a specific directory in the volume (for example, var/log). The sync operation looks for new directories under this path; it does not descend into any already-known subdirectories. This path is relative to the volume root, above. Use forward slashes (/) for NFS or CIFS paths.
share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume.
To find all new directories where they exist, use nsck ... report inconsistencies. This command, sync directories, finds all new subdirectories under a known directory.
Each sync operation generates a report named sync.sync-job-id.volume.rpt, shown after you issue the command. Use show reports to list all reports, including this sync report. To follow the progress of the sync operation, you can use tail reports report-name follow.
If the sync/repair fails, use the nsck ... rebuild command to rebuild the volume (drop all volume metadata and re-import all back-end shares).
The sync directories command uses the share priority set by the import priority command. That is, if two or more shares have the synchronized directory, and no other instance of that directory is already imported, the import priority determines which share has the master instance of the directory. Whenever there are two or more instances of a volume directory on the volumes back-end shares, one of them is master and the rest are called stripes. The stripe directory conforms to the attributes of the master.
bstnA# sync directories medarcv volume /lab_equipment path /acme share leased
bstnA# show reports sync.4._lab_equipment.rpt
If a file changes on a back-end filer without the managed volumes awareness, the volume metadata is inconsistent for that file. Use the sync files command to report on metadata inconsistencies and repair them.
sync files namespace volume volume path path [share share-name] [recurse] [rename-files]
namespace (1-30 characters) specifies the namespace to sync. Use the show namespace command for a list of configured namespaces.
volume (1-1024 characters) specifies the managed volume. All of the namespaces volumes appear in the show namespace output.
path (1-1024 characters) narrows the scope of the repair to a specific path in the volume (for example, var/log). This path is relative to the volume root, above. Use forward slashes (/) for NFS or CIFS paths.
share share-name (optional, 1-64 characters) limits the sync and repair to a single share in the volume.
recurse causes the sync operation to descend into subdirectories.
rename-files determines that, if a file-collision is discovered, the sync operation can rename the newly-discovered file. All collisions and renames are included in the sync report, described below.
recurse is off; the sync only examines the dir-path without descending into any child directories.
rename-files is off; collisions are noted in the sync report, and the metadata is not repaired.
Each sync operation generates a report named sync.sync-job-id.volume.rpt, shown after you issue the command. Use show reports to list all reports, including this sync report. To follow the progress of the sync operation, you can use tail reports report-name follow.
If the sync/repair fails, use the nsck ... rebuild command to rebuild the managed volume (drop all volume metadata and re-import all back-end shares).
SC indicates that a previously unsynchronized directory was successfully synchronized by this command. The managed-volume software does this in the background, so it is rare to see this in the report for a manual sync operation.
SI indicates that the sync operation attempted to sync a directorys attributes, and the directory-attribute synchronization failed. This indicates that one of the managed volumes shares is out of space. You can use show namespace to find the full share. You can access the filer directly to add more space, or use a place-rule with a source share to drain some files off of the full share. Then the managed-volume software synchronizes the directory attributes in the background, and this condition clears.
The sync files command uses the share priority set by the import priority command. That is, if two or more shares have the same file at the same path, and no other instance of that file is already imported, the share with the better import priority wins the master instance of the file. The volume renames the other file(s) or fails the sync operation, as determined by the rename-files flag.
bstnA# sync files wwmed volume /acct path /
bstnA# sync files wwmed volume /acct path /jsmith recurse
bstnA# sync files medarcv volume /rcrds path / recurse rename-files
recursively repairs the root directory (/) in a CIFS volume, medarcv~/rcrds. Figure 37.16 on page 37-48 shows a sample report, where a missing file, /copyRandomx.exe, was found and synchronized. Two additional files were also newly-discovered and synchronized.
bstnA# show reports sync.3._rcrds.rpt
A subshare is a CIFS share (along with its ACL) that is nested under an imported CIFS share. Use the sync subshares from namespace command to discover all of the CIFS subshares behind a managed volume and then share them from a front-end service. This synchronizes the CIFS subshares between back-end filers and the front-end service.
sync subshares from-namespace ns volume vol to-service fqdn
[expose-hidden] [tentative]
ns (1-30 characters) is the namespace for the sync operation. The namespace must support CIFS.
vol (1-1024 characters) specifies a managed volume with subshares. This command finds all CIFS subshares in all of the back-end shares behind this volume. It also replicates any subshares that are not already identical on those back-end shares. The command replicates the subshare name, directory path (relative to the share root), and ACL on each back-end filer that needs it.
fqdn (1-255 characters) is the target CIFS service to export all of the subshares found in the above volume.
expose-hidden (optional) causes the command to use a different front-end name for any subshares that are hidden on their back-end filers. A CIFS share is hidden from Windows-network views by adding a dollar-sign ($) to the end of the share name (for example, mybooks$). This option causes the operation to use an exposed front-end subshare for all such hidden subshares, without the dollar suffix (mybooks). Clients of the CIFS service can therefore see the shares.
tentative (optional) finds all of the subshares behind the volume and prints them in a report, but does not share them from the CIFS service.
You can configure a managed volume so that it passes a client connection from a front-end subshare directly to the back-end subshare, thereby allowing the filer to enforce its subshare ACLs. Use the gbl-ns-vol filer-subshares command to prepare a CIFS volume for subshare support, and then use this command to share all filer subshares out through a front-end CIFS service. (You can also use the export (gbl-cifs) ... filer-subshare command to share out a single subshare at a time.)
This command replicates all subshares, so that they have the same share names, ACLs, and directory names on all of the volumes shares. The subshare-replication process creates a sync report with the results. The name of the report appears after you issue the command. Use show reports report-name to see it.
If the volume is backed by any NetApp filers or EMC servers and you plan to support free-space quotas on them (see freespace cifs-quota), prepare the subshares directly on the filer before you invoke this command. The subshare-replication process does not create NetApp qtrees or EMC quota trees, and those special directories are required to support free-space quotas. Before you run subshare replication with this command, access the filers directly and
See the Guidelines: Subshare Replication with Free-Space Quotas section of the filer-subshares documentation. Then invoke this command to synchronize their share-level ACLs and other attributes.
The volume cannot use a native subshare name if any other CIFS share on the back-end filer is already using that name. This is called a subshare-name collision. For subshare-name collisions, the managed volume names the subshare with the following syntax:
_acopia_subshare_id$
subshare is the native name of the original subshare.
id is unique integer to identify the subshare. This is unique for every subshare behind the ARX and its redundant peer.
To prevent any such generated names on a volumes filers, you can use the native-names-only option in the filer-subshares command. The native-names-only option causes subshare replication to fail.
If this replication process fails for any subshare, the front-end subshare is degraded: clients cannot access the files in the unsynchronized back-end subshare(s). The show cifs-service all command shows the current status of the subshare-replication process, and whether or not any subshare is degraded. You can use this commands sync report to understand the problem, resolve the problem at the filer, and then use sync subshares from-service to re-run the subshare replication.
bstnA# sync subshares from-namespace medarcv volume /rcrds to-service ac1.medarch.org expose-hidden
export (gbl-cifs) ... filer-subshare
bstnA# show reports syncSshrVolToService_20100706010239.rpt
A subshare is a CIFS share (along with its ACL) that is nested under an imported CIFS share. Use the sync subshares from-service command to send CIFS subshares from a front-end CIFS service to all of the filers behind it. This is useful for repairing a degraded subshare.
sync subshares from-service fqdn to-namespace ns volume vol
[tentative]
fqdn (1-255 characters) is the FQDN for a CIFS service with subshares. Use the show cifs-service subshares all command for a complete list of CIFS services with subshares.
ns (1-30 characters) is the namespace behind the above service.
vol (1-1024 characters) is a particular managed volume with subshares. If the CIFS service exports any subshares from this volume, this command replicates the subshare definitions at all filers behind the volume.
tentative (optional) prints a report about all of the changes the command would make, but does not replicate any subshare information from filer to filer.
This operation is only effective in volumes that support CIFS and filer subshares. When you configure subshare support at the volume (with filer-subshares) and the volumes front-end export (with export (gbl-cifs) ... filer-subshare), a client that connects to the front-end subshare passes through the volume to the back-end subshare, so that the back-end filer can impose its subshare ACL. Without subshare support, a client that connects to a front-end subshare is passed through to the root of the back-end share, and the filer uses the root shares ACL.
You can use this command, sync subshares from-service, to correct a possible problem with subshares. When you first enable a managed volume with subshare support, it discovers and replicates all of the subshares on its back-end shares. After you export a subshare through a front-end service at some fqdn, the show cifs-service fqdn command indicates whether or not this subshare-replication process succeeded. If the subshare is degraded, you can get a detailed report about the problem by running this sync command with its tentative flag. Then you can correct the problem at the back-end filers and run this sync command again, this time without the tentative flag, to retry the replication.
To export subshares that are currently defined at the back-end filers, use the sync subshares from-namespace command. This is the reverse of the current command; it sends subshare definitions from the back-end filers to the front-end service.
If the volume is backed by any NetApp filers or EMC servers and you plan to support free-space quotas on them (see freespace cifs-quota), prepare the subshares directly on the filer before you invoke this command. The subshare-replication process does not create NetApp qtrees or EMC quota trees, and those special directories are required to support free-space quotas. Before you run subshare replication with this command, access the filers directly and
See the Guidelines: Subshare Replication with Free-Space Quotas section of the filer-subshares documentation. Then invoke this command to synchronize their share-level ACLs and other attributes.
The volume cannot use a native subshare name if any other CIFS share on the target filer is already using that name. This is called a subshare-name collision. For subshare-name collisions, the managed volume names the subshare with the following syntax:
_acopia_subshare_id$
subshare is the native name of the original subshare.
id is unique integer to identify the subshare. This is unique for every subshare behind the ARX and its redundant peer.
newptA# sync subshares from-service provmed.MEDARCH.ORG to-namespace provMed volume /mds tentative
export (gbl-cifs) ... filer-subshare
newptA# show reports syncSshrServToVolume_201110030248.rpt
Use the wait-for nsck command to wait for an nsck operation to complete.
wait-for nsck namespace [vol-path] [timeout timeout]
namespace (1-30 characters) is the name of a namespace.
vol-path (optional, 1-4096 characters) identifies a particular managed volume in the namespace.
timeout (optional, 1-2096) is the timeout value, specified in seconds. If this timer expires before the nsck operation completes, the command exits with a warning.
timeout - 0 (zero, meaning wait indefinitely)
The wait-for nsck command waits for an nsck operation on a specified namespace or volume to complete.
To interrupt the wait-for nsck command before the nsck operation completes, press <Ctrl-C>.
If the command is waiting for nsck ... rebuild, it exits after the volume(s) are destaged and have started importing files and directories from back-end shares. This command only waits until clients have full access to their files, not until import is complete.
bstnA(gbl-ns[medarcv])# wait-for nsck medarcv timeout 60
Use the wait-for sync command to block the CLI until one or more sync operations completes.
wait-for sync {files | directories} namespace [timeout timeout]
wait-for sync {files | directories} namespace volume vol-path [timeout timeout]
wait-for sync {files | directories} namespace volume vol-path path path [timeout timeout]
files | directories is a required choice. This selects the type of sync operation to await.
The namespace, vol-path, and path arguments mimic the ones used in the sync files or sync directories command. These identify one or more sync operations; if you omit all of them, the command waits for all sync-files or sync-directories operations on the switch.
namespace (1-30 characters) specifies a namespace where one or more sync operations are occurring.
vol-path (optional, 1-1024 characters) specifies a volume. Use forward slashes (/) for all volumes, including CIFS.
path (optional, 1-1024 characters) identifies a particular path that is being synchronized. As with volumes, use forward slashes in all paths.
timeout (optional, 1-2096) is the timeout value, specified in seconds. If this timer expires before the sync operation completes, the command exits with a warning.
timeout - 0 (zero, meaning wait indefinitely)
The wait-for sync command waits for a specified sync operation to complete.
To interrupt the wait-for sync command, press <Ctrl-C>. Use cancel sync to cancel the sync operation altogether. The show sync command shows all sync-files or sync-directories operations.
bstnA# wait-for sync files timeout 60
bstnA(gbl-ns[medarcv])# wait-for sync directories medarcv timeout 300
bstnA> wait-for sync files wwmed timeout 120
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)