NAS 2000s Release Notes

NAS 2000s Release Notes 5
2. For asynchronous writes: Although Server for NFS informs
the NFS client that the data has been safely written to disk,
the data is still stored in cache, and is waiting to be written to
disk. This might cause file corruption issues if, for example,
you lose your power supply to the Server for NFS server
while data is still in the cache. At this point, the NFS client
assumes that data that was lost was actually safely written to
disk.
3. With synchronous writes on (caching off), all write requests
are immediately committed to disk before a response is sent.
Although synchronous writes “on” does frequently slow NFS
file writes, it does improve the stability and data integrity.
WARNING: Turn asynchronous writes on only if you are
willing to risk file corruption if any issue with the Services for
UNIX server causes the cache to be lost (for example, if the
system shuts down, stops responding, loses its power supply,
or experiences other serious issues).
Clearing the NFS log via the WebUI causes the log file
to become inaccessible.
When clearing the NFS logs via the WebUI, the log file will clear
but the file permissions are set incorrectly. Access to the log
c:\msnfs\logs with Windows Explorer will be denied. To
resolve the issue, stop the Server for NFS service, then clear the
NFS log, then start the Server for NFS service. The log file will
then be accessible.
NFS administrative shares support
SFU does not work with administrative shares in the same fashion
as CIFS. By default, a volume drive such as C: is CIFS shared as
C$. This is an example of an administrative share and is hidden to
CIFS clients. If an NFS share is created and named driveS, as in
the example, the share will not be hidden to NFS clients. This
NFS share will act as a normal NFS share.