Acopia Adaptive Resource Switch, Руководство по обслуживанию CLI

Страница: 267 / 324

Troubleshooting Managed Volumes
Finding NFS-Only Entries in a Multi-Protocol Volume
CLI Maintenance Guide 8-61
Finding NFS-Only Entries in a Multi-Protocol
Volume
This section applies to volumes in a multi-protocol (CIFS and NFS) namespace only,
where the CIFS name and the NFS name for a file may differ.
Some file/directory names are legal in NFS but illegal in CIFS, or are legal in CIFS
but illegal in NFS. Most multi-protocol filers use the original name for the clients of
one protocol, then create a new filer-generated name (FGN) for the clients of the other
protocol. The ARX aggregates the naming solutions from several multi-protocol
vendors, each following a different standard for FGNs. Every file or directory must
have an NFS-side name that matches its CIFS-side name
on every share , or it is
marked as NFS-only .
Best Practice: Avoid NFS-Only Entries Where Practical
CIFS clients cannot access an NFS-only entry. This is especially a problem for
directories, which obscure all of their contents including all child directories.
Performance Issues
NFS-only entries, under rare circumstances, can also impede volume performance.
The volume does not record any FGNs from its filers because the memory cost would
be prohibitive; 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”).
A directory with any NFS-only entries is certain to have at least one FGN on its filers.
If a client creates a name there that might match an FGN pattern (such as
“myfile~1.doc” or “dir~1”), the volume first probes all its back-end shares to verify
that the FGN is not already taken. If the FGN is taken, the client’s new file is marked
“NFS-only.”