Well, I think I partially found out why this is acting strangely. I've
tried this on both samba 2.2.5 and 2.2.6rc4. The file handles work a little
differently between kernel 2.2 and kernel 2.4.
On kernel 2.2, when you access a directory, you get a single CWD open
handle (from LSOF 4.47):
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
smbd 12659 root cwd DIR 8,5 4096 624027 test
This CWD is the only handle opened.
This handle will stay in use until you click the 'up one folder' button.
Just closing the window doesn't seem to help.
On Kernel 2.4 you get 3 opened handles. 2 are read handles, while the other
is a CWD: (from LSOF 4.63):
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
smbd 14270 root cwd DIR 8,2 4096 131038 disc_test_pc/
smbd 14270 root 22r DIR 8,2 4096 131038 disc_test_pc/
smbd 14270 root 23r DIR 8,2 4096 131038 disc_test_pc/
When you close the window OR click the 'up one folder' button the cwd
handle is released.
However, the 2 extra read handles are not released. And, every instance of
access to that folder generates 2 more extra read handles. This will happen
for EVERY folder inside a share, or the share itself. Actually, the CWD
handle will disappear by itself if you wait a few minutes, even if the
folder is still in use.
So, after using a share with lots of folders on kernel 2.4 you see LOTS of
open folder handles when you run a lsof -p <smb_pid_of_a_workstation> even
if you've closed all windows to everything on that server, or you clicked
the heck out of the 'up one folder' button..
Oh, the above test was without mounting anything. That folder had just a
single file in it.
Soo...is there anyone out there using samba plus rh 8.0/kernel 2.4 plus
sharing a cdrom drive where the disc is being changed regularly? Are you
having problems unmounting the disc? :)
Again, RH 8.0, kernel 2.4.18, x86
Thanks,
Jon
At 11:03 AM 10/16/2002 -0700, you wrote:>Hey all,
>
>I've been fighting a samba share/unmount problem for several days now
and may
>have found a bug in the connect/disconnect code.
>
>Basically, it seems that while everything claims to free the connection to
>the
>share, it doesn't actually happen. This is me closing ALL windows to the
>server:
>
>log.smbd:
> jon1 (192.168.200.2) connect to service disc1_pc_test as user breakit
> (uid=501
>, gid=501) (pid 2908)
>[2002/10/16 10:13:27, 10] smbd/service.c:make_connection(672)
> calling vfs_ops.connect for service disc1_pc_test (options = )
> jon1 (192.168.200.2) closed connection to service IPC$
>[2002/10/16 10:13:37, 3] smbd/connection.c:yield_connection(48)
> Yielding connection to IPC$
> jon1 (192.168.200.2) closed connection to service disc1_pc_test
>[2002/10/16 10:13:38, 3] smbd/connection.c:yield_connection(48)
> Yielding connection to disc1_pc_test
>
>smbstatus:
>Samba version 2.2.5
>Service uid gid pid machine
>----------------------------------------------
>IPC$ jon_monroe jon_monroe 2908 jon1 (192.168.200.2) Wed
>Oct 16 1
>0:10:55 2002
>
>No locked files
>
>lsof disc1_pc_test:
>smbd 2908 root 19r DIR 7,1 2048 65536
/DVD_BURN/disc1/disc_test_pc/
>smbd 2908 root 23r DIR 7,1 2048 65536
/DVD_BURN/disc1/disc_test_pc/
>
>
>fuser disc1_pc_test:
>/DVD_BURN/disc1/disc_test_pc/: 2908
>
>
>I've tried disabling all cache options I know of, and it hasn't made
any
>difference. Here is a snip of my current smb.conf:
>[disc1_pc_test]
> comment = virtual PC volume from ISO image
> path = /DVD_BURN/disc1/disc_test_pc
> guest ok = yes
> valid users = root, jon_monroe, breakit
> force user = breakit
> force group = breakit
> oplocks = no
> level2 oplocks = no
> read only = yes
> posix locking = no
> locking = no
>
>
>This is on a RH8.0 x86 box, running K 2.4.18, and self installed samba
2.2.5.
>
>Due to the specific use, I can't use the pre/post exec functions for the
>unmount, though I don't see how it would make a difference.
>
>So, is there something I'm missing? Something else to try? Is this
behavior
>normal? :)
>
>Thanks for any help!
>
>Jon
>
>--
>To unsubscribe from this list go to the following URL and read the
>instructions: http://lists.samba.org/mailman/listinfo/samba