samba - Aug 2002 - Caching along linux->win smbmount?

Hi all -

    If this is in the wrong group kindly direct me where to post.

    I have an odd problem using rsync across an smbmount (via fstab) of 
a WinNT drive to Linux Redhat 7.1. I have samba 2.0.10-2 (though smbd is 
not running) and rsync 2.4.6-2.

    I use the Linux machine to rsync folders on the WinNT machine to 
folders on our production webservers. This allows clients to update 
their sites via their FTP access (which is to the WinNT machine), 
provided I have a process in place for them to deploy.

    My deployment machine mounts the WinNT drives AND the webserver 
'ServerRoot' folders (the webservers are also linux and those mounts are
NFS).

    The problem I find is this: It appears that files are being cached 
along the smbmount 'path'! I see this in several different ways.

1) I run rsync three times consecutively, each time to a different 
webserver. Each time the source is the same folder on the WinNT machine. 
The webservers are known to be in an identical state (I've had to force 
this to happen -- because of this problem -- with some effort, but I'm 
certain the webserver folders are identical). The first rsync run shows 
certain files have changed; the second and third shows a subset of those 
files! I check the target webservers and the target folders are no 
longer identical!

I had thought this was an rsync problem, but then I found the following:

2) After noticing the above situation, I can make manual changes to 
files on the WinNT server (simple changes I can easily see), save those 
files. Then I can 'cat' or 'less' them from the linux deployment
server
and I DON'T SEE THE UPDATED FILES! Instead I seem to be seeing the 
previous version of the file!


The only explanation I can find is that files are being cached somewhere 
between my linux kernel and the physical WinNT drives -- I realize 
there's a few things in there so I can't say for certain that samba is 
the culprit.

Other tidbits - this problem is intermittent. Normally we see it 
mid-afternoon, which is a HEAVY load time for the WinNT server.  I now 
force an unmount and remount of the WinNT drives before each rsync 
invocation -- the jury is still out on that change (just made it Friday 
night).

Unfortunately converting the WinNT box to Linux is not an option.



Any ideas or suggestions will be appreciated!


Dan


-- 
Dan Sperka
Virtual Properties 
Software Development
608-271-9601
877-901-9601

Confidentiality Notice
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.

On Mon, 19 Aug 2002, Daniel J. Sperka wrote:
>     I have an odd problem using rsync across an smbmount (via fstab) of 
> a WinNT drive to Linux Redhat 7.1. I have samba 2.0.10-2 (though smbd is 
> not running) and rsync 2.4.6-2.
Kernel version? If you are running the 2.4.3 or so that RH7.1 ships with,
you should try upgrading.

> 1) I run rsync three times consecutively, each time to a different 
> webserver. Each time the source is the same folder on the WinNT machine. 
> The webservers are known to be in an identical state (I've had to force
> this to happen -- because of this problem -- with some effort, but I'm 
> certain the webserver folders are identical). The first rsync run shows 
> certain files have changed; the second and third shows a subset of those 
> files! I check the target webservers and the target folders are no 
> longer identical!
This isn't necessarily a caching problem. tar exposes a problem with how
smbfs handles and updates file times when files are closed and tar will
sometimes complain that the files have changed when they haven't.

I don't know how rsync works. For tar this smbfs problem results in a
mostly harmless error message, so fixing it has had low priority.

I suspect that the setattr call in smb_proc_close_inode() in
fs/smbfs/proc.c should only be done if the file was written, or not at
all. You could try disabling it.

Also, rsync --ignore-times might give more consistent behaviour?

> 2) After noticing the above situation, I can make manual changes to 
> files on the WinNT server (simple changes I can easily see), save those 
> files. Then I can 'cat' or 'less' them from the linux
deployment server
> and I DON'T SEE THE UPDATED FILES! Instead I seem to be seeing the 
> previous version of the file!
smbfs caches file data. Without oplock support it relies on date and size
changes to tell it if it should consider the file data changed (I think
early 2.4 didn't consider size). If upgrading the kernel to a recent 2.4
doesn't help you can try this:

http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.19-rc1-ALL.patch.gz

Strictly speaking there should be a smbmount patch for that to make
smbmount negotiate oplock capability. But it seems to work without
negotiating ...

/Urban