File cacheing problem?

[Urban Widmark]

On Fri, 4 May 2001, James H. Puttick wrote:

> I am running into what seems to be a cacheing problem. I am doing 
> software development on this share, editing the files from a Win98 
> workstation, and compiling on the Linux box.
> 
> However, frequently, if I edit a file, make a few small changes (so that 
> the size of the file changes by a few dozen bytes or less), and then 
> recompile, Linux gets a corrupt version of the file. Suppose I've 
> increased the file length by 20 bytes. I will get the *old* version of the 
> file, but then padded out to the correct length with 20 nullchars at the 
> end.

Which editor do you use?

Does it make any difference if the file is edited directly on the win2k
machine? Or if you edit with the file on the win98 box and mount a share
from that.

Can you create a script/batfile to repeat it? (using echo or something
instead of an editor)

Does it always happen for a certain filesize? (200 byte file, adding 20
bytes always causes this)

I'm looking for a repeatable testcase.


A long time ago I received a patch to provide oplocks for smbfs, as well
as fcntl locking. For various reasons it has not been added to the kernel
yet. Here is a untested version vs 2.4.4 (was ok in 2.4.3-ac30).
http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.4-oplocks.patch
(cd /somewhere/linux; patch -p1 < smbfs-2.4.4-oplocks.patch)

Oplocks are supposed to help invalidate caches when files are changed.


> My conclusion is that either (a) Win2K is providing Linux with the 
> information indicating that the file has changed, but Linux is failing to 
> recognize that it has to re-read the file, or (b) Win2K is not providing 
> that information, so that Linux doesn't realize that the file has changed. 
> (But it is odd that Linux *does* know that the length has changed.) 

win2k doesn't say that the file changed but smbfs does "revalidate" inode
information. It knows that things can be changed so all info has a
time-to-live. If the file has changed it tries to invalidate the cached
file contents and re-read it. Something is wrong with the last part, it
seems.


> Also, is there a way to force SMB to dump its cache and reread the 
> file, other than unmounting and remounting the share?

No, but it can be done.

After applying the oplocks patch, apply this one.
http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.4-oplocks-invalidate.patch

It will add a /proc entry to which you can send filenames that you want
invalidated. You will need to use one 'echo' per file, it is a very stupid 
interface.
echo -n /mnt/smb/some/path/file.c > /proc/fs/smbfs/invalidate_cache

But what this does is the same as what should happen when smbfs sees that
the file size or time changes.

/Urban