Theory 1.) The failure is caused by excessive network traffic
This doesn't seem to be the case. I put together a test setup in my lab
and flooded the network with pings. The storm was pretty impressive, but
the connection held tight.
Theory 2.) The failure is caused by a period of inactivity.
This may indeed be a piece of the puzzle, and seems to be one of the more
popular notions going around. However, in the same laboratory setup
mentioned above, I disconnected the client machine overnight, and it was
still working properly upon re-connection the next day.
Theory 3.) The failure is specific to a particular configuration of
server.
This is not the case, as I have received correspondence from a number of
people with servers ranging from OS2 to NT as a PDC, all with the same
problem.
Theory 4.) The failure has something to do with the DEBUG option in the
source code.
The theory goes that the DEBUG option will work, but if it is turned off,
that is where the problem starts. Something to do with attempting to write
out error messages. I haven't had the opportunity
to observe this directly, but it is an interesting theory.
~~~~
Having said all that, I would like to relate the configuration under which
I was able to observe the failure, and present YAT (Yet Another Theory)
The basic concept behind this configuration was to use files set up on an
NT web server through an apache server on Linux by smbmounting the NT drive
in the apache html directory. This was the original configuration in which
I observed the problem earlier this year. For maximum possibility of
inducing failure I set it up as an smbmount on /mnt/test, the built a
symolic link to that from a /home/httpd/html/Test directory, which is in
the apache document path.
This way, somebody can connect to the apache server on the Linux box and
view the html files which are kept on the NT box. The underlying reason
for this is that the NT files are updated by a daily batch process which
runs every morning. A rather complex system was built around the NT box,
so it was impratical to re-build it on Linux. We needed access to those
files from the Linux box for security reasons, hence the smbmount.
At first, it looked like I was going to get the same result I had been
experiencing throughout this process, the smbmount looked rock solid. Many
hours went by, and every time I checked the connection, it was still
working. However, this morning when I checked, it was broken.
This leads into my new theory. I have seen a number of posts indicating
that if files are changed on the smb server, that this causes issues on the
mounted smb client. It wasn't entirely clear to me what those issues were,
it seemed to be a lack of current data from the perspective of the client,
or perhaps even a broken connection. In any event, I am speculating that
the update process on the NT box in my configuration above may be the
trigger that induces the failure. Most of the files are over-written
during the update, and this may be a reason for the broken connection.
I will be continuing to pursue this issue and narrow down the
variablesassociated with the failure. Thanks to everyone that has sent in
messages on this problem, and kudos to you if you have managed to read
through this lengthy post.
Regards,
Steve Rhodes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/