[OpenAFS] fileserver problem on 1.2.11 and SuSE 9.0
Lewis, Dave
LEWIS@NKI.RFMH.ORG
Fri, 18 Jun 2004 16:38:22 -0400
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C45574.32B81A70
Content-Type: text/plain
> > I'm wondering, where do we go from here? Is this fileserver a
> > viable long-term solution for a production server? We will
> > have to decide soon whether to 1) downgrade from SuSE 9.0 to 8.2
> > (which we know to work well with OpenAFS) or 2) to wait for a fix
> > or 3) continue using this fileserver.
>
> Before, you could setenv LD_ASSUME_KERNEL 2.4.1 and use the tviced
> (pthreads) fileserver and all would be well. I bet that isn't true
> anymore.
We tried this. You're correct -- it doesn't work.
> > Is there anything else that we should try to help to identify the
> > problem?
>
> If you feel like debugging the pthreads implementation you have and
> figuring out how it's different from every other
> implementation, well, I
> suspect you don't, but that's what's needed.
You're correct again (sorry!).
However, we did try one more thing which didn't work either:
In SuSE 9.0 there are 2 pthreads libraries, one in /lib and one
in /lib/i686. The tviced fileserver uses the one in /lib/i686.
We tried the one in /lib (via LD_LIBRARY_PATH) and we ran into
the same problems.
To summarize, the OpenAFS 1.2.11 server doesn't run well on SuSE 9.0
because of the implementation of the pthreads library on that distro.
It would be great to have a fix if possible.
We'll switch to SuSE 8.2, which should be fine. Thanks for your help.
Dave
------_=_NextPart_001_01C45574.32B81A70
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [OpenAFS] fileserver problem on 1.2.11 and SuSE 9.0</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> > I'm wondering, where do we go from here? Is this fileserver a</FONT>
<BR><FONT SIZE=2>> > viable long-term solution for a production server? We will</FONT>
<BR><FONT SIZE=2>> > have to decide soon whether to 1) downgrade from SuSE 9.0 to 8.2</FONT>
<BR><FONT SIZE=2>> > (which we know to work well with OpenAFS) or 2) to wait for a fix</FONT>
<BR><FONT SIZE=2>> > or 3) continue using this fileserver.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Before, you could setenv LD_ASSUME_KERNEL 2.4.1 and use the tviced</FONT>
<BR><FONT SIZE=2>> (pthreads) fileserver and all would be well. I bet that isn't true</FONT>
<BR><FONT SIZE=2>> anymore.</FONT>
</P>
<P><FONT SIZE=2>We tried this. You're correct -- it doesn't work. </FONT>
</P>
<P><FONT SIZE=2>> > Is there anything else that we should try to help to identify the</FONT>
<BR><FONT SIZE=2>> > problem?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> If you feel like debugging the pthreads implementation you have and</FONT>
<BR><FONT SIZE=2>> figuring out how it's different from every other </FONT>
<BR><FONT SIZE=2>> implementation, well, I</FONT>
<BR><FONT SIZE=2>> suspect you don't, but that's what's needed.</FONT>
</P>
<P><FONT SIZE=2>You're correct again (sorry!). </FONT>
</P>
<P><FONT SIZE=2>However, we did try one more thing which didn't work either:</FONT>
<BR><FONT SIZE=2>In SuSE 9.0 there are 2 pthreads libraries, one in /lib and one </FONT>
<BR><FONT SIZE=2>in /lib/i686. The tviced fileserver uses the one in /lib/i686. </FONT>
<BR><FONT SIZE=2>We tried the one in /lib (via LD_LIBRARY_PATH) and we ran into </FONT>
<BR><FONT SIZE=2>the same problems. </FONT>
</P>
<P><FONT SIZE=2>To summarize, the OpenAFS 1.2.11 server doesn't run well on SuSE 9.0 </FONT>
<BR><FONT SIZE=2>because of the implementation of the pthreads library on that distro. </FONT>
<BR><FONT SIZE=2>It would be great to have a fix if possible.</FONT>
</P>
<P><FONT SIZE=2>We'll switch to SuSE 8.2, which should be fine. Thanks for your help.</FONT>
</P>
<P><FONT SIZE=2>Dave</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C45574.32B81A70--