Finding Nfs-Only Entries In A Multi-Protocol Volume; Best Practice: Avoid Nfs-Only Entries Where Practical; Performance Issues - Acopia Adaptive Resource Switch Cli Maintenance Manual

Finding NFS-Only Entries in a Multi-Protocol
Volume

Best Practice: Avoid NFS-Only Entries Where Practical

CLI Maintenance Guide
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.
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."
Troubleshooting Managed Volumes

Finding NFS-Only Entries in a Multi-Protocol Volume

8-61