[Samba] Caching along linux->win smbmount?

Daniel J. Sperka dsperka at virtualproperties.com
Mon Aug 19 11:49:00 GMT 2002


Thanks, your descriptions seem to match my situation. For example, the 
last step in my process is to tar the source directories -- and I often 
see the message you describe (something like "file has changed since we 
...."). Similarly, If I have a file open in my Windows editor and I use 
my process to 'rsync' it, my editor reports that the file has changed. 
That should not be, strictly speaking, as rsync really shouldn't be 
modifying the source files.

For this afternoon I will implement the --ignore-times suggestion.

You were right on the money about my kernel - 2.4.2-2smp. I'll try and 
upgrade later this week.



Dan




Urban Widmark wrote:

>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
>
>

-- 
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.



-------------- next part --------------
HTML attachment scrubbed and removed


More information about the samba mailing list