[BUG] smbfs: caching problems

[BUG] smbfs: caching problems

[Xuan Baldauf]

Hello,

there is something wrong with smbfs caching which makes my
applications fail. The behaviour happens with
linux-2.4.3-pre4 and linux-2.4.3-final.

Consider following shell script: (where /mnt/n is a
smbmounted smb share from a Win98SE box)

router|/mnt/n/temp/smbfs> I=0; while test $I -lt 127; do
echo "abc" >>/tmp/test.abc; I=$((I+1)); done # create a 508
bytes file
router|/mnt/n/temp/smbfs> I=0; while test $I -lt 129; do
echo "xyz" >>/tmp/test.xyz; I=$((I+1)); done # create a 516
bytes file
router|/mnt/n/temp/smbfs> while true; do cp /tmp/test.abc
testfile; tail -1 testfile; cp /tmp/test.xyz testfile; tail
-1 testfile; done # copy the files alternatingly and read
the destination file after it has bean overwritten
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
abc
[...Ctrl-C...]
router|/mnt/n/temp/smbfs> cd /tmp # the same on reiserfs
router|/tmp> while true; do cp /tmp/test.abc testfile; tail
-1 testfile; cp /tmp/test.xyz testfile; tail -1 testfile;
done # here it works
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
xyz
abc
[...Ctrl-C...]
router|/tmp> uname -a
Linux router 2.4.3 #5 Fri Mar 30 14:02:24 CEST 2001 i586
unknown
router|/tmp>

Obviously, the smbfs behaviour is wrong. Interstingly, the
change in the filesize of the file overwritten seems to need
to cross a 512-block-boundary in order to show the bug.

Contact me if you need more info.

Xuân.

Re: [BUG] smbfs: caching problems

[Urban Widmark]

On Sun, 1 Apr 2001, Xuan Baldauf wrote:

> Hello,
> 
> there is something wrong with smbfs caching which makes my
> applications fail. The behaviour happens with
> linux-2.4.3-pre4 and linux-2.4.3-final.

Any version you know it doesn't happen with? (including 2.2 versions)


> Consider following shell script: (where /mnt/n is a
> smbmounted smb share from a Win98SE box)

Reproducible, but so far only with win98 (SE?). NT4, samba are testing ok
with the sizes I have tried, not sure what that means.

Thanks a lot for providing a testcase.


I have started looking but right now a lot of non-linux things are calling
for attention. If it isn't trivial I may need some time to get around to
it.
(insanely early morning flights to Stockholm and late evening return
 flights, work, easter holiday preparations, local community stuff ... and
 that was just today.
 Sorry, I'm tired and felt like complaining to someone.
 Pay no attention to me :)

You may want to consider looking into it yourself, if you need it
fixed quickly.

'tail -f' has previously been depending on smb_revalidate_inode to update
inode information properly (I suspect that one right now, will check
tomorrow. Possibly that smb open/close changes modification times ...
and/or some win95 bug workaround is causing this?)

Enabling verbose debug (select parts perhaps) can be useful.
Adding debug printouts on inode mtime+size.

/Urban

Re: [BUG] smbfs: caching problems

[Urban Widmark]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1074 bytes --]

On Sun, 1 Apr 2001, Xuan Baldauf wrote:

> there is something wrong with smbfs caching which makes my
> applications fail. The behaviour happens with
> linux-2.4.3-pre4 and linux-2.4.3-final.
> 
> Consider following shell script: (where /mnt/n is a
> smbmounted smb share from a Win98SE box)

Try the attached patch, as a workaround.

Not really sure what is happening, but it seems like win98se isn't
updating the filesize immediately (?).

After truncating the file to 0 bytes the server still returns the old size
(516) when asked (smb_proc_getattr). Somewhere that causes something to
keep the pages for the file (smb_revalidate?) or simply be confused on the
length of the file (508).

I don't understand how as vmtruncate should have thrown out the old stuff
already ... maybe the same page is reused and the last bytes (that
shouldn't be in the file) remain from the last write.

It works with NT4 and Samba, they both return the expected 0 bytes after
truncating to 0. refresh = 0 will not ask and instead run with the 0 byte
length that vmtruncate has set.

/Urban

[-- Attachment #2: Type: TEXT/PLAIN, Size: 872 bytes --]

diff -urN -X exclude linux-2.4.3-orig/fs/smbfs/inode.c linux-2.4.3-smbfs/fs/smbfs/inode.c
--- linux-2.4.3-orig/fs/smbfs/inode.c	Sat Mar 31 19:11:53 2001
+++ linux-2.4.3-smbfs/fs/smbfs/inode.c	Thu Apr  5 00:32:07 2001
@@ -234,9 +234,10 @@
 	last_sz   = inode->i_size;
 	error = smb_refresh_inode(dentry);
 	if (error || inode->i_mtime != last_time || inode->i_size != last_sz) {
-		VERBOSE("%s/%s changed, old=%ld, new=%ld\n",
+		VERBOSE("%s/%s changed, old=%ld, new=%ld, osz=%ld, sz=%ld\n",
 			DENTRY_PATH(dentry),
-			(long) last_time, (long) inode->i_mtime);
+			(long) last_time, (long) inode->i_mtime,
+			(long) last_sz, (long) inode->i_size);
 
 		if (!S_ISDIR(inode->i_mode))
 			invalidate_inode_pages(inode);
@@ -550,7 +551,7 @@
 		if (error)
 			goto out;
 		vmtruncate(inode, attr->ia_size);
-		refresh = 1;
+		refresh = 0;
 	}
 
 	/*

Re: [BUG] smbfs: caching problems

[Xuan Baldauf]

Urban Widmark wrote:

> On Sun, 1 Apr 2001, Xuan Baldauf wrote:
>
> > there is something wrong with smbfs caching which makes my
> > applications fail. The behaviour happens with
> > linux-2.4.3-pre4 and linux-2.4.3-final.
> >
> > Consider following shell script: (where /mnt/n is a
> > smbmounted smb share from a Win98SE box)
>
> Try the attached patch, as a workaround.
>

Works for me. :-)

It survived codified test case at the end of this message.

Xuân.


#!/bin/bash
#

if test -z "$1"; then
 LOCAL=0
fi

if test -n "$LOCAL"; then
 umount /mnt/n

 rmmod smbfs

 # mount
 ~/bin/lwc

 cd /mnt/n/temp
fi


rm -f /tmp/test.abc /tmp/test.xyz testfile

I=0
while test $I -lt 127; do
 echo "abc" >>/tmp/test.abc
 I=$((I+1))
done

I=0
while test $I -lt 129; do
 echo "xyz" >>/tmp/test.xyz
 I=$((I+1))
done

I=0

while test $I -lt 8; do
 cp /tmp/test.abc testfile
 tail -1 testfile
 cp /tmp/test.xyz testfile
 tail -1 testfile

 I=$((I+1))
done

rm -f /tmp/test.abc /tmp/test.xyz testfile


if test -n "$LOCAL"; then
 umount /mnt/n
fi