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(a)mathworks.com
> Subject: RE: CIFS file locking problem
>
>
> On Mon, 19 Jun 2000 mark.muhlestein(a)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(a)york.ac.uk
>