Daniel Clark <[EMAIL PROTECTED]> wrote:
On 10/27/06, Leggett, Jeff <[EMAIL PROTECTED]> wrote:
How does AFS compare to its stateless communication with NFS? We
have had problems with vendors using NFS to maintain links (EMC
comes to mind) to storage arrays, that fail often and hard.
I'm not qu
On Friday, October 27, 2006 03:53:23 PM -0400 "Peter N. Schweitzer"
<[EMAIL PROTECTED]> wrote:
# nm afs_osi.o | grep tasklist_lock
U tasklist_lock
OK; this is the one we're looking for. That, combined with Stefaan's
comment about not having the problem if keyring support is ena
On 10/27/06, Leggett, Jeff <[EMAIL PROTECTED]> wrote:
How does AFS compare to its stateless communication with NFS? We have
had problems with vendors using NFS to maintain links (EMC comes to
mind) to storage arrays, that fail often and hard.
I'm not quite sure what you mean by "using NFS to m
process.c:188 is in the "setjmp" version of savecontext() - you want the
other version.
Make sure your header files are setup so that USE_UCONTEXT is defined.
Marc
Ian Delahorne wrote:
Nope, same crash:
#0 savecontext (ep=0, savearea=0x80c8304, sp=0x40187004 "üýþÿ")
at ./process.c:188
On 10/27/06, Leggett, Jeff <[EMAIL PROTECTED]> wrote:
Hi, Sorry if these are covered somewhere, but my Architecture team is
having issues with my proposal to evaluate AFS as part of an
Environmental Segregation project. We have an issue where we have four
distinct environments, that are basicall
ted creedon <[EMAIL PROTECTED]> wrote:
1. the 1.5.10 windows msi's file name is 1.5.11, suggest the next rev
be 1.5.12.
What 1.5.10 release are you using that has a 1.5.11 in the filename?
2. Compiles and runs fine on linux 32 and 64 will stress test later
3. installs fine on XP and 2003 serv
On 10/27/06, Peter N. Schweitzer <[EMAIL PROTECTED]> wrote:
# nm afs_osi.o | grep tasklist_lock
U tasklist_lock
# nm libafs.o | grep tasklist_lock
U tasklist_lock
# nm rx_knet.o | grep tasklist_lock
w tasklist_lock
I get the exact same result, with the exception of a
> It never showed up on any volumes, or in 'vos listaddrs' output?
Never.
> added as a result of someone running a fileserver on that address at
> some time in the past -- either during testing before the renumbering,
> or because that address belonged to a server before -- or as a result
None o
Jeffrey Hutzelman wrote:
I do also wish to emphasize that this is not an AMD64 system, it's an
x86-32.
Hm. That should work. Does the module actually fail to load?
Yes, in /var/adm/syslog I get a message like
Oct 25 17:44:17 astarte kernel: libafs: Unknown symbol tasklist_lock
and libafs.m
On Friday, October 27, 2006 09:16:45 PM +0200 Stefaan
<[EMAIL PROTECTED]> wrote:
On 10/27/06, Jeffrey Hutzelman <[EMAIL PROTECTED]> wrote:
What I'm about to suggest isn't the "right" fix; in particular, it will
probably break syscall table scanning on older kernel versions. But it
should m
Daniel Clark schreef:
On 10/25/06, Bastian <[EMAIL PROTECTED]> wrote:
Christopher D. Clausen schreef:
> Bastian <[EMAIL PROTECTED]> wrote:
I don't think it is a hardware problem, since other file transfers (in
this case scp) have normal speed.
Before I knew non-afs transfers were normal, I tried
On Friday, October 27, 2006 03:20:29 PM -0400 "Peter N. Schweitzer"
<[EMAIL PROTECTED]> wrote:
Remove the "- 0x3" and the unresolved symbol reference should go
away.
I don't mean to be a pain, but this cannot possibly solve an unresolved
external reference.
Well, the reference in que
On Friday, October 27, 2006 10:21:17 PM +0300 Juha Jäykkä <[EMAIL PROTECTED]>
wrote:
Hmm. This might be it: the new address never showed up in VLDB, even
though bos showed them running normally. I wonder, how did this happen,
since the fileserver at the old address was stopped before the add
On Fri, 2006-10-27 at 14:36 -0400, Marc Dionne wrote:
> Sounds a lot like the "LWP vs setjmp" bug. What's your glibc version?
>
> If you can rebuild from source, try defining "USE_UCONTEXT" in param.h and
> see if it helps. It currently gets defined for glibc 2.4 and above, but
> only for linux2
> As a matter of fact, it can tell. Each server has an identifier
> (UUID), and registers its addresses with the VLDB on every startup.
> So, if all you are doing is renumbering an existing server, just change
> the address and restart it - the rest will happen automatically.
Except in this case,
Jeffrey Hutzelman wrote:
On Friday, October 27, 2006 08:02:07 PM +0200 Stefaan
<[EMAIL PROTECTED]> wrote:
On 10/24/06, Peter N. Schweitzer <[EMAIL PROTECTED]> wrote:
Yes, I didn't mean to be unclear. The problem I'm having is with a
2.6.18 system building 1.4.2.
I can confirm this. amd64
On 10/27/06, Jeffrey Hutzelman <[EMAIL PROTECTED]> wrote:
What I'm about to suggest isn't the "right" fix; in particular, it will
probably break syscall table scanning on older kernel versions. But it
should make your module load and work.
Go into src/afs/LINUX/osi_probe.c, and look for a line
On Fri, 2006-10-27 at 14:36 -0400, Marc Dionne wrote:
> Sounds a lot like the "LWP vs setjmp" bug. What's your glibc version?
>
> If you can rebuild from source, try defining "USE_UCONTEXT" in param.h and
> see if it helps. It currently gets defined for glibc 2.4 and above, but
> only for linux2
Sounds a lot like the "LWP vs setjmp" bug. What's your glibc version?
If you can rebuild from source, try defining "USE_UCONTEXT" in param.h and
see if it helps. It currently gets defined for glibc 2.4 and above, but
only for linux26. src/config/param.i386_linux24.h probably needs this
addition
On Friday, October 27, 2006 08:02:07 PM +0200 Stefaan
<[EMAIL PROTECTED]> wrote:
On 10/24/06, Peter N. Schweitzer <[EMAIL PROTECTED]> wrote:
Yes, I didn't mean to be unclear. The problem I'm having is with a
2.6.18 system building 1.4.2.
I can confirm this. amd64 box, linux vanilla 2.6
On Friday, October 27, 2006 03:41:24 PM +0300 Juha Jäykkä <[EMAIL PROTECTED]>
wrote:
It seemed to me as if openafs servers thought there are two distinct
servers: the one with the old ip and the one with the new. It never
seemed to occur to openafs that they were indeed the same server. (Wou
On 10/24/06, Peter N. Schweitzer <[EMAIL PROTECTED]> wrote:
Yes, I didn't mean to be unclear. The problem I'm having is with a
2.6.18 system building 1.4.2.
I can confirm this. amd64 box, linux vanilla 2.6.18, openafs 1.4.2,
both from their original sources
It does build perfectly, but after
Hi, Sorry if these are covered somewhere, but my Architecture team is
having issues with my proposal to evaluate AFS as part of an
Environmental Segregation project. We have an issue where we have four
distinct environments, that are basically mirrors of each other. From
what I am reading, it see
The server processes in 1.4.2 are segfaulting on me when trying to run
them on my 2.4.31 Gentoo box. This is what a backtrace from bos looks
like:
Program received signal SIGSEGV, Segmentation fault.
savecontext (ep=0, savearea=0x80c8304, sp=0x40187004 "üýþÿ")
at ./process.c:188
188
On 10/27/06, Juha Jäykkä <[EMAIL PROTECTED]> wrote:
Hi!
After upgrading to 1.4.2, I have started to get these (probably any bos
command will do - I tried the most common ones):
bos: could not find entry (can't find cell '' in cell database)
Also, /etc/init.d/openafs-fileserver stop produces th
Ron Croonenberg <[EMAIL PROTECTED]> writes:
> One little problem, I changed /usr/vice/etc/cellservDB (like that
> message suggests to do after the client rpm has been installed)
What "message" suggested this?
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Mem
> Yes, to remove the old server from the vldb entirely you should do a
> "vos changeaddr -oldaddr -remove".
> The former commands just removed the entries of the volumes on the old
> server.
This happened while there still were volumes at the original ip (or vldb
thought so), so "vos changeaddr"
Juha Jäykkä wrote:
Hmm, so somehow it cached the location of the volume.
I wonder if a "fs checkvolumes" would have helped.
I'm not very experienced on afs, but I'm not *that* beginner either. =) I
tried that, it simply complained that it could not contact the server at
the old address. I'm not
> Hmm, so somehow it cached the location of the volume.
> I wonder if a "fs checkvolumes" would have helped.
I'm not very experienced on afs, but I'm not *that* beginner either. =) I
tried that, it simply complained that it could not contact the server at
the old address. I'm not sure if it contac
Juha Jäykkä wrote:
the system now find the volumes from the new server?
Yes, it will.
Very nice, it indeed does. Thanks for a fast and precise reply! Those
seven volumes that were inaccessible are now accessible again.
No bother.
For some reason I had to restart one of the client processes,
> > the system now find the volumes from the new server?
> Yes, it will.
Very nice, it indeed does. Thanks for a fast and precise reply! Those
seven volumes that were inaccessible are now accessible again.
For some reason I had to restart one of the client processes, too.
Luckily that wasn't an i
I browsed the list archives and found no case identical to this; though
some were similar. One advice I found was to simply "vos delentry -server
" and then sync the vldb and server. This sounds like a good
solution, but I'm afraid it of what happens. Will the system now find the
volumes from the
Hi!
We had to change the IP address of one of our file servers (just fs, not
a db server), due to network topology changes. The process was done as
per http://www.openafs.org/pages/doc/AdminGuide/auagd008.htm#HDRWQ138,
but as a result, the VLDB thinks there is still a server with the old IP
addres
* David Howells [2006-10-27 00:18:15 +0100]:
> Ah. Turning off dynroot permits the script to complete successfully.
>
> I've put an updated script at:
>
> http://people.redhat.com/~dhowells/openafs-1.4.setup.sh
>
> That sets up an openafs server quite nicely:-)
Did you remember to turn d
Hi!
After upgrading to 1.4.2, I have started to get these (probably any bos
command will do - I tried the most common ones):
bos: could not find entry (can't find cell '' in cell database)
Also, /etc/init.d/openafs-fileserver stop produces the above and fails to
shut down anything else but bosse
35 matches
Mail list logo
