Skip to contentSkip to conversation

smbfs: caching problems

BUG Xuan Baldauf 2 participants 4 messages Apr 1, 2001 – Apr 5, 2001

lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw
Quoted 5 lines · 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.

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

Quoted 2 lines

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

#2 lore raw
In reply to Xuan Baldauf
Quoted 6 lines · Xuan Baldauf

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

fs/smbfs/inode.c +4 -3
diff -urN -X exclude linux-2.4.3-orig/fs/smbfs/inode.c linux-2.4.3-smbfs/fs/smbfs/inode.c
@@ -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;
 	}
 
 	/*
#3 lore raw
Quoted 11 lines · Urban Widmark
Quoted 6 lines · Xuan Baldauf

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