Re: [PATCH][RFT] smbfs bugfixes for 2.4.4

[Xuan Baldauf <xuan--lkml@baldauf.org>]

Urban Widmark wrote:

> On 7 May 2001, Linus Torvalds wrote:
>
> > It has code to do that in smb_revalidate_inode(), but it may be that
> > something else refreshes the inode size _without_ doing the proper
> > invalidation checks. Or maybe Urban broke that logic by mistake while
> > fixing the other one ;)
>
> No, I broke it when copying the ncpfs dircache code.
>
> That code will reuse an old inode if it already exists (and thus also any
> pages attached to it), which is what I wanted and should be fine except
> that it needs to invalidate_inode_pages() if something changed.
>
> Xuan and James, you have both seen this bug with smbfs not properly
> handling changes made on the server. Could you please test this patch vs
> 2.4.4 and let me know if it helps or not.
>
> http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.4-truncate+retry-4.patch
> (Apply with 'patch -p1' in the linux/ source dir)
>
> /Urban

Hello Urban,

I've been playing around a while with that patch and so far could not find any
problems anymore. But I've noticed some other annoying behaviour, which might
be caused by trying to work around the initially reported bug where the
win98se server does not update something (the new file contents after writing
to a file or the file size?) when something is written by the client: Every
little SMBwrite is followed by an SMBflush, which is translated by win98se
into a "commit" of the file, which seems to be an fsync(2) equivalent.

That is annoying, because it heavily slows down bulk transfers of small
writes, like automatically unzipping a new mozilla build from the linux box to
the windows box. Every write of say 100 bytes is implemented as

send write req
recv write ack
send flush req
sync to disk (on the windows machine)
recv flush ack

This creates heaviest disk load (on the windows machine) for minimal
throughput. Is the SMBflush needed anymore, after you seem to have found
another, better workaround?

Xuân.