e i g h t - c u b e d . c o m 

Polling Samba

A while ago, I was on contract for my now current employer. They wanted me to port all the functionality of their application from OpenVMS on Alpha to OpenVMS on IA64. As part of the port, we had to switch from Advanced Server (Pathworks) to Samba on IA64.

I set up the Samba shares for them and ensured it worked in testing, but by the time my contract ended, the switch still hadn't been made, and was not made until about 4 months later.

Now I find myself looking at a machine that's completely CPU bound dealing with Samba polls from the Windows Server world out there.

Looking at the scripts that run in Windows land, we find that the majority of them are something like:

if exist \\sambaserver\somedir\*.txt copy \\sambaserver\somedir\*.txt c:/somewhere/

Now, let's think about what this does. The script asks the Samba server to connect to a share point and determine if a file is present, and copy it locally if so. Simple, right? But what's happening on the (OpenVMS based) Samba server?

Well, Samba connections are created in response to the client opening a port (139 or 445). That is, there is no persistant server like Advanced Server. Each time you connect to a Samba share, OpenVMS created a new process. Now, Samba is tries to be smart, and assumes that the connection will be around for a while. So it goes and reads INDEXF.SYS for the directory you connected to so as to cache file information such as the create date and size of the file (which Windows expects each time you do a directory lookup). Unfortunately, the way the script is connecting, if there are no files to process (or even if there are) this action is a complete waste of CPU time and I/O as the share is disconnected at the end of the script.

The appropriate way to do this is to connect the server/directory combination as a network drive and then refer to the local drive letter in the script. Assuming the server/directory is mapped to drive N:, the script then becomes:

if exist n:/*.txt copy n:/*.txt c:/somewhere/

By asking the Windows admins to change to this method, I've gone from a machine that was peaking at 100% CPU to one that's now peaking at 50% CPU. A good win for just "doing it right".