Installation guide

Acopia Networks, Inc.
NSCK and Sync-Files
Problem Description
NSCK reports do not identify
“marked” multi-protocol
directories where you should run
a sync files operation. (23891)
Some multi-protocol (NFS and CIFS) directories are “marked” for
special processing. These directories contain files and/or subdirectories
one of these naming issues:
• the name resembles a Filer-Generated Name (FGN, such as
“myfile~1.txt”), or
• the name produces an FGN on its back-end filers (such as
“my:file.txt,” or “MYFILE” in the same directory as “myfile”).
If a directory is marked with one of these naming issues, the volume
performs extra processing whenever a client tries to introduce an entry
with the other naming issue. Depending on the outcome of the
processing, the new client entry could become NFS-only (inaccessible
to CIFS clients). Refer to the CLI Maintenance Guide for details.
Clients can resolve these issues by accessing the volume through its
VIP and renaming the directory’s entries. However, the directory mark
persists after all of its child entries have been correctly renamed; you
use the sync files CLI command to remove the mark.
The issue is that there are no reports that identify a directory as
“marked” after its entries have been correctly renamed.
Workaround: Use sync files to clear the directory mark immediately
after renaming its entries.
Under rare circumstances, an
nsck … rebuild on a shadow
volume can make the volume
stall in “importing” state.
(18135)
If a shadow volume meets all of the following criteria when someone
issues an nsck … rebuild, the shadow volume stays in “importing”
state for a long time (perhaps hours), and is inaccessible to clients:
• The shadow-copy-rule has its publish command set to group (the
default),
• The source volume contains millions of files,
• The shadow-copy rule was near the end of a run, so most of the
files were copied into the shadow volume’s staging area (the
hidden .acopia_shadow directory in the root of each share).
The root of the problem is that the .acopia_shadow directories contain
millions of files, and the nsck … rebuild must remove those
directories at the beginning of its process. Clients cannot access the
volume until all the filers are able to delete this directory.
If this occurs, messages appear in the syslog that describe the problem.
17