I am working with a Raidzone tech to solve a problem with our Raidzone NAS. The tech told me he has not yet posted to any Samba list about this, and gave me permission to do so. Using XCOPY from either NT4SP6a or W2KSP3, over varying network paths, a file of 18,490,235K-1 bytes or smaller will copy to the NAS successfully in about 45 minutes, but a file of 18,490,256K-1 bytes or larger will fail. The failure occurs in about 7 minutes with a message on the Windows computer of either "end of file reached" (on NT) or "network path no longer available" (on W2K.) When a copy fails, /var/log/samba/log.<clientname> on the NAS contains messages about "no response to oplock break request". During the trials which fail, it seems that no data flows; the lights on the switch show no traffic, the drives on the Windows computer sending the file are not accessed, and the LCD display on the NAS shows only minimal dataflow. We could probably narrow the threshold window further, but have not done it yet. Setting oplock break wait time = 100 had no perceivable effect. Disabling oplocks completely resulted in the XCOPY failing with a sharing violation message on the NT box. (We did not try this variation on W2K.) The NAS appears to be running Linux kernel 2.4.18. I found nothing about this in open web searching. I looked through the archives of this list and saw that oplock messages are often attributed to network problems, but if that is the case here, then I wonder why there seems to be a file size threshold involved. I also saw that someone reported a similar situation with files of ~25GB, but there did not seem to be any replies. I am hoping the file size threshold I have described above may give someone an insight about the situation, or that there may be suggestions for specific areas for the Raidzone tech and I to investigate. Finally, I am new to Samba and this list, so I apologize for any ignorance on my part. Thank you. -Eric Regards, Eric Moyer (EMoyer@LibraryTech.com) Library Technologies, Inc. 2300 Computer Avenue, Suite D-19 Willow Grove, PA 19090 Phone 215-830-9320, FAX 215-830-9422
On Wed, Jun 25, 2003 at 10:54:44AM -0400, Eric N. Moyer wrote:> I am working with a Raidzone tech to solve a problem with our Raidzone > NAS. The tech told me he has not yet posted to any Samba list about this, > and gave me permission to do so. > > Using XCOPY from either NT4SP6a or W2KSP3, over varying network paths, a > file of 18,490,235K-1 bytes or smaller will copy to the NAS successfully in > about 45 minutes, but a file of 18,490,256K-1 bytes or larger will > fail. The failure occurs in about 7 minutes with a message on the Windows > computer of either "end of file reached" (on NT) or "network path no longer > available" (on W2K.) When a copy fails, /var/log/samba/log.<clientname> on > the NAS contains messages about "no response to oplock break request". > > During the trials which fail, it seems that no data flows; the lights on > the switch show no traffic, the drives on the Windows computer sending the > file are not accessed, and the LCD display on the NAS shows only minimal > dataflow. > > We could probably narrow the threshold window further, but have not done it > yet. > > Setting oplock break wait time = 100 had no perceivable effect. Disabling > oplocks completely resulted in the XCOPY failing with a sharing violation > message on the NT box. (We did not try this variation on W2K.) > > The NAS appears to be running Linux kernel 2.4.18.Interesting. I always wondered what version of Samba the RAIDZONE people are running. They haven't asked to be put on our vendors list to my knowledge. The version of Samba they are running is far more important. Ask them for the source code to see if any changes have been made or if it's a standard version and if so what version it is. oplock break failures are commonly due to network hardware problems or sometimes client bugs. All of the known Samba bugs here have been fixed to my knowledge. Jeremy.
> >Interesting. I always wondered what version of Samba the RAIDZONE >people are running. They haven't asked to be put on our vendors >list to my knowledge. The version of Samba they are running is >far more important. Ask them for the source code to see if any >changes have been made or if it's a standard version and if so >what version it is. > >oplock break failures are commonly due to network hardware problems >or sometimes client bugs. All of the known Samba bugs here have >been fixed to my knowledge. > >Jeremy.Thank you for the reply. I have asked the Raidzone tech for a copy of their Samba source, and we are also investigating network issues. Another thing we are doing is testing the large file copies on a spare Linux system, for comparison to the Raidzone unit. This test computer started off with Samba 2.2.1a-4, and copied a large file fine, and much faster than the rate we get on the Raidzone when it works. We then updated the test machine to Samba 2.2.8a-1, and it took 50% longer to copy the file. Is a performance decrease like this a common experience with the newer versions? Are there some customary settings we should check? Thanks. -Eric Regards, Eric Moyer (EMoyer@LibraryTech.com) Library Technologies, Inc. 2300 Computer Avenue, Suite D-19 Willow Grove, PA 19090 Phone 215-830-9320, FAX 215-830-9422