Hi All -

I just wanted to let all OpenAFS users know that we discovered a
problem/solution
in one of our Labs which was using Juniper Switches.

When moving AFS volumes to fileservers within this Lab, many volumes were
experiencing
strange corruption in some of the gzipped or data files (non-ASCII files).

If we changed the options on the fileserver and volserver to use -nojumbo,
we no longer
saw the corruption.

We went through many phases of debugging and we were able to prove that AFS
was not
the cause of the corrupted data.

Eventually, the switches were updated and we no longer saw the problem.

We discovered that the problem was related to a bug in the Juniper
Switches, the ticket number is







A search of this Problem Report Number ==> PR1006718 takes you to the
Release Update
of the JunOS

  Resolved Issues in JunOS OS Release 12.3 for M Series, MX Series and T
Series Routers

http://www.juniper.net/techpubs/en_US/junos12.3/information-products/topic-collections/release-notes/12.3/index.html?topic-81613.html

If the volserver is using "-nojumbo", the problem will NOT happen.  It can
only happen when the
volserver is sending jumbo packets and then the "special triggers" hit.

We had a difficult time finding a reproducible case because the triggers
would not always hit
from test to test.

If our fileservers were allowing jumbos, we would have probably have seen
data corruption on StoreData
calls to the fileserver as well, but our fileservers were already using the
-nojumbo option.

There really isn't much more I can add to this.

Again, if your site uses Juniper Switches, you may want to make sure that
you are running with this
fix.  Or possibly using the -nojumbo option.

Thanks for your help

Todd DeSantis

Reply via email to