[Fwd: smbmount problems]

[Urban Widmark]

On Thu, 5 Apr 2001, Sudheer Tumuluru wrote:

> BTW, I am using samba-client-2.0.7-4 and Redhat Linux 6.1 (linux
> 2.2.12-20).
> 
> -Sudheer
> 
> Sudheer Tumuluru wrote:
> 
> > Hi,
> >         I have an NT machine running an application which refreshes a
> > text file every minute or so with fresh data. The directory containing
> > this file is shared so that I can do an smbmount. I have a linux machine
> > which runs a program to interpret this file. When the program starts up,
> > it does smbmount of the remote directory. I am able to see the file but
> > there is a very visible propagation delay. I mount the same directory on
> > another NT machine and I see that the file change almost instantaneously
> > while the linux machine seems to take upto 2 seconds longer to refresh
> > the contents of the file. The application is very time sensitive and

smbfs caches file information (inode information, ie file size). I assume
that this causes your app to not see the change until after the cached 
value has timed out (apparently about 2 seconds).

You could get the source for the RedHat 2.2.12-20 and search through the 
smbfs code (fs/smbfs/*.c, include/linux/smb*.h) for things checking for 
delays like:
	if (age > 2*HZ)
		smb_invalid_dir_cache(dir);

(it may be enough to change smb_revalidate_inode to not
 "Check whether we've recently refreshed the inode.")

If you use 2.4.3 and samba 2.2.0alpha3 you can specify a time-to-live for
this type of cache. It is 1 second by default but you can change it with a
mount option:
$ mount -t smbfs -o username=foo,...,ttl=0 //server/share /mnt/point

I don't know if that will be enough, but perhaps worth a try (the unit is
ms, so 1000 is 1 second, if 0 is painful you can try 200 or so ....)


Also, the connection to the server may be down (if the period of
inactivity is too long) and that will add a delay. But if you linux app is
polling for filechanges every 50ms (or how often you do that) that
shouldn't be a problem.


> > needs to synchronize this file change event with other events coming
> > through the audio input. I set up TCP_NODELAY in smb.conf but that did

If this is very time sensitive it would seem much safer if the writer of
the file would send a signal (over tcp or so) to the reader that
something new arrived.

/Urban