The underlying problem may be due to a timing bug in the Microsoft client (MS has acknowledged the bug; their answer is "upgrade to Windows 2000") This is seen more on filers than NT server because we are so much faster doing opens. We have a workaround, which is to enforce a small delay before breaking the oplock on oplocked files that are re-opened. This is controlled by an option, "cifs.oplocks.opendelta". It defaults to 8 ms which works well for most clients, but it sounds like you might want to try increasing it. The "cifs stat" console command has a value "OpLkBkNoBreakAck" which gets incremented if this problem is seen. If you have non-zero values for this, try increasing the opendelta to 16 and see if things get better.
As to the protocol issues, as Bruce said, we're more or less stuck with them because of Microsoft compatibility. If a session goes away when there is no request pending (i.e. we don't owe the client a response), the filer delays 10 minutes before terminating the session. This is to keep the session alive in the face of temporary network partitions, which we can't distinguish from just losing a client. Currently that 10 minute interval is not configurable on the filer, but it sounds like we might want to make it so.
Mark Muhlestein -- mmm@netapp.com
On Mon, 19 Jun 2000 mark.muhlestein@netapp.com wrote:
<cut>
This 10 minute timeout doesn't seem to be working. I tried this with my PC yesterday. It had approx 13 locks, I turned the power off, and after an hour the filer still thought the locks were active. However they have gone this morning, after around 16 hours. We're running 5.3.5.
-- Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin@york.ac.uk
-
Dave Atkin -
mark.muhlestein＠netapp.com