I have a Linux box (Pentium III processor, 256M RAM) running kernel version 2.4.3, and smbmount version 2.0.7. The Linux box has a Windows 2000 Server share mounted via "mount -t smbfs ...". 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. When this happens, I've found the following seems to force Linux to get a correct copy: delete a big chunk of the file, save it (from Win98), reread it from Linux, put the big chunk back, and then reread it again. I used a network sniffer to monitor the packets. What I found is that, when the problem occurs, Linux sends SMB requests to query the path info for the file and open the file, but does not actually reread the file. 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.) Unfortunately, I don't know enough about SMB protocol to determine where the fault is. I don't know if timestamps are relevant, but the Linux box uses NTP to maintain the same time as the Win2K machine; and the Win98 machine is within a second of the same time. Suggestions? Also, is there a way to force SMB to dump its cache and reread the file, other than unmounting and remounting the share? Thanks. -- James ---------------------------------------- James H. Puttick Kerr Vayne Systems Ltd. 1 Valleywood Drive, Unit 5A Markham, Ontario L3R 5L9 Canada +1 905 475 6161 office +1 905 479 9833 fax mailto:james.puttick@kvs.com ----------------------------------------
Well, having reread your e-mail, my first answer (below my signature) is not for you, but it may apply. A samba book I was reading indicated to me that when more than one machine edits concurrently the same file on a share, the only way to keep them in sync is to have both machines access the file via SMB. So perhaps, mounting the share on the windows box and editing it through the network mount will work. I know this seems silly, but it might work. However, it would be nice to know of a better solution. R. I had this same problem. Although, I was working the other way around: editing under linux and compiling under windows. Anyway, you probably need to look into the oplock settings. If I recall correctly, oplocks (Opportunity Locks) allow a client to lock a file for writing. This basically guarantees that no one else will be allowed to write to the file so the client can feel free to cache the file locally. Turn oplocks off for the share you're having trouble with and your caching problems should go away. BTW There are multiple settings for oplocks. On Fri, 4 May 2001, James H. Puttick wrote:> I have a Linux box (Pentium III processor, 256M RAM) running > kernel version 2.4.3, and smbmount version 2.0.7. The Linux box has > a Windows 2000 Server share mounted via "mount -t smbfs ...". > > 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. > > When this happens, I've found the following seems to force Linux to > get a correct copy: delete a big chunk of the file, save it (from > Win98), reread it from Linux, put the big chunk back, and then reread > it again. > > I used a network sniffer to monitor the packets. What I found is that, > when the problem occurs, Linux sends SMB requests to query the > path info for the file and open the file, but does not actually reread the > file. > > 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.) > Unfortunately, I don't know enough about SMB protocol to > determine where the fault is. > > I don't know if timestamps are relevant, but the Linux box uses NTP > to maintain the same time as the Win2K machine; and the Win98 > machine is within a second of the same time. > > Suggestions? > > Also, is there a way to force SMB to dump its cache and reread the > file, other than unmounting and remounting the share? > > Thanks. > > -- James > > > ---------------------------------------- > James H. Puttick > > Kerr Vayne Systems Ltd. > 1 Valleywood Drive, Unit 5A > Markham, Ontario L3R 5L9 > Canada > > +1 905 475 6161 office > +1 905 479 9833 fax > > mailto:james.puttick@kvs.com > ---------------------------------------- > >
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