> Steven N. Hirsch wrote:
> >
> > Bill,
> >
> > I applied your patch against 2.1.63, and it does not affect the problem
> > with reads failing after file re-open. I went so far as to set the delay
> > to 1 * HZ - no luck. To make matters worse, I started seeing problems
> > with file _creation_ (as reported by others) when mounting from a third
> > machine.
> >
> > Please correct me, but I don't understand how you have concluded that the
> > problem lies on the server end. We've already seen that the first read
> > call never makes it to the smbfs filesystem driver, so how is a
> > Windows-based latency to blame? I would think that it is the Linux kernel
> > which has not "caught up" with the fact that the file is completely
> > written and closed. Can you briefly outline the chain of events?
>
> Hi Steve,
> I'm sorry if the patch didn't work out, so let's fall back to the
> original plan.
Hey, that's life. I'm willing to keep at it.
> I need you to provide a very detailed debugging log of the events from
> when the file is closed after writing, to when iozone says its attempt
> to read failed. I want to see all of the system calls and returns, and
> the debugging reports of all smbfs routines, if any. (If it truly isn't
> making any calls back into the smbfs code, then the problem must lie
> elsewhere.)
By "..all of the system calls and returns..", I'm assuming that you're
referring to strace, no? If so, I already sent you output that monitored
library and system calls while iozone was running. How do I go about
getting lower-level information as the call progresses through to kernel
space?
I turned on all the debugging you asked for in the fs/smbfs directory.
Where else would you want traces from?
> I'm assuming only that the Win 3.1 server is somehow different, as the
> smbfs code works fine when talking to Win NT.
I agree. It's fine here as well.
Steve