The way it works is that if a CIFS client has open files but no command has been received at the filer for 10 minutes, we send a keep-alive NETBIOS message. That then goes through the normal TCP timeout logic, which will normally take 520 sec or so. That means the total elapsed time for a non-responsive connection to timeout is just under 20 minutes. If you can verify that the locks are still present after more than 20 minutes, please let us know. We'll have to take a packet trace to see what is going on.
Mark
-----Original Message----- From: Dave Atkin [mailto:dla1@york.ac.uk] Sent: Wednesday, June 21, 2000 12:41 AM To: Muhlestein, Mark Cc: toasters@mathworks.com Subject: RE: CIFS file locking problem
On Mon, 19 Jun 2000 mark.muhlestein@netapp.com wrote:
<cut>
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.
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
-
mark.muhlestein＠netapp.com