Files Copied to ExtremeZ-IP Volumes from Windows users are not seen by Macintosh Clients

1 Star2 Stars3 Stars4 Stars5 Stars
Loading...
  • Product:
    ExtremeZ-IP
  • Version:
    3.2x13-current
  • Document Type:
    Info
  • Revised:
    4/28/2006
  • Reviewed:
    4/28/2006

Summary:

This article discusses a problem that can cause files to be temporarily unavailable from Mac clients under certain circumstances. Primarily this problem can occur when there is heavy file system activity on the ExtremeZ-IP server itself, unrelated to access from Mac clients. As of ExtremeZ-IP 3.2, the potential for the problem has been diminished, and there is also a registry option to optimize ExtremeZ-IP for high-volume servers that may still encounter the situation with the default settings.

In this article, “notifications” are message sent from the operating system (Windows) to ExtremeZ-IP concerning file/folder changes made to ExtremeZ-IP volumes. The way this works is the following:

ExtremeZ-IP will make a call to the operating system asking what changes Windows users have made to a particular volume. ExtremeZ-IP knows what all the Macintosh changes are because ExtremeZ-IP is performing those changes itself. The call made to the operating system requires a buffer be passed to the operating system. The operating system places all of the changes into the buffer for ExtremeZ-IP to read.

The problem that occurs is the amount of space needed to fit all of the notifications is much larger than the buffer passed to the operating system. The result is missed notifications.

Description:

Rectifying the Problem:
There are two options to fixing this problem. Increase the buffer size for all of the volumes ExtremeZ-IP shares, or increase the buffer on the affected volumes only (recommended).

Option 1:
Add into the registry location:
Version 3:
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ExtremeZ-IP\Parameters\
Version 4:
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ExtremeZ-IP\Parameters4\NonRefreshable\


DWORD Value
NotificationBuffer 512

Option 2 (recommended):
Add volume specific changes into the registry areas above:


DWORD Value
(volume name)_NotificationBuffer 512

Example: The volume name is Test, so the DWORD would be Test_NotificationBuffer. Do this for all of the volumes that are affected by the copy.

For these keys to work the server must to stopped and restarted. They are not refreshable. If the problem persists after increasing the buffer size, contact Group Logic Support.

Additional Information:
Buffer size verses previous versions:
The buffer size previous to 3.2×13 was 128K, the default in 3.2×13 is 256K. This means ExtremeZ-IP is using 2x more notification buffer memory per volume in 3.2×13. Most users will not have a problem with this increase. However if the ExtremeZ-IP process is using near 2GB of memory usage or using the 3GB switch, users may want to revert to 128K as long as they are not encountering the problem.

Possible reason for missed notifications:
Running other CPU intensive software on the same machine as ExtremeZ-IP, may cause notifications to be missed. As the user increases the number of applications on the server, the less time each application will get access to the CPU. Because the amount of time between ExtremeZ-IP directory change requests increases, the more likely it will miss notifications.

For example, a client is copying files from one Windows server to the ExtremeZ-IP server as a constant rate. On average the size of the buffer required to fit all of the notifications every 500milliseconds is 200K. ExtremeZ-IP asks approximately every 500milliseconds (in this example) with a buffer size of 256K. The client decides to also run SQL server and data replication software on the ExtremeZ-IP server. Because all 3 applications need time on the CPU and of the operating system ExtremeZ-IP now asks approximately every 750milliseconds. So the average buffer size required is 300K, notifications are now being missed.

Workaround:
If increasing the size of the buffer is not possible there is a workaround that may help.

Rather than copying the files/folders to the ExtremeZ-IP volume, to move them. For example, if the client is copying files/folders from server 1 to the ExtremeZ-IP server (server 2) have them adjust the workflow so the files are copied to a temporary folder on server 2 (not shared with ExtremeZ-IP). This folder must be on the same physical drive as the ExtremeZ-IP destination folder, and would be helpful if it was also the same logical drive. Then move the contents from the temporary folder to ExtremeZ-IP. As far as performance, the move is usually instantaneous, so the timing on a particular workflow should be unaffected.

The reason this workaround will help is: If a folder with 500 files is copied from folder A to folder B; 500 notifications are sent. If a folder with 500 files is moved from folder A to folder B; 1 notification is sent. ExtremeZ-IP then recurses through the folder adding the children manually.

Tags: