Re: file leases

[Jamie Lokier <jamie@shareable.org>]

Jeremy Allison wrote:
> > When I want to edit a file directly on the server, opening for write
> > stalls for a long time.  Presumably the lease causes Samba to send a
> > break_lease to the _one_ client.  Being an idle client that's not
> > holding the file open, it should respond immediately to break_lease,
> > and then Samba should let me open the file locally.
> > 
> > That's how leases are supposed to work, but something in that whole
> > arrangement isn't working properly.  Samba is 3.0.6-r3, kernel is
> > 2.6.8 (both gentoo versions).
> 
> This is easy to check. Turn on debug level 10 with millisecond log
> timestamps and watch the whole process from the smbd point of view.
> What is stalling should become obvious.

Ok, I've just observed a 45 second stall with log level = 10.  I
forgot to set millisecond timestamps but I don't think that's a a
problem.

Here's the command which stalls.  It's on a local filesystem on the
server, Linux 2.6.8, Samba 3.0.6:

jamie@kushida ~/x $ date; cp -p 3rd.jpg 4th.jpg; date
Wed Sep 22 11:50:49 BST 2004
Wed Sep 22 11:51:34 BST 2004

This was triggered by creating 3rd.jpg (copied locally from
elsewhere).  Then viewing it in Internet Explorer on the Windows ME
client.  Then closing IE, and trying to copy the file locally.

Looking at the log, I see Samba gets the lease and grants the oplock
to the Window client:

[2004/09/22 11:50:40, 3] smbd/oplock_linux.c:linux_set_kernel_oplock(185)
  linux_set_kernel_oplock: got kernel oplock on file x/3rd.jpg, dev = 303, inode = 1325168, file_id = 7
[2004/09/22 11:50:40, 5] smbd/oplock.c:set_file_oplock(218)
  set_file_oplock: granted oplock on file x/3rd.jpg, dev = 303, inode = 1325168, file_id = 7, tv_sec = 41515900, tv_usec = 68af0

At about 11:50:49 I expect to see linux_oplock_receive_message and
then linux_release_kernel_oplock -- because I see these at times when
there's no stall -- but I *don't* see either in the Samba log after
this point:

kushida ~ # grep linux_ /var/log/samba/log.smbd
......
[2004/09/22 11:38:59, 3] smbd/oplock_linux.c:linux_set_kernel_oplock(185)
  linux_set_kernel_oplock: got kernel oplock on file x/3rd.jpg, dev = 303, inode = 1325168, file_id = 5
[2004/09/22 11:39:08, 10] smbd/oplock_linux.c:linux_release_kernel_oplock(196)
  linux_release_kernel_oplock: file x/3rd.jpg, dev = 303, inode = 1325168 file_id = 5 has kernel oplock state of 1.
[2004/09/22 11:39:08, 3] smbd/oplock_linux.c:linux_set_kernel_oplock(185)
  linux_set_kernel_oplock: got kernel oplock on file x/3rd.jpg, dev = 303, inode = 1325168, file_id = 6
[2004/09/22 11:39:10, 3] smbd/oplock_linux.c:linux_oplock_receive_message(149)
  linux_oplock_receive_message: kernel oplock break request received for dev = 303, inode = 1325168 fd = 28, fileid = 6
[2004/09/22 11:39:10, 3] smbd/oplock_linux.c:linux_kernel_oplock_parse(239)
[2004/09/22 11:39:10, 10] smbd/oplock_linux.c:linux_release_kernel_oplock(196)
  linux_release_kernel_oplock: file x/3rd.jpg, dev = 303, inode = 1325168 file_id = 6 has kernel oplock state of 0.
[2004/09/22 11:50:40, 3] smbd/oplock_linux.c:linux_set_kernel_oplock(185)
  linux_set_kernel_oplock: got kernel oplock on file x/3rd.jpg, dev = 303, inode = 1325168, file_id = 7
kushida ~ #

Perhaps more worryingly, there is no communication with Windows ME, so
Windows ME may still think it has the oplock.  20 minutes later, after
viewing the file a couple more times in ME, and after editing it
locally, there are no further messages with "oplock" or "linux" in the
Samba log.

30 minutes later I edit the file in Windows ME with notepad, writing
to it.  That breaks the lease because Samba breaks it itself; then it
reacquires the lease after writing the file.


It looks like either:

  (1) Linux leases aren't working: they're not signalling Samba.

  (2) or, Samba is not interfacing with Linux leases properly, so
      is missing the signal.


-- Jamie