0 Replies Latest reply: Jun 18, 2013 3:49 PM by 1f081361-2603-4589-b1c8-864c1aaf8620 RSS



      I apologize for this being sort of a mixed-experience question as it relates to SMB and usage with Windows; but here goes...


      I am currently migrating from an Isilon storage cluster to Solaris running ZFS and samba.  We have a Windows based sync service which monitors file changes via ReadDirectoryChangesW on various locations in the existing cluster.  The Isilon supports such notifications sent over CIFS to the monitoring service.  And all is fine with that configuration.  But, when we initially ran this service against the Solaris host, we got no change results.  I built a quick and dirty version using .Net System.IO.FileSystemWatcher (FSW) which simply monitors a path and writes change event details to a console for further investigation in such a setup.  When it is run, if I make a single change behind the path being monitored on the Solaris host, then the FSW app complains with the all-too-common "too many changes at once."  This typically only occurs when the FILE_NOTIFY_INFORMATION buffer size is too small to hold the size of the data for the population of entries returned (ie. we typically see 500-800 FILE_NOTIFY_INFORMATION entries per ReadDirectoryChangesW call return).  The maximum limit for this buffer when used over the network is 64K.  The buffer is currently set to the maximum value, and the approximate size of the FILE_NOTIFY_INFORMATION required for the single change I am making is only about 100 bytes.


      So my question is, does anyone know if Solaris supports this feature for it's Samba implementation?  Because with FSW it acts like it wants to - as I get that error on-time consistently with any file modification.  However, the only result I actually get is the error itself; as if the buffer is being flooded for a simple single file change.  Has anyone else run into this problem or know of a workaround/solution to what we are seeing?



      - drew