RE: [OpenAFS] changing administrative principal?

[Dexter 'Kim7; Kimball]

Make sure the new admin is able to maintain the auth db, if necessary.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Frank Burkhardt
> Sent: Tuesday, October 04, 2005 11:01 AM
> To: Jiann-Ming Su; OpenAFS-info@openafs.org
> Subject: Re: [OpenAFS] changing administrative principal?
> 
> 
> Hi,
> 
> On Tue, Oct 04, 2005 at 12:30:13PM -0400, Jiann-Ming Su wrote:
> > How do I change the administrative principal of my cell?  And is it
> > necessary to have the my_afs_princ/admin notation if my_afs_princ is
> > dedicated specifically for being the admin principal for my OpenAFS
> > cell?
> 
> Remove the current admin principal from the 
> system:administrators group, add
> the new one to this group (pts add ..., pts remove ...).
> 
> Remove the current admin from the userlists of *all* 
> afs-servers of your
> cell and add the new one to userlist of *all* afs-servers 
> (bos removeuser
> ..., bos adduser ...).
> 
> 
> Frank
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Fileserver preferences and retired fileservers

[Dexter 'Kim7; Kimball]

Scenario:

I feed fileserver preferences into "fs setserverprefs."

One of the fileservers cannot be contacted.

AFAIK the client will ask the fileserver for the time to see if the
fileserver is back up.

What are the constraints on this behavior:

-- How often does the client ask?

-- When does the client finally quit?

-- If a fileserver is retired and will never be run again at an IP address
specified by "fs setserverprefs," when does the client decide that the
fileserver no longer exists?

Any info greatly appreciated.

Kim


=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccrecom



___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Need details of callback mechanism -- questions ...

[Dexter 'Kim7; Kimball]

Debugging what looked like a callback related race condition has ended up
challenging my beliefs about callbacks.

IIRC when a fileserver attempts a BCB to client X and the BCB fails to
elicit a response, the fileserver periodically retries the BCB.  When I was
teaching for Transarc we taught something like ... the fileserver retries
the BCB immediately, then puts the client on a 3 second list, then 10 second
list, then one minute list.  Eventually the fileserver decides that the
client has been unreachable for so long it instructs the client, on next
contact, to mark all callbacks from  as "iffy," causing the
client to RPC the fileserver to check AFS version numbers on cached items.
If the version numbers are the same then the client updates the callback
state and no data transfer occurs.  OTOH if the file has been changed and
the version numbers are different, the client receives data and then updates
the callback state.

I'm looking for definitive answers to the following.  Assume RW volumes
throughout.

1.  When a fileserver sends a BCB to a given client, does it wait for a
response or does it send the BCB and handle responses asynchronously?  I
believe it used to wait for a response and that it no longer does so.

2.  When does the fileserver begin sending the BCBs?
a. When it begins to modify a given file -- i.e when it receives the
write RPC and before (or simultaneously with) storing the first few bytes.
b. When it has written the first bytes to a given file -- i.e. after it
has stored x bytes but before receiving a "close" from the client.
c. When it receives the close file RPC.
3.  If the fileserver attempts a BCB to client X and gets no response (BCB
fails on X), does it:
a. Retry immediately.
b. Wait some period of time before attempting the BCB again.
c. (a) then (b)
4.  What is the current fileserver BCB retry scheme?

Any info much appreciated.

Kim 



=
Kim (Dexter) Kimball
CCRE, Inc.
dhkccrecom






___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Re: [Slightly OT] changing UID of a user to 1 ["readonly mountpoint"]

[Dexter 'Kim7; Kimball]

The "readonly mountpoint" nomenclature is widely used to mean "#" (regular)
mountpoint but is inaccurate.

A read-only mountpoint is created with "fs mkmount  volname.readonly"
and results in a regular (#) mountpoint and takes you to a readonly volume

A _regular_ mountpoint is created with  "fs mkmount  volname" and
results in a mountpoint with # but takes you to a readwrite volume or a
readonly volume depending on the cache manager's "Volume Traversal Rules."

The Volume Traversal Rules are applied at each mount point the AFS client
encounters:

1. At a regular (#) mountpoint, if ".readonly" is used in the named volume
go to a .readonly instance of the volume.  If none exists, fail.
2. At a regular (#) mountpoint, if ".backup" is used in the named volume go
to the .backup instance of the volume.  If none exists, fail.
3. At a regular (#) mountpoint:
a. If currently in a readonly volume and the VLDB indicates that a
readonly instance exists for the volume named in the mount point, go to a
readonly instance or fail.
  b. If currently in a readwrite volume go to the readwrite instance of
the volume named in the  mount point, or fail.  Replicas and .backup volumes
are ignored.
3. At a readwrite (%) mountpoint, go to the readwrite instance of the volume
named in the mount point, or fail.  Replicas and .backup volumes are
ignored.


Kim


=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com




> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Altman
> Sent: Monday, August 29, 2005 1:08 PM
> To: Russ Allbery
> Cc: Madhusudan Singh; openafs-info@openafs.org
> Subject: Re: [OpenAFS] Re: [Slightly OT] changing UID of a user to 1
> 
> 
> The '#' means that the mount point is a read-only path.
> If it were a read-write path, there would be a '%'.
> 
> Jeffrey Altman
> 
> 
> Russ Allbery wrote:
> 
> > Madhusudan Singh <[EMAIL PROTECTED]> writes:
> > 
> > 
> >>Indeed it was an lsmount in my script (included as a 
> check). And then
> >>adduser was failing with a force-badname check. Fixed that, 
> deleted bnl4
> >>from the admin group and am now back in business.
> > 
> > 
> >>In any case, what does the # mean above.
> > 
> > 
> > It's an artifact of how AFS internally represents mount points.  The
> > actual volume name is the name omitting the #.  It's confusing, but
> > changing it at this point would probably break other things.
> > 
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] running vos from "another" machine

[Dexter 'Kim7; Kimball]

Issue the "tokens" command and see who you are.

Then issue "bos listu " on your fileservers and see who's in the
UserList.

You should have tokens for someone listed in UserList.

Kim


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
 Croonenberg
 Sent: Thursday, August 25, 2005 11:51 AM
 To: [EMAIL PROTECTED]
 Cc: openafs-info@openafs.org
 Subject: RE: [OpenAFS] running vos from "another" machine
 
 
 Hi Kim,
 
 I noticed that the -localauth had something to do with it.
 
 Sooo...what I did is simply execute  the vos commands without the
 -localauth. And that seemed to work.
 
 Maybe I am missing something, it surprised me. I didn't 
 klog or anything
 and was able to "dump" a volume.
 
 Ron
 
 
 >>> "Dexter 'Kim' Kimball" <[EMAIL PROTECTED]> 08/25/05 11:09 AM >>>
 Ron,
 
 "vos" per se doesn't require the /usr/afs/etc directory
 
 OTOH "vos" with "-localauth" _does_ require the up-to-date
 /usr/afs/etc/KeyFile
 
 "-localauth" essentially means "I'm root on this here 
 machine that has a
 KeyFile so create some AFS admin credentials for me."  
 
 Without the KeyFile "vos ... -localauth" simply can't create the
 token/ticket you require.
 
 If you sftp /usr/afs/etc/KeyFile from one of your AFS 
 servers to the
 client-only box from  which you're running vos you'll be 
 up and running
 with
 "vos  -localauth"
 
 When you change keys remember to update the KeyFile on your admin
 client.
 
 Putting the KeyFile on a client isn't a good idea unless 
 the machine in
 question is secure/limited access, which yours is.
 
 Kim
 
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
  Croonenberg
  Sent: Wednesday, August 24, 2005 4:07 PM
  To: [EMAIL PROTECTED]
  Cc: openafs-info@openafs.org
  Subject: RE: [OpenAFS] running vos from "another" machine
  
  
  Hi,
  
  I have installed/setup :
  openafs-1.2.13-rhel3.0.1
  openafs-client-1.2.13-rhel3.0.1
  openafs-kernel-1.2.13-rhel3.0.1
  
  now if I try to do a vos dump like :
  vos dump -id homestaff.cowboy.backup -f
  /data/afs-dump/homestaff.cowboy.backup -localauth  
   
   
  
  then:
  vsu_ClientInit: Could not process files in 
 configuration directory
  (/usr/afs/etc).
  could not initialize VLDB library (code=4294967295) 
  
  And when I look in /usr/afs, then /usr/afs/etc isn't there.
  
  So I assume in order to use vos  it needs to be there. 
  What needs to be
  in it ?  the same thing/stuff as in the 
  fileserver/dbserver /usr/afs/etc
  ?
  
  >., so be sure to have a local account or a local 
  password for your 
  >AFS account.
  
  I have a local account on that machine.
  
  > You'll have to klog after you log in.
  
  right..  and that seems to work just fine.
   
  >I'm sure we could come up with something more complicated :)
  
  ;-)  looking forward to it...
  
  oh and btw, in case you're wondering  why I want this..  I 
  want to dump
  the volumes on a "backup server" that no one has access to.
  (other stuff is dumped/archived on that machine too)
  
  thanks,
   
  Ron
  
  
  ___
  OpenAFS-info mailing list
  OpenAFS-info@openafs.org
  https://lists.openafs.org/mailman/listinfo/openafs-info
  
 
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] running vos from "another" machine

[Dexter 'Kim7; Kimball]

Ron,

"vos" per se doesn't require the /usr/afs/etc directory

OTOH "vos" with "-localauth" _does_ require the up-to-date
/usr/afs/etc/KeyFile

"-localauth" essentially means "I'm root on this here machine that has a
KeyFile so create some AFS admin credentials for me."  

Without the KeyFile "vos ... -localauth" simply can't create the
token/ticket you require.

If you sftp /usr/afs/etc/KeyFile from one of your AFS servers to the
client-only box from  which you're running vos you'll be up and running with
"vos  -localauth"

When you change keys remember to update the KeyFile on your admin client.

Putting the KeyFile on a client isn't a good idea unless the machine in
question is secure/limited access, which yours is.

Kim


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
 Croonenberg
 Sent: Wednesday, August 24, 2005 4:07 PM
 To: [EMAIL PROTECTED]
 Cc: openafs-info@openafs.org
 Subject: RE: [OpenAFS] running vos from "another" machine
 
 
 Hi,
 
 I have installed/setup :
 openafs-1.2.13-rhel3.0.1
 openafs-client-1.2.13-rhel3.0.1
 openafs-kernel-1.2.13-rhel3.0.1
 
 now if I try to do a vos dump like :
 vos dump -id homestaff.cowboy.backup -f
 /data/afs-dump/homestaff.cowboy.backup -localauth  
  
  
 
 then:
 vsu_ClientInit: Could not process files in configuration directory
 (/usr/afs/etc).
 could not initialize VLDB library (code=4294967295) 
 
 And when I look in /usr/afs, then /usr/afs/etc isn't there.
 
 So I assume in order to use vos  it needs to be there. 
 What needs to be
 in it ?  the same thing/stuff as in the 
 fileserver/dbserver /usr/afs/etc
 ?
 
 >., so be sure to have a local account or a local 
 password for your 
 >AFS account.
 
 I have a local account on that machine.
 
 > You'll have to klog after you log in.
 
 right..  and that seems to work just fine.
  
 >I'm sure we could come up with something more complicated :)
 
 ;-)  looking forward to it...
 
 oh and btw, in case you're wondering  why I want this..  I 
 want to dump
 the volumes on a "backup server" that no one has access to.
 (other stuff is dumped/archived on that machine too)
 
 thanks,
  
 Ron
 
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Re: [OpenAFS-Doc] IBM source docs

[Dexter 'Kim7; Kimball]

I'm pretty sure the editor du jour was an Xwindows based ugliness called
"Publisher" unaffectionately referred to as "Punisher" as it was a PITA.

Not that this helps :)

Kim


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of 
 Esther Filderman
 Sent: Tuesday, August 23, 2005 9:15 AM
 To: [EMAIL PROTECTED]; openafs-info@openafs.org
 Subject: [OpenAFS] Re: [OpenAFS-Doc] IBM source docs
 
 
 
 > Are there any contacts at IBM that could provide the 
 original .scr files for
 > the documentation?
 > 
 > The IBM doc pdf and htm files appear to have been 
 emitted using a document
 > system possible internal to IBM.
 
 Once again: Nobody has the original source.  There are IBM 
 people on
 the Elders board. Nobody can find them.  Lost cause.  Give 
 up asking already.
 
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] running vos from "another" machine

[Dexter 'Kim7; Kimball]

 -Original Message-
 From: Ron Croonenberg [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, August 24, 2005 2:13 PM
 To: [EMAIL PROTECTED]
 Cc: openafs-info@openafs.org
 Subject: RE: [OpenAFS] running vos from "another" machine
 
 
 Hi Kim,
 
 >Hi Ron,
 
 >Guess you're up and running :)
 
 Yup,  had some communication problems between the "old" 
 server and the new box.
 
 >The AFS commands can be run from any AFS client.
 
 Right..  BUT I don't want to just install the AFS client 
 because I don't want anyone to really have access to that machine.
 
Installing the AFS client doesn't grant anyone access to that machine.

 >AFAIK if a user doesn't have an entry in /etc/passwd 
 they're not able >to log in.  PAM may be able to 
 circumvent this, I'm not an expert, but
 > suspect if you try using an /etc/passwd with just the 
 permitted login
 > users that it will work.
 
 >IOW -- set the machine up as an AFS client, and any of the AFS 
 >commands can be run from that client.  Trim the /etc/passwd file
 > and see if you can still log in as one of the deleted users.
 
 Uhm, ok,  someone else suggested to not do any "pam" 
 stuff..  that way afs users can simply not use the machine.
 
That should work as long as there are no local (non-AFS) accounts with local
passwords.

I prefer leaving PAM properly configured.

Keep in mind that if PAM doesn't work for anyone else it won't work for you
either, so be sure to have a local account or a local password for your AFS
account.

You'll have to klog after you log in.

 I thought that maybe there was some "elegant" way to do 
 what I wanted.
 
I'm sure we could come up with something more complicated :)

 >Kim
 
 thanks,
 
 Ron
 
 =
 Kim (Dexter) Kimball
 CCRE, Inc.
 kimkimballjpl.nasa.gov
 dhkccre.com
 
 
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
  Croonenberg
  Sent: Wednesday, August 24, 2005 11:36 AM
  To: openafs-info@openafs.org
  Subject: [OpenAFS] running vos from "another" machine
  
  
  Hello all,
  
  I want a machine that is not "per se" an OpenAFS client or 
  server to be
  able to run vos so I can dump volumes in a cell.
  
  (Actually what I want is "a" machine to run OpenAFS so 
  that I can use
  vos on it, but I don't want anyone with an afs account to 
  be able to log
  in to the box, except an OpenAFS admin maybe.)
  
  Can that be done ? (and if so what do I need ?)
  
  thanks,
  
  Ron
  
  ___
  OpenAFS-info mailing list
  OpenAFS-info@openafs.org
  https://lists.openafs.org/mailman/listinfo/openafs-info
  
 
 
 
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] running vos from "another" machine

[Dexter 'Kim7; Kimball]

Hi Ron,

Guess you're up and running :)

The AFS commands can be run from any AFS client.

AFAIK if a user doesn't have an entry in /etc/passwd they're not able to log
in.  PAM may be able to circumvent this, I'm not an expert, but suspect if
you try using an /etc/passwd with just the permitted login users that it
will work.

IOW -- set the machine up as an AFS client, and any of the AFS commands can
be run from that client.  Trim the /etc/passwd file and see if you can still
log in as one of the deleted users.

Kim



=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com



 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
 Croonenberg
 Sent: Wednesday, August 24, 2005 11:36 AM
 To: openafs-info@openafs.org
 Subject: [OpenAFS] running vos from "another" machine
 
 
 Hello all,
 
 I want a machine that is not "per se" an OpenAFS client or 
 server to be
 able to run vos so I can dump volumes in a cell.
 
 (Actually what I want is "a" machine to run OpenAFS so 
 that I can use
 vos on it, but I don't want anyone with an afs account to 
 be able to log
 in to the box, except an OpenAFS admin maybe.)
 
 Can that be done ? (and if so what do I need ?)
 
 thanks,
 
 Ron
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Large volumes -- anyone using?

[Dexter 'Kim7; Kimball]

If you've got experience with large volumes (tens to hundreds of GB) I'd
much appreciate any experiences you may have had, good bad or indifferent.

Thanks.

Kim



=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com



___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Problems on AFS Unix clients after AFS fileserver moves

[Dexter 'Kim7; Kimball]

fs checkv will cause the client to discard what it remembers about volumes.
Did you try that?

Kim


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Rich Sudlow
 Sent: Tuesday, August 09, 2005 9:58 AM
 To: openafs
 Subject: [OpenAFS] Problems on AFS Unix clients after AFS 
 fileserver moves
 
 
 We've been having problems with our cell for the last couple
 years with AFS clients after fileservers are taken out of service.
 Before that things seemed to work ok when doing fileserver 
 moves and
 rebuilding. All data was moved off the fileserver but the clients
 still seem to have some need to talk to it.  In the past the AFS
 admins have left the fileservers up and empty for a number of
 days to try to resolve this issue -  but it doesn't resolve the
 issue.
 
 For example a recent example:
 
 The fileserver reno.helios.nd.edu was shutdown after all data
 moved off of it.  However the client still can't get to
 a number of AFS files.
 
 [EMAIL PROTECTED] root]# fs checkservers
 These servers unavailable due to network or server problems: 
 reno.helios.nd.edu.
 [EMAIL PROTECTED] root]# cmdebug reno.helios.nd.edu -long
 cmdebug: error checking locks: server or network not responding
 cmdebug: failed to get cache entry 0 (server or network 
 not responding)
 [EMAIL PROTECTED] root]# cmdebug reno.helios.nd.edu
 cmdebug: error checking locks: server or network not responding
 cmdebug: failed to get cache entry 0 (server or network 
 not responding)
 [EMAIL PROTECTED] root]#
 
 [EMAIL PROTECTED] root]#  vos listvldb -server reno.helios.nd.edu
 VLDB entries for server reno.helios.nd.edu
 
 Total entries: 0
 [EMAIL PROTECTED] root]#
 
 on the client:
 rxdebug localhost 7001 -version
 Trying 127.0.0.1 (port 7001):
 AFS version:  OpenAFS 1.2.11 built  2004-01-11
 
 
 This is a linux 2.4 client and I don't have kdump - have 
 also had these
 problems on sun4x_58 clients too.
 
 I should mention that we've seen some correlation
 to this happening on machines with "busy" AFS caches  - 
 which makes it
 even more frustrating as it seems to affect machines which 
 depend on
 AFS the most. We've tried lots of fs flush* * -
 So far we've ended up rebooting which does fix the
 problem.
 
 Does anyone have any clues what the problem is or what a workaround
 might be?
 
 Thanks
 
 Rich
 
 -- 
 Rich Sudlow
 University of Notre Dame
 Office of Information Technologies
 321 Information Technologies Center
 PO Box 539
 Notre Dame, IN 46556-0539
 
 (574) 631-7258 office phone
 (574) 631-9283 office fax
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] reconfiguring an OpenAFS server

[Dexter 'Kim7; Kimball]

Hi Ron,

How did you restart the service?

Did you try a reboot or just the /etc/init.d route?

Kim


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
 Croonenberg
 Sent: Tuesday, August 09, 2005 10:31 AM
 To: openafs-info@openafs.org
 Subject: [OpenAFS] reconfiguring an OpenAFS server
 
 
 Hello all,
 
 I am trying to re-configure and AFS server that I set up 
 so that it serves the same cellname as an older server I have.
 
 So I changed the CellServDB and Thiscell and copied the 
 contents from the  /usr/afs/etc directory on the old 
 server to the /usr/afs/etc on the new server.
 
 Then I tried to start the afs service again and what 
 happened is below. To me it seems that I have to throw 
 away all the volumes, user accounts etc ...correct ?
 What about the things that were created with "bos create" 
 when setting up the server (kaserver, buserver ptserver 
 etc) ? Looks like those need to be changed too ?
 
 Or is it just easier to start from scratch ?
 
 Ron
 
 
 Starting AFS services. 
 free(): invalid pointer 0xb7402010!
 free(): invalid pointer 0xb73d1010!
 free(): invalid pointer 0xb73a0010!
 free(): invalid pointer 0xb736f010!
 free(): invalid pointer 0xb733e010!
 free(): invalid pointer 0xb730d010!
 free(): invalid pointer 0xb72dc010!
 free(): invalid pointer 0xb72ab010!
 free(): invalid pointer 0xb727a010!
 free(): invalid pointer 0xb7249010!
 free(): invalid pointer 0xb7218010!
 free(): invalid pointer 0xb71e7010!
 free(): invalid pointer 0xb71b6010!
 free(): invalid pointer 0xb7185010!
 afsd: All AFS daemons started.
 free(): invalid pointer 0xb7154010!
 free(): invalid pointer 0xb7123010!
 free(): invalid pointer 0xb70f2010!
 free(): invalid pointer 0xb70c1010!
 free(): invalid pointer 0xb7090010!
 free(): invalid pointer 0xb705f010!
 free(): invalid pointer 0xb702e010!
 free(): invalid pointer 0xb6ffd010!
 free(): invalid pointer 0xb6fcc010!
 free(): invalid pointer 0xb6f9b010!
 free(): invalid pointer 0xb6f6a010!
 free(): invalid pointer 0xb6f39010!
 free(): invalid pointer 0xb6f08010!
 free(): invalid pointer 0xb6ed7010!
 free(): invalid pointer 0xb6ea6010!
 free(): invalid pointer 0xb6e75010!
 free(): invalid pointer 0xb6e44010!
 free(): invalid pointer 0xb6e13010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6de2010!
 free(): invalid pointer 0xb6db1010!
 free(): invalid pointer 0xb6d80010!
 free(): invalid pointer 0xb6d4f010!
 free(): invalid pointer 0xb6d1e010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6ced010!
 free(): invalid pointer 0xb6cbc010!
 free(): invalid pointer 0xb6c8b010!
 free(): invalid pointer 0xb6c5a010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6c29010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6bf8010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6bc7010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6b96010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6b65010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6b34010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6b03010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6ad2010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6aa1010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6a70010!
 /usr/afs/bin/buserver: problems with host name Ubik init failed
 free(): invalid pointer 0xb6a3f010!
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] server install "from scratch"

[Dexter 'Kim7; Kimball]

Removing everything from /vicepa removes only AFS volumes.  The AFS user
accounts etc live in /usr/afs/db

Kim

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
 Croonenberg
 Sent: Tuesday, August 09, 2005 11:10 AM
 To: openafs-info@openafs.org
 Subject: [OpenAFS] server install "from scratch"
 
 
 Just wondering.
 
 If I delete everything on /vicepa  does that mean I get 
 rid of all configuration, all users, all volumes ?
 And the system looks like I just installed OpenAFS and I 
 didn't do any configurations yet ?
 
 thanks,
 
 Ron
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] creating root.afs and root.cell

[Dexter 'Kim7; Kimball]

Hi Ron,

I expect root.afs already exists on your original server.

Use "vos listvl root.afs" and you should see it.

You can move it with "vos move."

IIRC the /vicepa you wiped had only volumes from the cell you "threw away?"

Kim


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
 Croonenberg
 Sent: Tuesday, August 09, 2005 2:02 PM
 To: openafs-info@openafs.org
 Subject: [OpenAFS] creating root.afs and root.cell
 
 
 I am trying to reconfigure an OpenAFS server I set up.
 
 When I try to create root.afs I get the following.
 
 [EMAIL PROTECTED] local]# vos create afs-1 /vicepa root.afs 
 -cell csc.depauw.edu -noauth
 Volume root.afs already exists
 Error in vos create command.
 
 How can I fix this (I deleted everything on /vicepa before 
 I started)
 
 thanks,
 Ron
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] restoring volumes

[Dexter 'Kim7; Kimball]

Hi Ron,

Shut down on Friday.

User accounts can be moved in a similar fashion.

I'm assuming that the fileserver is also the AFS DB server in a single-node
cell?

And that you are not going to change the cell name?

If these two assumptions are correct, when you bring up the second
fileserver bring it up as an AFS DB server as well.

Refer to the AFS Admin guide/Quick Start "bringing up a second DB
server/fileserver" as I'm pretty sure the following is not complete.

Make sure the CellServDB files in /usr/vice/etc and /usr/afs/etc on the new
server contain the server info for both the old DB server and the new DB
server.

The server encryption keys on the two nodes will need to match.  The easiest
way to ensure this is to copy the key file (howls of protest from everyone
who ever took one of my classes :) from one machine to another, using sftp
or some sort of secure transfer (howls of protest diminish somewhat.)
(After your two-node cell is working properly I suggest changing the
encryption key making sure to add the new key to the KeyFile first (bos
addkey on each server machine, same secret word) and then, using the same
password/secret word, update the password for the user "afs" to match -- and
make sure to specify the same key version number (kvno) for bos addkey and
kas setpasswd.  After the cell is functioning correctly.)

Once the KeyFile and CellServDB are in place on the new server start the
bosserver and add yourself to the UserList on the new node (bos adduser).
Then "bos create" away.

Add the new AFS DB server info to the /usr/vice/etc/CellServDB on the old
AFS DB node and then as root run "fs newcell" making sure to specify the
complete list of DB servers for the cell.

Then add the new AFS DB server info to the /usr/afs/etc/CellServDB on the
old AFS DB node and use "bos addhost" to update the server CellServDB.  I
believe you have to restart all of the AFS server DB processes on the old DB
node so that they will see the changes but this may no longer be required.
(I've been doing this a long time and things change.)  If you want you can
wait five minutes or so and look in /usr/afs/db on the new node -- ls -l
should show the same sizes as in /usr/afs/db on the old node.  And/or more
conventionally, you can use "udebug" against each of the DB server ports on
the new machine -- it should report a DB version number that matches the old
machine.

Make sure to add your admin account(s) to the UserList on the new node --
"bos adduser"

After the DB servers synchronize you'll have the user accounts (PTS and KAS
entries) on both machines.

Once you get this far you should be able to "vos move" volumes from old
fileserver to new fileserver.

How many AFS clients do you have?  Their CellServDB files will be out of
date.  Choices -- update the CellServDB file on each client (conventional
approach), or leave the old AFS DB server running so that clients can find
the DB services, or change the IP/hostname of the new fileserver to match
the old and shut down/retire the old if retirement is what you're up to.

If you shutdown the existing DB server before you make sure your AFS clients
can find the new one AFS will stand for the "Ain'tNo File System" -- the
clients won't be able to find volumes, users won't be able to log in, things
in generally will gradually (within an hour or so) succumb to entropy.

Do follow the Quick Start procedures where applicable.

Let me know if you get stuck.

Kim


=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com



 -Original Message-
 From: Ron Croonenberg [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, August 06, 2005 4:29 PM
 To: [EMAIL PROTECTED]; openafs-info@openafs.org
 Subject: RE: [OpenAFS] restoring volumes
 
 
 Sounds like a plan.
 
 Can useraccounts be moved too ?
 
 >>> "Dexter 'Kim' Kimball" <[EMAIL PROTECTED]> 08/05/05 1:56 PM >>>
 Another way to do this is to make the new fileserver a 
 member of the current
 cell and, use vos move to get the volumes across, and 
 retire/shoot/fix the
 current fileserver.
 
 The advantage of this is that users won't be disturbed and 
 you'll get all of
 the data including changes made while the move is in progress.
 
 If you dump the .backup volumes any changes made between 
 "vos backup" and
 "vos dump | vos restore" will be lost.
 
 Another caution: if you're using the AFS kaserver the new 
 cell name will
 invalidate all your passwords since the cell name is used 
 in key encryption.
 IOW you can't copy the KADB to the new cell and use 
 existing passwords.  You
 may have already taken care of this some other way, but 

RE: [OpenAFS] restoring volumes

[Dexter 'Kim7; Kimball]

Another way to do this is to make the new fileserver a member of the current
cell and, use vos move to get the volumes across, and retire/shoot/fix the
current fileserver.

The advantage of this is that users won't be disturbed and you'll get all of
the data including changes made while the move is in progress.

If you dump the .backup volumes any changes made between "vos backup" and
"vos dump | vos restore" will be lost.

Another caution: if you're using the AFS kaserver the new cell name will
invalidate all your passwords since the cell name is used in key encryption.
IOW you can't copy the KADB to the new cell and use existing passwords.  You
may have already taken care of this some other way, but thought I'd mention
it.

You'll also have to update the CellServDB on all the clients so that they'll
see the new cell (afs-1).

Is there a reason for the new cell name?  If not I'd bring up the new
fileserver as a member of the existing cell.

Otherwise:


1. Get admin tokens in both cells.
   a. One of the cells will have to have CellServDB entries for both cells.
  i.  If not, update the CellServDB and use "fs newcell" (as root)
 ii.  I'm assuming that the csc.depauw.edu client you're using has CSDB
info for afs-1.csc.depauw.edu

2. Get admin tokens for both cells
   a. klog ..., klog ... -cell

3. Recommended:  in old cell issue "vos backupsys"
   a. If you dump the RW volumes in the old cell they'll be unusable during
the dump.
   b. vos backupsys gives a fresh snapshot to dump from
  Alternatively you might want to issue "vos backup " just
before dumping , especially for volumes that are in use.

4. vos dump  | vos restore-cell
afs-1.csc.depauw.edu

This restores the .backup snapshot from csc.depauw.edu (users won't lose
access) to a RW volume in cell afs-1.csc.depauw.edu

Assuming that UIDs map across the two cells (AFS PTS UIDS) the ACLs will be
OK in the new cell.

If AFS accounts (PTS UIDs) don't match in the new cell things access will
not be what you intend:  numeric PTS UIDs are stored on ACLs/in PTS groups.



Kim




 btw the 2 servers are not in the same cell.
 
     the old cell is called csc.depauw.edu the new cell is 
 called afs-1.csc.depauw.edu
 
 >>> "Dexter 'Kim' Kimball" <[EMAIL PROTECTED]> 08/05/05 1:16 PM >>>
 Let's see.
 
 If the two servers are in the same cell the vos restore 
 will fail -- can't
 have 2 instances of a RW volume, and the example you give 
 would leave
 homestaff.cowboy as a RW on two different servers.
 
 If the two servers are in different cells then you want to 
 get admin tokens
 for both cells and use "vos dump  | vos restore  
 -cell "
 
 If you want to replicate the volume within a given cell 
 use "vos addsite "
 "vos release"
 
 If you want to replicate the volume within a given cell 
 but want default
 access to be to the RW volume, create a RW mount point (fs 
 mkm  -rw).
 
 Not sure what you're after.  Probably a case I didn't cover :)
 
 Kim
 
 
 =
 Kim (Dexter) Kimball
 CCRE, Inc.
 kimkimballjpl.nasa.gov
 dhkccre.com
 
 
 
  -Original Message-
  From: Ron Croonenberg [mailto:[EMAIL PROTECTED] 
  Sent: Friday, August 05, 2005 12:05 PM
  To: [EMAIL PROTECTED]; openafs-info@openafs.org
  Subject: RE: [OpenAFS] restoring volumes
  
  
  Ahh...ok...
  
  Well let me explain what I am trying to do, at least it's 
  a plan I have.
  
  - I want to dump a volume with vos on the old server, 
 let's say
"homestaff.cowboy"
  - move the dumpfile to the new server
  - restore the dumpfile with vos on the new server to a 
  volume called
homestaff.cowboy
  
  So maybe I need a bit different approach ?
  
  Ron
  
  
  >>> "Dexter 'Kim' Kimball" <[EMAIL PROTECTED]> 08/05/05 1:02 PM >>>
  Ron,
  
  Specify a different value after "-name"
  
  The volume will be restored to the specified server and 
  partition -- as a
  read write volume.
  
  The ".backup" volume name extension won't work (it's 
  reserved) and is
  causing your "restore name" to exceed the 22 char limit.
  
  If you want to restore over the existing RW volume put it 
  on the same server
  and partition, use the same name, and 

RE: [OpenAFS] restoring volumes

[Dexter 'Kim7; Kimball]

Let's see.

If the two servers are in the same cell the vos restore will fail -- can't
have 2 instances of a RW volume, and the example you give would leave
homestaff.cowboy as a RW on two different servers.

If the two servers are in different cells then you want to get admin tokens
for both cells and use "vos dump  | vos restore  -cell "

If you want to replicate the volume within a given cell use "vos addsite "
"vos release"

If you want to replicate the volume within a given cell but want default
access to be to the RW volume, create a RW mount point (fs mkm  -rw).

Not sure what you're after.  Probably a case I didn't cover :)

Kim


=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com



 -Original Message-
 From: Ron Croonenberg [mailto:[EMAIL PROTECTED] 
 Sent: Friday, August 05, 2005 12:05 PM
 To: [EMAIL PROTECTED]; openafs-info@openafs.org
 Subject: RE: [OpenAFS] restoring volumes
 
 
 Ahh...ok...
 
 Well let me explain what I am trying to do, at least it's 
 a plan I have.
 
 - I want to dump a volume with vos on the old server, let's say
   "homestaff.cowboy"
 - move the dumpfile to the new server
 - restore the dumpfile with vos on the new server to a 
 volume called
   homestaff.cowboy
 
 So maybe I need a bit different approach ?
 
 Ron
 
 
 >>> "Dexter 'Kim' Kimball" <[EMAIL PROTECTED]> 08/05/05 1:02 PM >>>
 Ron,
 
 Specify a different value after "-name"
 
 The volume will be restored to the specified server and 
 partition -- as a
 read write volume.
 
 The ".backup" volume name extension won't work (it's 
 reserved) and is
 causing your "restore name" to exceed the 22 char limit.
 
 If you want to restore over the existing RW volume put it 
 on the same server
 and partition, use the same name, and specify -overwrite.
 
 Otherwise give it a new name (homestaff.cowboy.R e.g.), 
 mount it, fix the
 existing volume ... etc.
 
 Kim
 
 
 
 =
 Kim (Dexter) Kimball
 CCRE, Inc.
 kimkimballjpl.nasa.gov
 dhkccre.com
 
 
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
  Croonenberg
  Sent: Friday, August 05, 2005 11:28 AM
  To: openafs-info@openafs.org
  Subject: [OpenAFS] restoring volumes
  
  
  Hello,
  
  I dumped a volume on an old afs server and try to restore 
  it on the new server. This is what I see:
  
  [EMAIL PROTECTED] vicepb]# vos restore -server 
  afs-1.csc.depauw.edu -partition /vicepa -name 
  homestaff.cowboy.backup -file 
  /vicepb/homestaff.cowboy.backup -cell afs-1.csc.depauw.edu 

   
  
  vos: the name of the volume homestaff.cowboy.backup 
  exceeds the size limit
  
  Does vos restore create the volume ?  I didn't see the 
  volume homestaff.cowboy.backup.  There is a volume called 
  homestaff.cowboy on the new server though.
  
  Ron
  
  
  
  
  ___
  OpenAFS-info mailing list
  OpenAFS-info@openafs.org
  https://lists.openafs.org/mailman/listinfo/openafs-info
  
 
 
 
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] restoring volumes

[Dexter 'Kim7; Kimball]

Ron,

Specify a different value after "-name"

The volume will be restored to the specified server and partition -- as a
read write volume.

The ".backup" volume name extension won't work (it's reserved) and is
causing your "restore name" to exceed the 22 char limit.

If you want to restore over the existing RW volume put it on the same server
and partition, use the same name, and specify -overwrite.

Otherwise give it a new name (homestaff.cowboy.R e.g.), mount it, fix the
existing volume ... etc.

Kim



=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com



 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ron 
 Croonenberg
 Sent: Friday, August 05, 2005 11:28 AM
 To: openafs-info@openafs.org
 Subject: [OpenAFS] restoring volumes
 
 
 Hello,
 
 I dumped a volume on an old afs server and try to restore 
 it on the new server. This is what I see:
 
 [EMAIL PROTECTED] vicepb]# vos restore -server 
 afs-1.csc.depauw.edu -partition /vicepa -name 
 homestaff.cowboy.backup -file 
 /vicepb/homestaff.cowboy.backup -cell afs-1.csc.depauw.edu 
 
 
 vos: the name of the volume homestaff.cowboy.backup 
 exceeds the size limit
 
 Does vos restore create the volume ?  I didn't see the 
 volume homestaff.cowboy.backup.  There is a volume called 
 homestaff.cowboy on the new server though.
 
 Ron
 
 
 
 
 ___
 OpenAFS-info mailing list
 OpenAFS-info@openafs.org
 https://lists.openafs.org/mailman/listinfo/openafs-info
 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] removing IP addresses

[Dexter 'Kim7; Kimball]

Did you try vos changeaddr?

Kim

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Lester Barrows
 Sent: Tuesday, July 19, 2005 1:21 PM
 To: openafs-info@openafs.org
 Subject: Re: [OpenAFS] removing IP addresses
 
 
 Hi Brian,
 
 We have a similar configuration at our AFS cell. What 
 we've done is set up 
 separate CellServDB files for clients on the non-routable 
 network which point 
 to the non-routable volserver IP. We also added several 
 "fs setserverprefs" 
 lines to the init scripts (at the end of the start() 
 method) to cause the 
 clients to prefer the volume locators and file servers we 
 want them to talk 
 to. It's a bit of a kludge, but none of the other methods 
 we've found have 
 worked to any degree of satisfaction.
 
 Regards,
 Lester
 
 On Monday 18 July 2005 19:37, Brian May wrote:
 > Hello,
 >
 > How do I remove IP addresses from the output of "vos listaddrs"?
 >
 > I setup my server when I was still learning AFS, and 
 wasn't aware of the
 > NetInfo file at the time.
 >
 > I have tried:
 >
 > * Changing NetInfo and restarting, but it doesn't help.
 >
 > * vos changeaddr $addr -remove -localauth -verbose
 >   but it complains it is in use by the vldb.
 >
 > * Delete the sysid file and restart the server. As per:
 >   
 https://lists.openafs.org/pipermail/openafs-info/2002-May/0
04467.html
>   No change.
>
> * Dodgy instructions in
>  
> https://lists.openafs.org/pipermail/openafs-info/2004-December/015854.html
> didn't help.
>
> Obviously these are wrong for various reasons, but what is the correct
> way?
>
> I haven't tried:
>
> * removing the other interfaces, because they are used by other
>   processes.
>
> * Move all volumes to somewhere else (would another partition be
>   sufficient?), delete the addresses, and then move then back again
>   (would this help?). This seems excessive.
>
> The problem is some of these addresses are private IP addresses and
> cannot be accessed from outside my private network. As such I don't want
> the fileserver advertising these addresses to clients outside my
> network. It causes the client to take ages to start while it tries the
> internal addresses first.
>
> It also lists every public IP address my machine has, I only want
> OpenAFS on one of these IP addresses, not every one. This in turn would
> allow tighter firewall controls.
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Defect in "backup dump" -- at least as recent as 1.2.11

[Dexter 'Kim7; Kimball]

Defect:   AFS backup system -- "backup dump" command erroneously dumps
every .backup volume in cell ...

Description:  A volume set refers to a fileserver that existed at one time
but has been shut down and removed from the cell.
The volume set tested refers to the removed fileserver,
partition .*, volumes .*.backup 
  The "backup dump" command refers to the volume set.
  
  Expected behavior: no volumes are dumped -- there is no such
fileserver
  
  Actual behavior:  all "*.backup" volumes in the entire cell
are dumped.
  
Reproducing:


I didn't want to create a bogus fileserver, so I added a bogus entry to
/etc/hosts on an existing fileserver.  

# echo "127.0.0.1 BogusFileserver" >> /etc/hosts


Still on the same fileserver, I created a volset to use to refer to the
bogus fileserver:

$ backup addvolset BOGUS

Then the volentry for the volset BOGUS -- which is where the actual
reference to the fileserver is stored:

$ backup addvole BOGUS -server BogusFileserver -partition ".*" -volu
".*\.backup"

MUST DO:  Now comment out or remove the /etc/hosts entry for
BogusFileserver.

Now the backup dump command.  "-n" means "no action" and you can use any
number for the port, it doesn't have to exist in the BUDB.

$ backup dump BOGUS /full -port 11 -n

The backup dump command returns a list of all volumes in the cell.  This
reproduces the behavior.


NOTES:

1.  The backup addvolentry command will not allow adding a volume set entry
that refers to a nonexistent fileserver.
2.  The defect exists only for a fileserver that exists in the backup
db/volset but is no longer listed in the VLDB.
3.  I reproduced the behavior for IBM AFS 3.6 2.45 and OpenAFS 1.2.11
4.  I have not tested the case where a fileserver is still running but
stores no volumes.
5.  If a specific volume is named in the volset, instead of .*\.backup, the
backup dump command attempts to dump that single volume.
6.  If a specific partition is named in the volset, instead of .*, the
backup dump command behaves identically as for partition .*

Kim Kimball




=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com



___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Locking issues, Solaris & AFS, kernel panic stated to be due to AFS vs Solaris thread locking order

[Dexter 'Kim7; Kimball]

We have had a panic/core on A Sun Solaris box -- the Sun kernel engineer who
examined the core determined that there was lock contention for a page of
memory -- and that the kernel and AFS (IBM AFS 3.6 2.53) use different
locking order and that this results in lock contention which is subsequently
detected by the kernel which panics as a result.

Summary and details below.

Question:  Is there any current issue with lock order in OpenAFS that anyone
is aware of, or any changes that have been made to OpenAFS to address the
issue?

-- SUMMARY

1.  The spontaneous reboots recently seen on systemX are caused by an
interaction between the AFS client and the Solaris operating system. 
(This also seems to be a likely explanation for the systemY and 
directory server reboots, as well.)

2.  The AFS client locks thread resources in the reverse order of that
employed by the operating system.  This can (and in this case did)
result in a condition where each of two processes obtains one half of
the locks needed on a resource and cannot get the other half because it
is already locked by the other process.  Kernel panic, or system hang,
eventually results.

3.  Per our conversation with Sun Microsystems, the condition has been seen
before and is known to Sun.  Also, the reboots or hangs are expected to
be quite erratic in timing, and to some degree dependent on the other
process that are used on a given system.

4.  Last night, we upgraded systemX to the very latest Transarc AFS client
available to our production environment, IBM 3.6 2.53.  We do not know if
this condition has been fixed in
that client, but it was the most we could do at the time.  UPDATE: We have
since had another 
panic and have sent a second core to Sun to see if the lock contention is
the cause of this.

5.  Kim Kimball will be checking with Transarc and with the open source
AFS group to see if either has a client that has fixed the condition. 
If not, bug reports will be filed.  If so, we need to obtain
an appropriate client.

6.  systemX and, I think, the institutional directory servers, are
absolutely
dependent on AFS at this time to support the Kerberos plug-ins used for
authenticating with the AFS password.  So removing AFS is not an option
at this time.

7.  We can and will consider removing AFS from related systems.
However, there are dependencies there as well that will have to be
accounted for, and the remaining life of these systems is measured in
months.


DETAILS FROM SUN KERNEL ENGINEER 
> 
> 
> To whom:
> 
> Here is my analysis of the core file from eis-msg-056. My comments are 
> on lines that begin with >>>.
> 
> 
> 
> core file:  /cores/64603274/vmcore.0
> release:5.8 (64-bit)
> version:Generic_108528-27
> machine:sun4u
> node name:  eis-msg-056
> hw_provider:Sun_Microsystems
> system type:SUNW,Sun-Fire-280R
> hostid: 8329d379
> time of crash:  Thu Jun  2 14:28:44 MDT 2005
> age of system:  2 minutes 32.75 seconds
> panic CPU:  1 (2 CPUs, 2G memory)
> panic string:   Deadlock: cycle in blocking chain
> 
> sanity checks: settings...vmem...cpu...sysent...
> WARNING: unknown module afs seen 6 times in sysent table
> clock...misc...done
> 
>  >>> Below is the thread that actually panicked the system:
> 
> SolarisCAT(vmcore.0)> panic
> panic on cpu 1
> panic string:   Deadlock: cycle in blocking chain
>  panic user (LWP_SYS) thread: 0x30006221220  pid: 348  bound to CPU: 
> 1 
> cmd: ./ns-slapd -D /opt/netscape/server5/slapd-dir -i 
> /opt/netscape/server5/slapd-di
> t_wchan: 0x3ace880  sobj: mutex owner: 0x30006220720 
> (recursive mutex loop)
> top mutex owner: 0x30006221220  mutex type: unknown
> t_procp: 0x30004570010  p_as: 0x3000162c988  hat: 0x30595e8  cnum:
0x896
>size: 52.0M  rss: 37M
> t_stk: 0x2a100671af0  sp: 0x10423351  t_stkbase: 0x2a10066e000
> t_pri: 58(TS)  t_epri: 60  pctcpu: 0.439721  t_lwp: 0x300061f9890 
> machpcb: 0x2a100671af0
> last CPU: 1
> idle: 100 ticks (1.00 seconds)
> start: Thu Jun  2 14:28:34 2005
> age: 10 seconds (10 seconds)
> stime: 15275 (0 seconds later)
> syscall: #65 sys#65() (sysent: genunix:loadable_syscall+0x0)
> tstate: TS_SLEEP - awaiting an event
> tflg:   T_PANIC - thread initiated a system panic
> tpflg:  none set
> tsched: TS_LOAD - thread is in memory
>  TS_DONT_SWAP - thread/LWP should not be swapped
> pflag:  SLOAD - in core
>  SULOAD - u-block in core
>  ASLWP - process uses an aslwp for async signals
>- also overloaded to mean it is a MT process
>  SPRLOCK - process locked by /proc
>  NOCD - new creds from VSxID, do not coredump
> 
> pc: 0x10047010  unix:panicsys+0x44:   call  unix:setjmp
> 
> -- on panic_stack --
> 0x10423b50 unix:panicsys+0x44 (0x10423d20, 0x2a100671258, 
> 0x10146550, 0x78002000, 0x736c6963, 0xb)
> 0x10423c70 unix:vpanic+0xcc (0x10146550, 0x2a100671258, 0x3c, 0x0, 
> 0x0, 0x30005f88400)
> -- switch to user

RE: [OpenAFS] Question about append-only directories and ownership of files

[Dexter 'Kim7; Kimball]

You're right of course about the directory ownership.

Kim



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Todd M. Lewis
> Sent: Monday, March 21, 2005 11:26 AM
> To: openafs-info@openafs.org
> Cc: 'Thomas M. Payerle'
> Subject: Re: [OpenAFS] Question about append-only directories 
> and ownership of files
> 
> 
> 
> 
> Dexter 'Kim' Kimball wrote:
> > 
> > In general AFS doesn't care about ownership/mode bits -- 
> ignores them
> > entirely on directories,
> 
> Not quite. The owner of a directory has implied administrator 
> rights in that 
> directory. That may be relevant here. Or not. Whatever.
> -- 
> +--+
>/ [EMAIL PROTECTED]  919-962-5273  http://www.unc.edu/~utoddl /
>   / Bakers trade bread recipes on a knead to know basis. /
> +--+
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Oracle Databases...

[Dexter 'Kim7; Kimball]

> Byte-range locking is really not the core issue here.
> 
> The backend storage for an Oracle database is highly specialized, 
> performance-critical, and cannot be shared among multiple 
> servers.  Thus, 
> it is not a good candidate for storage in _any_ remote or distributed 
> filesystem, including AFS.
> 


Now that's a definitive response.

Thanks.

Kim

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Hutzelman
> Sent: Monday, March 21, 2005 3:15 PM
> To: [EMAIL PROTECTED]; 'Craig Cook'; openafs-info@openafs.org
> Subject: RE: [OpenAFS] Oracle Databases...
> 
> 
> 
> 
> On Monday, March 21, 2005 09:53:07 AM -0700 Dexter 'Kim' Kimball 
> <[EMAIL PROTECTED]> wrote:
> 
> >> Is OpenAFS a good filesystem to run an Oracle database on?
> >
> > Lousy, actually.  No byte range locking, to begin with.  
> Other performance
> > overhead.
> 
> Byte-range locking is really not the core issue here.
> 
> The backend storage for an Oracle database is highly specialized, 
> performance-critical, and cannot be shared among multiple 
> servers.  Thus, 
> it is not a good candidate for storage in _any_ remote or distributed 
> filesystem, including AFS.
> 
> -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
>Sr. Research Systems Programmer
>School of Computer Science - Research Computing Facility
>Carnegie Mellon University - Pittsburgh, PA
> 
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] can't force deletion of off-line volume

[Dexter 'Kim7; Kimball]

I thought that if the name of the volume were used as an argument to "vos
zap" that the zap would fail if the volume name couldn't be resolved to an
ID via VLDB  IOW if I use the numeric ID who needs the VLDB, but if I
use the name instead the VLDB entry is required so that the numeric ID can
be obtained??

Kim




> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Derrick 
> J Brashear
> Sent: Friday, March 18, 2005 5:33 PM
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] can't force deletion of off-line volume
> 
> 
> vos zap does talk to the vldb but does not require the volume 
> to be found 
> there
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Question about append-only directories and ownership of files

[Dexter 'Kim7; Kimball]

You don't mention the other half of the ACL.  Who has "wilk" permissions?

In general AFS doesn't care about ownership/mode bits -- ignores them
entirely on directories, but does apply the owner mode bits to all users,
including the owner.  (Doesn't seem relevant here but sometimes good to
know.)

Kim


=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com




> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Thomas M. Payerle
> Sent: Friday, March 18, 2005 6:58 PM
> To: openafs-info@openafs.org
> Subject: [OpenAFS] Question about append-only directories and 
> ownership of files
> 
> 
>   I have a cgi script on a web server writing into an AFS 
> directory with
> ACL rights wilk; i.e. "write" permission set minus the "r".  
> The desired
> intent was to create a directory containing a file which the 
> cgi script can
> append to, but would be unable to read from.
> 
> The above appeared to be working as I expected, until I 
> started testing out
> a replacement web server machine (having a different 
> hostname, thus the 
> httpd.hostname principal is different).  Even when the ACL list in the
> parent (and all ancestral) directories are the same for both 
> instances,
> the "wilk" permission set does not appear to be sufficient 
> for appending
> _UNLESS_ the principal also is the owner of the file (the old 
> server owned
> the files, and so worked without problem).
> 
> It is happy if it has the "r" permission added to the set, 
> and does not
> even change the owner after appending. It also is happy if 
> the owner of the
> file is changed and the "r" permission not added.
> 
> I have tested this out even with simple "echo 'AAA' >> file" 
> type commands,
> so it does not appear to be an artifact of perl.
> 
> As AFS generally tends to be somewhat unconcerned about file 
> ownership in
> most cases, this ownership dependency was unexpected.  I 
> searched some texts
> and the web on AFS ACL rights, and although only one 
> explicitly mentioned
> "append" rights 
> (http://www.engin.umich.edu/caen/technotes/afs.pdf) (stating
> that "w" permission sufficient for that), the more common 
> definition of
> "w" as allowing modification of files content seems 
> consistent with that.
> 
> Is this behavior "expected"?  Am I missing something?  Is 
> there a way in
> AFS to have a file be append-only (possibly with creation if 
> missing, but
> without being "readable") that does not depend on the 
> principal appending
> to the file owning the file?
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] can not change a backup or readonly volume

[Dexter 'Kim7; Kimball]

I'm not sure why you want to create a directory for a fileserver, and assume
you understand that it's not necessary and that you have some reason for
doing so.

Try this:

fs lq /afs/mycell
fs lq /afs/.mycell

I notice in the output you reference:

> >try mounting at /afs/.mycell/etc.  Then release your RW volume.
> 
> ok, so this is my result:
> --
> -
> fs mkmount -dir /afs/mycell/myserver2-afs -vol 536571001 
> -cell mycell; vos release -id 536571001
> fs: You can not change a backup or readonly volume
> Volume 536571001 has no replicas - release operation is meaningless!

You've left out the "." in front of "mycell"

The conventional cell configuration uses an RW mount point at /afs/.mycell

The default behavior of the AFS client is to go to an RO volume from an RO
volume, and the AFS client bases its decision on whether or not there is an
RO entry for the volume in the VLDB entry for that volume.

I suspect that if you "vos listvl root.afs" you'll find that it is
replicated.

This means that the AFS client will automatically go to an RO instance of
root.afs

I also suspect, given your results, that if you "vos listvl root.cell"
you'll find that it is also replicated, and that "fs lsm /afs/mycell" will
reveal that the volume "root.cell" is mounted at /afs/mycell.

If this is all correct, then "fs mkm /afs/mycell -vol " will try to
create a mountpoint in a readonly instance of root.cell and will fail with
the message you're getting.

If the cell was set up in the conventional manner, "fs mkm /afs/.mycell"
will successfully create the mountpoint in the RW instance of root.cell --
mind the "."

Which is what Esther was suggesting.

If /afs/.mycell does not get you to the RW instance of root.cell you'd do
well to create /afs/.mycell -- if this is the case and you're not sure how
to create it, post post again :)

Kim




=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com






> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> [EMAIL PROTECTED]
> Sent: Sunday, March 20, 2005 9:51 AM
> To: openafs-info@openafs.org; [EMAIL PROTECTED]
> Subject: Re: [OpenAFS] can not change a backup or readonly volume
> 
> 
> Esther Filderman <[EMAIL PROTECTED]> wrote:
> 
> >The simplest question is:  is /afs/mycell a RO volume?
> 
> What I'm doing is adding another server to an existing cell.  I'm
> pretty certain the existing cell is RW since I can actually 
> RW to the current server.  The problem is trying to add the 
> other server to the cell.
> 
> >
> >try mounting at /afs/.mycell/etc.  Then release your RW volume.
> 
> ok, so this is my result:
> --
> -
> fs mkmount -dir /afs/mycell/myserver2-afs -vol 536571001 
> -cell mycell; vos release -id 536571001
> fs: You can not change a backup or readonly volume
> Volume 536571001 has no replicas - release operation is meaningless!
> VOLSER: illegal operation
> Error in vos release command.
> VOLSER: illegal operation
> 
> 
> >
> >You cannot mount a volume in a RO clone.
> >
> >
> >On Wed, 16 Mar 2005 10:13:58 -0500, [EMAIL PROTECTED]
> ><[EMAIL PROTECTED]> wrote:
> >> server OS: win2k
> >> client OS: rh9
> >> openafs: 1.77
> >> problem: I get the following error message if I try fs mkmount:
> >> 
> >> [EMAIL PROTECTED] vos listvol -server myserver.edu
> >> Total number of volumes on server myserver.edu partition /vicepg: 1
> >> myserver-afs 536571001 RW  
> 2 K On-line
> >> 
> >> Total volumes onLine 1 ; Total volumes offLine 0 ; Total busy 0
> >> 
> >> [EMAIL PROTECTED] fs mkmount -dir /afs/mycell/myserver-afs 
> -vol 536571001 -cell mycell
> >> fs: You can not change a backup or readonly volume
> >> 
> >> What is the problem here, and how can I fix it?
> >> FYI, the commands above weren't issued from the system 
> where the cell is
> >> located.
> >> 
> >> bob
> >> 
> >> __
> >> Switch to Netscape Internet Service.
> >> As low as $9.95 a month -- Sign up today at 
> http://isp.netscape.com/register
> >> 
> >> Netscape. Just the Net You Need.
> >> 
> >> New! Netscape Toolbar for Internet Explorer
> >> Search from anywhere on the Web and block those annoying pop-ups.
> >> Download now at http://channels.netscape.com/ns/search/install.jsp
> >> ___
> >> OpenAFS-info mailing list
> >> OpenAFS-info@openafs.org
> >> https://lists.openafs.org/mailman/listinfo/openafs-info
> >>
> >___
> >OpenAFS-info mailing list
> >OpenAFS-info@openafs.org
> >https://lists.openafs.org/mailman/listinfo/openafs-info
> >
> 
> __
> Switch to Netscape Internet Service.
> As low as $9.95 a month -- Sign up today at 
>

RE: [OpenAFS] can't force deletion of off-line volume

[Dexter 'Kim7; Kimball]

Have you tried salvaging the volume?



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Matt Elliott
> Sent: Monday, March 21, 2005 9:14 AM
> To: openafs-info@openafs.org; Wes Chow
> Subject: Re: [OpenAFS] can't force deletion of off-line volume
> 
> 
> 
> On Mar 21, 2005, at 9:06 AM, Wes Chow wrote:
> 
> >
> >> Try specifying "-server hippo -partition vicepb -id 
> >> datafiles.20040102 -force"
> >
> > Still no dice:
> >
> > [EMAIL PROTECTED]:~$ vos zap -server hippo -partition /vicepb -id 
> > datafiles.20040102 -force
> > VLDB: no such entry
> > [EMAIL PROTECTED]:~$ vos listvol hippo /vicepb | grep 20040102
> > datafiles.20040102536937070 RW5688181 K Off-line
> 
> Try replacing the "-id datafiles.20040102" with its actual ID.
> 
> vos zap -server hippo -partition /vicepb -id 536937070 -force
> 
> 
> 
> Matt Elliott  Production Systems Infrastructure
> 217-265-0257  
> 
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Oracle Databases...

[Dexter 'Kim7; Kimball]

> 
> 
> Is OpenAFS a good filesystem to run an Oracle database on?

Lousy, actually.  No byte range locking, to begin with.  Other performance
overhead.

IIRC Oracle has its own replication mechanism.

Kim


=
Kim (Dexter) Kimball
CCRE, Inc.
kimkimballjpl.nasa.gov
dhkccre.com



> 
> We are setting up two Sun 880's at the moment.
> 
> Database design has not been done yet, so I am not sure if it 
> will be read or write intensive.
> 
> Is AFS better for a mainly read only filesystem?
> 
> Thanks
> 
> Craig Cook
> --
> Systems Monitoring Consulting and Support Services
> http://www.cookitservices.com
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] vos examine oddity

[Dexter 'Kim7; Kimball]

In this case I'm explicitly examining an RO.  The ID of the RO is correctly
reported 536901459 on the  line -- but in that same record two
lines down the RO volID is "0"

So apparently vos exa does know the RO volID (first line) but it doesn't get
printed (third line) because (beats me ... called from different routine?
gets reset somewhere after it's first populated? elves?)

[EMAIL PROTECTED] kim]$ vos exa root.afs.readonly
root.afs.readonly 536901459 RO 10 K  On-line   
I know the RO volID
magic.lab.ccre.com /vicepa
RWrite  536901458 ROnly  0 Backup  0   
not anymore
MaxQuota   5000 K
CreationFri Jan 28 08:03:29 2005
Last Update Fri Jan 28 08:03:29 2005
0 accesses in the past day (i.e., vnode references)

root.afs.readonly 536901459 RO 10 K  On-line    
angel.lab.ccre.com /vicepaat
least I'm consistent
RWrite  536901458 ROnly  0 Backup  0   
MaxQuota   5000 K
CreationFri Jan 28 08:03:29 2005
Last Update Fri Jan 28 08:03:29 2005
11 accesses in the past day (i.e., vnode references)

RWrite: 536901458 ROnly: 536901459 Backup: 536901460
number of sites -> 3
   server satchmo.lab.ccre.com partition /vicepa RW Site
   server magic.lab.ccre.com partition /vicepa RO Site
   server angel.lab.ccre.com partition /vicepa RO Site

Kim


> > If as far as the volserver is concerned there has never 
> been an ro, it
> > won't have the id for one.
> 
> That answer makes perfect sense but unfortunately doesn't enlighten me
> very much, probably because I don't know enough.  :)  What operations
> would make a volserver aware that there is an RO?  Apparently neither
> having the RO on the same server and partition nor releasing 
> the volume
> are sufficient
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED]) 
> 
> ___
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 


___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Number of user groups one can create

[Dexter 'Kim7; Kimball]

0 is infinity.


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Matt Elliott
> Sent: Monday, November 22, 2004 11:34 AM
> To: [EMAIL PROTECTED]; Derek T. Yarnell
> Subject: Re: [OpenAFS] Number of user groups one can create
> 
> 
> 
> On Nov 22, 2004, at 12:35 PM, Derek T. Yarnell wrote:
> 
> > I thought there was some upper limit on the number of groups a user
> > can create in the pts database. I can not seem to find it in the 
> > documentation now. Does anyone know what this is? Is there anyway 
> > around the it?
> >
> >> From my testing it seems like 20.
> >
> 
> Usage: pts setfields -nameorid + [-access
> ] [-groupquota  creation>] [-cell
> ] [-noauth] [-force] [-help]
> 
> 
> You want to change the groupquota on the specific user.
> 
> 
> 
> Matt Elliott  Production Systems Infrastructure
> 217-265-0257  
> 
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 


___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] Mountpoint to volume map, volume to mountpoint map [was "2 problems for me newbie... "]

[Dexter 'Kim7; Kimball]

I haven't got anything that builds the map.  If anyone else does please
contribute if possible.  

If you

cat  | awk '{print
$6,$9,$NF}' | sed 's/[()]//g'

it will output a file with lines of the form


  A B
C
Volume-containing-mountpoint  path-to-mountpoint-relative-to-root-node-of-A
name-of-volume-mounted-at-B

Example output:

testvolV /W testvolW
testvolV /a/b/c/d/e/f/Z testvolZ

which means "relative to the root node of testvolV I found a mountpoint ./W
to volume testvolW"
and "relative to the root node of testvolV I found a mountpoint
./a/b/c/d/e/f/Z to volume testvolZ"


So if testvolV is mounted at

/afs//testvolV

then you know that

/afs//testvolV/W is a mount point to volume testvolW, or conversely
that testvolW is mounted at /afs//testvolV/W

and that

/afs//testvolV/a/b/c/d/e/f/Z is a mountpoint to volume testvolZ, or
conversely that testvolZ is mounted at /afs//testvolV/a/b/c/d/e/f/Z

I haven't scripted the rest yet, hoping to find that someone else has done
it and can contribute same.  

It shouldn't be necessary to run any vos command to complete the
mountpoint|volume, volume|mountpoint map.

Hope this helps.

Kim



I figured I'd find the rest of the script somewhere
On 9/17/2004 12:36:27 PM, Dave Blakemore ([EMAIL PROTECTED]) wrote:
> Thanks Kim,
> 
> I kinda figured out my problem.
> 
> I am just installing some new afs servers and had added a new one to 
> the cell,  a couple of volumes had been created on the server for test 
> proposes running -showmounts produced no results because the only 
> volumes on the server had no mountpoints within them trying it now on 
> one of my production servers I get the appropriate output, but see it  
> reports on mount points within volumes...  I was hoping for a direct 
> "volume" to "mountpoint" reference rather than "parent volume" to 
> "mountpoint" reference.
> 
> What I am hoping to do, and trying to figure out the best way of doing 
> ...
> 
> is generating is a mountpoint to volume cross reference table such 
> that given a specific volume I can tell where it is mounted.
> 
> The problem was always getting a list of mountpoints.
> Right now I am looking at running salvager -showmounts on all the 
> servers,
> 
> cutting out the mountpoint, combining these outputs from each of the 
> servers, and then doing a vos e on each mountpoint.
> 
> Can you think of a better way?   Do you do anything similar?
> 
> --
> Dave Blakemore
> 
> 
> 

___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] 2 problems for me newbie...

[Dexter 'Kim7; Kimball]

1:52:57 In volume 536871345 (group) found mountpoint ./afs/log
to '#group.afs.logs.'


The "bos salvage" command doesn't have a showmounts option, so either run
/usr/afs/bin/salvager from the command line or alternatively use "bos exec"
followed by "bos getlog"

If you're trying to run using "bos exec" let me know -- I've got it in a
script somewhere and can find the syntax for you.

Kim



> -Original Message-
> From: Dave Blakemore [mailto:[EMAIL PROTECTED] 
> Sent: Friday, September 17, 2004 11:05 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [OpenAFS] 2 problems for me newbie...
> 
> 
> Kim
> 
> Hope you do not mind the direct note...
> I was interested when I saw your append as I would like to 
> build a mount 
> point map.   However trying the -showmounts option to see 
> what info it 
> would provide did not show any mountpoint information in the 
> SalvageLog, I 
> was wondering if I was missing something.   I tried it on the 
> whole server 
> and on a specific volume but got no output. could you 
> send me a 
> sample...
> 
> # cat SalvageLog
> @(#)Base configuration afs3.6 2.53
> 09/17/2004 11:31:13 STARTING AFS SALVAGER 2.4 (/usr/afs/bin/salvager 
> -partition /vicepa -volumeid 1769303090 -showmounts -showlog)
> 
> # vos e  1769303090
> dbonfs1  1769303090 RW  19962 K  On-line
> afsfs1 /vicepa
> RWrite 1769303090 ROnly  0 Backup  0
> MaxQuota 50 K
> CreationFri Sep 17 09:17:18 2004
> Last Update Fri Sep 17 09:24:48 2004
> 42 accesses in the past day (i.e., vnode references)
> 
> RWrite: 1769303090
> number of sites -> 1
>server afsfs1 partition /vicepa RW Site
> 
> thanks
> --
> Dave Blakemore
> 
> 
> 
> 
> "Dexter 'Kim' Kimball" <[EMAIL PROTECTED]> 
> Sent by: [EMAIL PROTECTED]
> 09/17/2004 12:02 PM
> Please respond to
> dhk
> 
> 
> To
> <[EMAIL PROTECTED]>
> cc
> 
> Subject
> RE: [OpenAFS] 2 problems for me newbie...
> 
> 
> 
> 
> 
> 
> Actually, no, the "-showmounts" argument does not cause the 
> fileserver to 
> be
> shut down.  It's a read operation and makes no changes, so there's no 
> need.
> Many cells use it to build a mount point map.
> 
> Daily cron is fine.  It'll spin the disks the vicep's are 
> mounted on so if you're fileservers are near saturation 
> you'll want to run it in off times.
> 
> Kim
> 
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Coffman
> > Sent: Friday, September 17, 2004 8:02 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [OpenAFS] 2 problems for me newbie...
> > 
> > 
> > > I'd use a script.  The "vos release" command doesn't take 
> multiple 
> > > volume name arguments.
> > > 
> > > In general, if you need to find out what volumes are
> > mounted below a
> > > given node in your directory tree in order to recursively
> > vos release
> > > them you can use "bos exec" to run /usr/afs/bin/salvager
> > -showmounts
> > > on each fileserver, redirecting the output to a 
> world-writeable AFS 
> > > directory for convenience.  I can send an example if you'd like.
> > 
> > Doesn't running the salvager this way take down the fileserver?
> > 
> > This is probably not something to be doing in a daily cron, 
> right? ;-)
> > 
> > ___
> > OpenAFS-info mailing list
> > [EMAIL PROTECTED] 
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> > 
> 
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED] 
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 

___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] 2 problems for me newbie...

[Dexter 'Kim7; Kimball]

Actually, no, the "-showmounts" argument does not cause the fileserver to be
shut down.  It's a read operation and makes no changes, so there's no need.
Many cells use it to build a mount point map.

Daily cron is fine.  It'll spin the disks the vicep's are mounted on so if
you're fileservers are near saturation you'll want to run it in off times.

Kim




> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Coffman
> Sent: Friday, September 17, 2004 8:02 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [OpenAFS] 2 problems for me newbie... 
> 
> 
> > I'd use a script.  The "vos release" command doesn't take multiple
> > volume name arguments.
> > 
> > In general, if you need to find out what volumes are
> mounted below a
> > given node in your directory tree in order to recursively
> vos release
> > them you can use "bos exec" to run /usr/afs/bin/salvager
> -showmounts
> > on each fileserver, redirecting the output to a world-writeable AFS
> > directory for convenience.  I can send an example if you'd like.
> 
> Doesn't running the salvager this way take down the fileserver?
> 
> This is probably not something to be doing in a daily cron, right? ;-)
> 
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 

___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] clarification on client caches

[Dexter 'Kim7; Kimball]

I just create a few big files and cat  > /dev/null, rename file,
cat again ... in a loop.

As far as ARLA and larger caches -- I haven't experimented with ARLA so
can't say.

Kim


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Wes Chow
> Sent: Wednesday, September 08, 2004 10:10 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OpenAFS] clarification on client caches
> 
> 
> 
> 
> > May have been covered elsewhere in thread and if so oh 
> well:  are you 
> > filling the cache until it purges?  I.e. did you initialize a 50 GB 
> > cache (in which case a huge number of Vfiles are created 
> and you have 
> > to be careful, at the least, with # of inodes on cache 
> partition); or, 
> > did you initialize and 50 GB cache and write into it until 
> the cache 
> > begins to purge?
> 
> I haven't filled the cache until it purges yet.  Since this 
> is still a testing setup, we don't have 50 gigs worth of data 
> on AFS to test with... (I'm copying files over right now)
> 
> > If you've fully populated a 50GB cache and the consequent cache 
> > purging doesn't cause the AFS client to go catatonic, I'd be very 
> > interested in knowing.
> 
> I'll let you know what I find out...
> 
> Wes
> 
> -- 
> http://www.woahnelly.net/~wes/  OpenPGP key = 0xA5CA6644
> fingerprint = FDE5 21D8 9D8B 386F 128F  DF52 3F52 D582 A5CA 
> 6644 ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED] 
> https://lists.openafs.org/mailman/listinfo/ope> nafs-info
> 

___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] problems configuring openafs on linux

[Dexter 'Kim7; Kimball]

Do you have access to/have you found the AFS "Quick Beginnings"
documentation?

http://www.openafs.org/pages/doc/


This should get you through the basic setup.

Calling an entire nationality "unfriendly" when you don't get what you want,
by the way, is churlish.  It's also a bad way to get help in the future.
Lighten up!

Kim

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Temp
> Sent: Wednesday, April 28, 2004 11:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OpenAFS] problems configuring openafs on linux
>
>
> I guess i come from more frendly Linux user group (www.lugos.org)
> or i guess
> people in .si are just more frendly than you (americans) are.
>
> What is the point of this mailing list existing, if you can't get
> the most
> basic help.
>
> Martin
>
> On Wednesday 28 of April 2004 15:28, Derek Atkins wrote:
> > Temp <[EMAIL PROTECTED]> writes:
> > > I guess people on this list are totaly lame or just plain
> lazy since the
> > > problem was obvius to every openafs nonbeginer.
> >
> > Hey, what do you expect from a free support line?
> >
> > -derek
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info
>


___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

RE: [OpenAFS] /afs does not exist

[Dexter 'Kim7; Kimball]

>
> >Is /afs available on other AFS clients?  That rules out some
> possibilities.
> >
>
> Yes, on some of them. 50% have this problem though.

That's interesting.  One I can understand.  50% gives me a pause ... unless
of course you only have 2 clients :)

>
> >I'd go to a well-behaved client, cd /afs, fs flushv, cd /afs and see if
> >/afs
> >is still available on that client.
>
> Yes, tried this and /afs was still available.
>
> >

> vos exa root.afs gave (on well behaved client):
>
>
> vos exa root.afs.readonly gace:
> >

These are both fine.

I do suggest creating an RO on   "server rsl155 partition /vicepa RW
ite"  -- same server, same partition as RW -- doesn't cost much since such a
RO is COW/clone and will allow rsl155 to be used as an RO failover site.
(Client won't fail over to the RW if it's supposed to get an RO, and when
root.afs is replicated the client will be looking for an RO.)

Are you able to "vos listvl root.afs" from a good client/bad client?

> >
> >rxdebug  7001will give you some info about activity on the
> >AFS
> >client's callback port
>
> On a working client:

Nothing conclusive here, but nothing unexpected either.  rs155 has talked to
a fileserver (apparently itself) and still has an open connection.

>
> rsl55:/afs/.uk.baplc.com# rxdebug rsl55 7001
> Trying 167.156.154.55 (port 7001):
> Free packets: 130, packet reclaims: 0, calls: 101338, used FDs: 64
> not waiting for packets.
> 0 calls waiting for a thread
> 1 threads are idle
> Connection from host 167.156.154.55, port 7000, Cuid 9915c0ac/1817cfe8
>   serial 128760,  natMTU 1444, flags pktCksum, security index 2,
> client conn
>   rxkad: level clear, flags pktCksum
>   Received 271944 bytes in 2518 packets
>   Sent 180088696 bytes in 128706 packets
> call 0: # 2518, state dally, mode: receiving, flags: receive_done
> call 1: # 0, state not initialized
> call 2: # 0, state not initialized
> call 3: # 0, state not initialized
> Done.


While rs156 either hasn't talked to a fileserver recently or at all -- in
any case there's no connection.

?  Someone correct me if I'm wrong ... IIRC the connections to 7001 from
a given fileserver will time out after a period of non use???

>
> On a broekn client:
>
> rsl56:/# rxdebug rsl56 7001
> Trying 167.156.154.56 (port 7001):
> Free packets: 130, packet reclaims: 0, calls: 79437, used FDs: 64
> not waiting for packets.
> 0 calls waiting for a thread
> 1 threads are idle
> Done.
>
>
> >
> >df to see if /afs still appears in the output
>
> /dev/logsarc 9469952   6327480   34%  244 1% /logs/archive
> AFS
> df: /afs: No such file or directory
>

Expected from broken client.

>
> >

> >When was the client last confirmed working correctly?
>
> It was working until 10th April.
>

Is there anything (like a reboot) that happened  oh, I see, it looks
like you're doing the Sunday default fileserver restarts ... judging from
the dates ...

rsl57:/usr/afs/local# ps -ef | grep afs
> > > root 17314 40486   0   11 Apr  -  0:00 /usr/afs/bin/fileserver
> > > root 17686 40486   0   11 Apr  -  0:00 /usr/afs/bin/volserver
> > > root 20134 1   0   08 May  - 17:24 /usr/vice/etc/afsd
> > > -stat 2800
> > > -dcache 2400 -daemons 5 -volumes 128
> > > root 20384 1   0   08 May  - 17:23 /usr/vice/etc/afsd
> > > -stat 2800


How about sending the output from bos status  -long ... for each
fileserver -- or at least telling me when the last restart times were for
each.

Is it possible that all your fileservers restarted at the same time, or that
the two fileservers with root.afs.readonly restarted at the same time, or
were unavailable at the same time?

If so, what were the broken clients doing during the restart?  Might be
worth checking uptime on the broken clients to see if they were restarted
while the fileservers were restarting.

?  Do any of the fs commands (fs checkv or fs checks, e.g.) work on the
client?  I don't know if those are blocked when /afs won't mount or not.
Anyone???

How about fs setcache?  (Gotta be root, and I'd try this on a broken client
you don't care about hurting ... but it might be worth resetting the cache
size to 1, waiting for it to purge, then resetting to 0 -- which restores
the original size.  fs checkv tells the client to refetch info from the VLDB
instead of trusting its cache, but is irrelevant if the unmounted /afs
breaks all the fs commands -- not sure because afsd is running even tho /afs
is broken)

Possibility ... I'm thinking that the broken clients may have tried to mount
/afs (root.afs.readonly) while the fileservers were restarting.  Couldn't
find any root.afs.readonly so failed to mount /afs.  If so, argues for not
restarting all the FS at the same time, and for having root.afs.readonly on
each of your X (how many do you have) fileservers.


Looks like afsd has been up for almost a year?  While AFS fileserver procs
were restarted 11 Apr?  Clients were good on Apr 10 ...

While we're

RE: [OpenAFS] /afs does not exist

[Dexter 'Kim7; Kimball]

Is /afs available on other AFS clients?  That rules out some possibilities.

I'd go to a well-behaved client, cd /afs, fs flushv, cd /afs and see if /afs
is still available on that client.

I'd also be interested in

  vos exa root.afs
  vos exa root.afs.readonly

to see if the root.afs and root.afs.readonly volumes are on line, though if
/afs is available on other clients the output is moot.

rxdebug  7001will give you some info about activity on the AFS
client's callback port

df to see if /afs still appears in the output


You don't mention the debug level of your fileserver.  kill -HUP  will set debug levels to 0 (default).  kill -TSTP bumps one
level per kill -- to levels 1, 5, 25 -- some experiments I've done (but not
yet repeated) indicate some performance impact at debug level 25 but none at
levels 1 or 5.  Not sure if anything would show up so might try this late in
the game.

Create a new volume on the fileserver, mount it, make sure it's accessible.

Check the afsd startup arguments and make sure that

[-rootvol ]
and
[-mountdir ]

don't change the default root volume (root.afs) or default root directory
(/afs).  Unlikely but worth checking pro forma.

afsmonitor -cm  -fs  -freq 5

will tell you if there's any activity on the cache manager/fs ;  you're
probably not interested in -fs if the fileserver is behaving
orrectly.  -freq 5 specifies 5 second update interval instead of the 60 sec
default.  Your mileage may vary.  I like to see numbers change more
frequently than every minute.

When was the client last confirmed working correctly?

Kim


=
Kim (Dexter) Kimball
CCRE, Inc.
afsinfo at ccre dot com





> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of J S
> Sent: Tuesday, April 13, 2004 4:53 AM
> To: [EMAIL PROTECTED]
> Subject: [OpenAFS] /afs does not exist
>
>
> Hi,
>
> I'm having problems getting in to the /afs directory on an AIX
> box and I'm
> not sure how to fix it:
>
> # cd /afs
> ksh: /afs:  not found.
>
> This has been running fine until now though. The processes are still
> running:
>
> rsl57:/usr/afs/local# ps -ef | grep afs
> root 17314 40486   0   11 Apr  -  0:00 /usr/afs/bin/fileserver
> root 17686 40486   0   11 Apr  -  0:00 /usr/afs/bin/volserver
> root 20134 1   0   08 May  - 17:24 /usr/vice/etc/afsd
> -stat 2800
> -dcache 2400 -daemons 5 -volumes 128
> root 20384 1   0   08 May  - 17:23 /usr/vice/etc/afsd
> -stat 2800
> -dcache 2400 -daemons 5 -volumes 128
> ..
> ..
> root 40486 1   0   11 Apr  -  0:00 /usr/afs/bin/bosserver
>
> And the logs look normal. I can ping the AFS server also.
>
> Is there anything else I can try?
>
> Thanks for any help.
>
> JS.
>
> _
> It's fast, it's easy and it's free. Get MSN Messenger today!
> http://www.msn.co.uk/messenger
>
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info
>


___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Knfs doesn't work on an AFS/NFS translator under OpenAFS

[Dexter 'Kim7; Kimball]

Didn't the VLDB format change to accomodate multi-homed fileservers around
3.3?

I thought that was part of the 3.3-3.4 transition??

Kim
---
Kim Kimball


> Derek Atkins <[EMAIL PROTECTED]> writes:
> > Russ Allbery <[EMAIL PROTECTED]> writes:
>
> >> Don't you have AFS for NeXT?  When we had NeXT systems in the main
campus,
> >> we just ran AFS on them natively.
>
> > That was back around AFS 3.x for x < 4.  I don't think it's still
> > supported, and I *KNOW* that OpenAFS doesn't support NeXT.
>
> Nothing's broken AFS 3.3 so far as I know.  I'm still running it on one
> system.
>
> --
> Russ Allbery ([EMAIL PROTECTED]) 
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info

___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] poor out of cache behavior on writing

[Dexter \"Kim\" Kimball]

>I wonder if something as simple as "track the total bytes written to a
>particular file while that file is currently open, once it exceeds x% of
>the cache, bypass" would perform reasonably?

Is the write behavior necessarily this dependent on cache size alone?  I'm
speculating that cache state would be relevant.

If I've got a large empty cache or mostly unused cache, do I get the same
write performance as with an about-to-purge-I'm-full cache?

Or might there be a dependency on the number/percentage of dirty chunks ...
those have got to be flushed back to the fileserver before they can be
reclaimed, so the worst case might be a large cache with lots of dirty
chunks from lots of small files.

I've only been "bothered" by the write performance limitations once or
twice -- when continuously and rapidly writing/closing/opening an output
file from an "indexer" into AFS filespace.  Indexing software was
proprietary, couldn't get vendor to change it  so finally moved the
output file outside of AFS -- automatically moved it back when the indexing
was complete.

It took a while to figure out what the bottleneck was, though, and it would
by all means be great to have a reasonable bypass algorithm.  Or even the
ability to tag a file/directory/volume/partition as "don't cache."   Which
again presupposes the willingness to identify the file/directory/...


- Original Message -
From: "Neulinger, Nathan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 17, 2003 4:24 PM
Subject: RE: [OpenAFS] poor out of cache behavior on writing


I wonder if something as simple as "track the total bytes written to a
particular file while that file is currently open, once it exceeds x% of
the cache, bypass" would perform reasonably?

It wouldn't help the small cases.

Another possible scenario would be assume bypass until the file has been
read once. That would cause all initial creates to bypass, but later
appends/edits would return to normal speed.


Nathan Neulinger   EMail:  [EMAIL PROTECTED]
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services   Fax: (573) 341-4216


> -Original Message-
> From: Derrick J Brashear [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 17, 2003 5:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OpenAFS] poor out of cache behavior on writing
>
>
> On Mon, 17 Feb 2003, Paul Blackburn wrote:
>
> > You probably will get better data transfer from ftp-client
> => ftp-server
> > than a distributed filesystem.
>
> This, at least, is a protocol. scp is a hack, which is why
> I'm reluctant
> to use it.
>
> > When it comes to "uploading" large datafiles from machine
> to machine,
> > I now prefer using SSH's scp which shows me a progress bar and ETA.
> >
> > For most all other tasks, I like AFS which gives me other
> capabilities
> > unheard of in NFS.
>
> I wonder if we could find a sucker^H^H^H^H^H^Hgrad student to
> figure out
> ("guess") when to bypass the cache and when to use it, and
> incorporate it
> (at least as an option) in the clients.
>
> I know CITI has done cache-bypass stuff, but it used the
> volume name (I
> think) as a hint.
>
>
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] poor out of cache behavior on writing

[Dexter \"Kim\" Kimball]

You might try using afsmonitor to inspect the client's behavior when you
write the 2x file to the 1x cache.

After the cache fills, you should see the cache
filling/purging/filling/purging in a short cycle.  "Cache files in use" vs.
Cache files free (inexact terminology).

This won't fix the performance you describe, but may give you some idea of
what the client is doing that is causing CPU loads.

Haven't done this recently, but under Transarc/IBM AFS 3.5 I played with
cache sizes to see what behavior to expect at the client.

Results will vary by platform/resources and probably by sizes of files being
cached.

You're describing behavior of a large file into a small cache.  I used lots
of small (average size 5K or so) into a very large cache.

The machine I was using (some flavor of mid-range HPUX server with about 0.5
GB RAM and fast disk storage) _appeared_ to hang when cache sizes were very
large (8-12 GB on that platform).  That is, any processing on the machine
seemed to stop entirely.

Using AFS monitor I was able to see that the resources were being consumed
in cache purging.  Cache fills up (machine behavior OK), cache files in use
start decreasing (cache is purging, machine is essentially dead for any
other purpose).  With the large numbers of small files to be purged, AFS
essentially consumed all of the CPU resources.

It seems that cache garbage collection has some limitations when asked to
fill/purge in a short cycle.

By the way, if you're going to routinely be reading/writing large files
sequentially, you may want to experiment with AFS cache chunk size.

WRT AFS vs. NFS, I believe that in 1) a local area network with 2) a lot of
write activity, the caching overhead of AFS is a liability.  (Write to local
disk cache, read from local disk cache, network to fileserver, write to
fileserver disk.)

Not sure what the current status is, but did experiment extensively with AFS
memory caching.  (Write to local memory cache, read from memory cache,
network to fileserver, write to fileserver disk.)  The speed advantages were
quite significant.  At the time, however, I couldn't get decent stability
from either HPUX platforms or AIX platforms when caching to memory.

Your mileage may vary.

Kim
---------------
Dexter "Kim" Kimball
CCRE, Inc.
[EMAIL PROTECTED]


- Original Message -
From: "Garance A Drosihn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, February 16, 2003 7:36 PM
Subject: Re: [OpenAFS] poor out of cache behavior on writing


> At 5:01 PM -0800 2/16/03, [EMAIL PROTECTED] wrote:
> >nfs 0.120u  21.030s  4:19.47  8.1%
> >afs 0.5G cache  0.100u 517.330s 10:49.84 79.6%
> >afs 2GB cache   0.060u  20.570s  4:49.58  7.1%
> >
> >In these tests, I copy a 1 GB file from the client to the server.
> >In both NFS and AFS cases, I use the same client and server machines.
> >
> >Notice that with the 0.5 GB cache, it takes about 2.5x longer to
> >copy the file, and consumes almost 80% of the CPU, mostly in system
> >time.The 2 GB cache case is more reasonable, taking just
> >slightly longer than NFS.
>
> Notice that your cache is half the size of the file you're trying
> to copy.  In the past we at RPI have noticed that AFS performance
> is bad if the machine has a cache size that is smaller than a
> file you want to work on.
>
> --
> Garance Alistair Drosehn=   [EMAIL PROTECTED]
> Senior Systems Programmer   or  [EMAIL PROTECTED]
> Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
> ___
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info
>

___
OpenAFS-info mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-info