I've seen this problem often, but it's not a filer problem where I've seen it -- it's a duplex negotiation problem on the switch the laptop is plugged in to. For some reason it affects XL save times more than many other apps.
Check to see if the user played with the duplex settings on the laptop NIC and/or if the port on the switch is hard-coded to 100/full with the laptop set to "auto negotiate". Remember that some PCcard NICs cannot go to full duplex in win2k and many do not auto-negotiate port speed very well.
mjb
----- Original Message ----- From: "Brian Tao" taob@risc.org To: toasters@mathworks.com Sent: Tuesday, August 21, 2001 5:56 AM Subject: Write timeouts to CIFS share, oplock problem?
Is this type of problem (Windows applications hanging whentrying to write out files, or the file being saved is mysteriously deleted from the filesystem) indicative of oplock issues between a Windows client and a filer? I have a few things to look at on the Netapp side, but I want to make sure there isn't some other easy explanation for this.
Client is running W2K from a laptop on a 100t port. Filer is onthe same switched network also on a 100t port. Filer is an F740 running 5.3.6R1. Oplocks are disabled on the particular filesystems the user is writing to. One filesystem has NTFS-style security and the other uses mixed mode security. The network itself and the filer interface are not congested or seeing packet errors.
Do people generally leave oplocks enabled on CIFS shares? Is thisfeature enabled on NT-based file servers? Reading
http://now.netapp.com/NOW/knowledge/docs/ontap/rel536r2/html/sag/cifs25.htm
gives me the distinct feeling that oplocks == write-caching with no error checking, which sounds like trouble waiting to happen.
First report:Problem: Excel spreadsheet located in (****** directory) is taking over 20 min to save.
(email notes below) I have a single worksheet Excel spreadsheet stored on CORP-NA1 (****** directory) that takes over twenty minutes to save. During that time, my Excel application and my Windows Explorer (which is open to that directory) appear to be 'hung'. Given enough time, both applications come back and the entries in the spreadsheet appear to be saved.
I am listing this as over 20 minutes, because I have not waited around long enough to find out how long it actually takes. After 20 minutes, I've gone off to meetings, and an hour and a half later, it is working again.
Second report (same user):Sorry for the delay.
This problem is ongoing. In fact, minutes ago, a new twist appeared. As Alex was exiting this shared spreadsheet, I was opening it. It was opened, I accepted a change that had been made earlier by someone else, and went to save it. At that point, after a long (three to five minute) wait, it gave a general error message, and the data file was deleted from CORP-NA1. I was doing this from a desktop PC on the LAN (not using the VPN). At the same time, Sandi was online and was having a long delay in opening the sub-directories under ******, and also saw the data file was deleted.
I re-saved the data file, and re-established the shared workbook privileges.
I'm still guessing that some sort of NetBIOS timeout is occurring.
-- Brian Tao (BT300, taob@risc.org) "Though this be madness, yet there is method in't"