[Samba] Caching along linux->win smbmount?
urban at teststation.com
Mon Aug 19 10:49:01 GMT 2002
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:
Strictly speaking there should be a smbmount patch for that to make
smbmount negotiate oplock capability. But it seems to work without
More information about the samba