From thomas.mueller@hrz.tu-chemnitz.de Fri Feb 1 06:12:17 2002 From: thomas.mueller@hrz.tu-chemnitz.de (Thomas Mueller) Date: Fri, 1 Feb 2002 07:12:17 +0100 (MET) Subject: [OpenAFS-devel] callback handling problem In-Reply-To: <3C597D5E.352A8E5E@rzg.mpg.de> Message-ID: On Thu, 31 Jan 2002, Hartmut Reuter wrote: > > In older versions of callback.c was no "if ( !" around the call to > ClearHostCallbacks_r. Therefore the loop was left. I suppose we need a > line > > hp1 = hp; > Yes, I agree, this should break the loop. Thank you. I've installed the changed code on our fileservers. Thomas. -- ------------------------------------------------------------------------- Thomas Mueller, TU Chemnitz, Universitaetsrechenzentrum, D-09107 Chemnitz e-mail: Thomas.Mueller@hrz.tu-chemnitz.de ----------------------------------------------------------------------- From u85021@ice.ntnu.edu.tw Fri Feb 1 08:12:29 2002 From: u85021@ice.ntnu.edu.tw (=?big5?B?s6+kubh0?=) Date: Fri, 1 Feb 2002 16:12:29 +0800 Subject: [OpenAFS-devel] Can I fetch some appointed files whenerver I log in? Message-ID: <016201c1aaf8$31ad0b00$803e7a8c@yschengwin2k> This is a multi-part message in MIME format. ------=_NextPart_000_015F_01C1AB3B.3F6246F0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, falks: Can I fetch some appointed files whenever I log in AFS client? That is = when I log in some AFS client, I can fetch some appointed files to save = file transfer time. Just because the appointed files usually are used, = so I want to prefetch them when I log in to AFS client. When I want to = use these files, I can access them immediately without waiting. ------=_NextPart_000_015F_01C1AB3B.3F6246F0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Hi, falks:

Can I fetch some appointed files whenever I log in = AFS client?=20 That is when I log in some AFS client, I can fetch some appointed files = to save=20 file transfer time. Just because the appointed files usually are used, = so I want=20 to prefetch them when I log in to AFS client. When I want to use these = files, I=20 can access them immediately without waiting.

------=_NextPart_000_015F_01C1AB3B.3F6246F0-- From balsa@vectra.startv.hu Fri Feb 1 09:42:36 2002 From: balsa@vectra.startv.hu (Balazs GAL) Date: 01 Feb 2002 10:42:36 +0100 Subject: [OpenAFS-devel] Re: [OpenAFS] pagsh and big uid with linux In-Reply-To: References: <1011104898.3697.0.camel@vpn65.ece.cmu.edu> <1012515929.28874.0.camel@balcsi> <1012518274.28930.2.camel@balcsi> <1012520304.28906.6.camel@balcsi> Message-ID: <1012556559.28930.10.camel@balcsi> 2002-02-01, F Derek Atkins wrote: Hi ! > In all my years of using AFS I have NEVER seen these be 'real' groups. The groups are in the /etc/group file before i call setpag(). I can read and write files. Only I can't unlink files. > Sure, you can shoot yourself in the foot by trying to force the issue, > but why? > > There is a saying in the US: A patient goes to the Doctor and says, > "Doctor, Doctor, it hurts when I do this." The Doctor responds, "Don't > do that." This was not only an ugly demo. I really have group id-s in this range. But this is only test: www:/etc# grep test8 /etc/group test8:x:44302: www:/etc# echo "This IS the big secret" > /etc/big_secret www:/etc# chown root:test8 /etc/big_secret www:/etc# chmod 660 /etc/big_secret www:/etc# ls -al /etc/big_secret -rw-rw---- 1 root test8 23 Feb 1 10:26 /etc/big_secret www:/etc# su balsa balsa@www:/etc$ id uid=60004(balsa) gid=100(users) ,100(users),102(doksi),1015(ftpssl),1022(tanszek) balsa@www:/etc$ pagsh balsa@www:/etc$ id uid=60004(balsa) gid=100(users) groups=33892,44302(test8),100(users),102(doksi),1015(ftpssl),1022(tanszek) balsa@www:/etc$ cat /etc/big_secret This IS the big secret balsa@www:/etc$ cat >> /etc/big_secret This WAS the big secret ^D balsa@www:/etc$ cat /etc/big_secret This IS the big secret This WAS the big secret balsa@www:/etc$ exit balsa@www:/etc$ exit www:/etc# ls -al /etc/big_secret -rw-rw---- 1 root test8 47 Feb 1 10:28 /etc/big_secret www:/etc# ls -al / total 100 drwxr-xr-x 20 root root 4096 Dec 4 19:09 . drwxr-xr-x 20 root root 4096 Dec 4 19:09 .. [...] drwxr-xr-x 57 root root 4096 Feb 1 10:26 etc [...] www:/etc# This is not a joke. I don't belive it that this is normal. balsa From openafs-info@openafs.org Fri Feb 1 15:18:41 2002 From: openafs-info@openafs.org (Derek Atkins) Date: 01 Feb 2002 10:18:41 -0500 Subject: [OpenAFS-devel] Re: [OpenAFS] pagsh and big uid with linux In-Reply-To: <1012556559.28930.10.camel@balcsi> References: <1011104898.3697.0.camel@vpn65.ece.cmu.edu> <1012515929.28874.0.camel@balcsi> <1012518274.28930.2.camel@balcsi> <1012520304.28906.6.camel@balcsi> <1012556559.28930.10.camel@balcsi> Message-ID: This is normal behavior for AFS. It has always done this. -derek PS: Why do you have so many groups? Perhaps if you move to AFS then you can move all your "groups" into AFS groups and then you can remove them from /etc/group? -derek Balazs GAL writes: > 2002-02-01, F Derek Atkins wrote: > > Hi ! > > > In all my years of using AFS I have NEVER seen these be 'real' groups. > > The groups are in the /etc/group file before i call > setpag(). > > I can read and write files. Only I can't unlink files. > > > Sure, you can shoot yourself in the foot by trying to force the issue, > > but why? > > > > There is a saying in the US: A patient goes to the Doctor and says, > > "Doctor, Doctor, it hurts when I do this." The Doctor responds, "Don't > > do that." > > This was not only an ugly demo. I really have group id-s in this range. > > But this is only test: > > www:/etc# grep test8 /etc/group > test8:x:44302: > www:/etc# echo "This IS the big secret" > /etc/big_secret > www:/etc# chown root:test8 /etc/big_secret > www:/etc# chmod 660 /etc/big_secret > www:/etc# ls -al /etc/big_secret > -rw-rw---- 1 root test8 23 Feb 1 10:26 /etc/big_secret > www:/etc# su balsa > balsa@www:/etc$ id > uid=60004(balsa) gid=100(users) > ,100(users),102(doksi),1015(ftpssl),1022(tanszek) > balsa@www:/etc$ pagsh > balsa@www:/etc$ id > uid=60004(balsa) gid=100(users) > groups=33892,44302(test8),100(users),102(doksi),1015(ftpssl),1022(tanszek) > balsa@www:/etc$ cat /etc/big_secret > This IS the big secret > balsa@www:/etc$ cat >> /etc/big_secret > This WAS the big secret > ^D > balsa@www:/etc$ cat /etc/big_secret > This IS the big secret > This WAS the big secret > balsa@www:/etc$ exit > balsa@www:/etc$ exit > www:/etc# ls -al /etc/big_secret > -rw-rw---- 1 root test8 47 Feb 1 10:28 /etc/big_secret > www:/etc# ls -al / > total 100 > drwxr-xr-x 20 root root 4096 Dec 4 19:09 . > drwxr-xr-x 20 root root 4096 Dec 4 19:09 .. > [...] > drwxr-xr-x 57 root root 4096 Feb 1 10:26 etc > [...] > www:/etc# > > > This is not a joke. > I don't belive it that this is normal. > > balsa > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From openafs-devel" References: <016201c1aaf8$31ad0b00$803e7a8c@yschengwin2k> Message-ID: AFS will not do this on its own. However, you can write your login scripts to try to pre-fetch the files. For example, cat /afs/cell/file/to/cache/1 > /dev/null & cat /afs/cell/file/to/cache/2 > /dev/null & cat /afs/cell/file/to/cache/3 > /dev/null & This will pull the file into the cache "in the background". I'm not sure why you want to do this, unless the connection between your client and server is REALLY SLOW (like 56k) or very high latency (like a satellite). I find that my login time (with my home directory in AFS) is based more on processor speed and machine memory than on AFS delays, until my network gets really slow. -derek =B3=AF=A4=B9=B8t writes: > Hi, falks: > Can I fetch some appointed files whenever I log in AFS client? That is wh= en I log in some AFS client, I can fetch some appointed files to save file = transfer time. Just because the appointed files usually are used, so I want= to prefetch them when I log in to AFS client. When I want to use these fil= es, I can access them immediately without waiting. >=20 --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nneul@umr.edu Fri Feb 1 15:58:24 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 09:58:24 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: (I've been doing alot of diagnosis attempting to improve our AFS cell, = that's why the stream of lots of these notes.) We just had a client start to experience continual 'waiting for busy = volume' messages against two volumes on a server that is not very = loaded. I've got a network trace of communications w/ that = client+server, and what's going on is the client is sending two = FetchStatus requests (one against each volume), and the server is = sending back a RX abort packet. Nothing but that over and over again. Any idea what could be causing this? In the fileserver logs, I'm not seeing anything specific to that client. We're going to be upgrading file servers to more recent code very = shortly, if there is any instrumentation y'all think it would be worth = adding before I do that, please speak up, cause now is the time I can = add it reasonably. (We're clearing servers then upgrading os and afs = install.) -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From kenh@cmf.nrl.navy.mil Fri Feb 1 16:08:29 2002 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 01 Feb 2002 11:08:29 -0500 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state In-Reply-To: Your message of "Fri, 01 Feb 2002 09:58:24 CST." Message-ID: <200202011608.g11G8VG03414@ginger.cmf.nrl.navy.mil> >(I've been doing alot of diagnosis attempting to improve our AFS cell, that's >why the stream of lots of these notes.) > >We just had a client start to experience continual 'waiting for busy volume' >messages against two volumes on a server that is not very loaded. I've got >a network trace of communications w/ that client+server, and what's going on >is the client is sending two FetchStatus requests (one against each volume), >and the server is sending back a RX abort packet. Nothing but that over >and over again. What's the error code from the abort packet? That should tell you _something_. --Ken From nneul@umr.edu Fri Feb 1 16:15:14 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 10:15:14 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: Hmm... I must not be decoding the abort type packet completely. If the = error code is the 4-byte integer after the Service ID, then it is = 0x0000006E, or 110. I didn't see any mention of that in the rx_packet = structure though.=20 The trace is tiny if you want it.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 > Sent: Friday, February 01, 2002 10:08 AM > To: Neulinger, Nathan > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] RX abort packets, and client=20 > sitting in "waiting for busy volume" state=20 >=20 >=20 > >(I've been doing alot of diagnosis attempting to improve our=20 > AFS cell, that's > >why the stream of lots of these notes.) > > > >We just had a client start to experience continual 'waiting=20 > for busy volume' > >messages against two volumes on a server that is not very=20 > loaded. I've got > >a network trace of communications w/ that client+server, and=20 > what's going on > >is the client is sending two FetchStatus requests (one=20 > against each volume), > >and the server is sending back a RX abort packet. Nothing=20 > but that over > >and over again. >=20 > What's the error code from the abort packet? That should=20 > tell you _something_. >=20 > --Ken >=20 From nneul@umr.edu Fri Feb 1 16:38:34 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 10:38:34 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 > Sent: Friday, February 01, 2002 10:20 AM > To: Neulinger, Nathan > Subject: Re: [OpenAFS-devel] RX abort packets, and client=20 > sitting in "waiting for busy volume" state=20 >=20 >=20 > >Hmm... I must not be decoding the abort type packet completely. >=20 > That's what you get from using an "inferior" packet decoder :-) Change has been committed to CVS to correct that problem. > >If the error code is the 4-byte integer after the Service=20 > ID, then it is > >0x0000006E, or 110. I didn't see any mention of that in the rx_packet > >structure though.=20 >=20 > I think I figured that out from examining the code and/or the=20 > packet trace > (because I knew there was an error code in there somewhere). Yeah, looks to be in SendSpecial where the data is appended. For abort = packets, the data is the abort code. > I'm not sure what error code 110 on your system ... I think=20 > you're going > to have to grovel through your system's sys/errno.h, figure out what > that is, and what would make the fileserver ever return that. It's linux on a 2.2.x kernel on redhat62: infinity(50)>grep 110 /usr/include/asm/errno.h #define ETIMEDOUT 110 /* Connection timed out */ I'm not sure why fileserver would return that, but I'll take a look. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Fri Feb 1 18:13:11 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 12:13:11 -0600 Subject: [OpenAFS-devel] Changing RXDEADTIME... MUCH better failover for RO vols... Message-ID: Further testing with the killall -STOP fileserver/volserver stuff. = Changing RXDEADTIME to 10 seconds instead of 50 seconds made a huge = improvement in the failover time. I'm not sure what negative effects = this will have. It looks to take 2 * RXDEADTIME for it to detect server = failure, but that's just from rough looking at it. Anyone with history know the logic behind the current timing choices? I'd prefer to adjust for just RO volume access, but that will involve a = bit more than just a parameter change. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From kolya@MIT.EDU Fri Feb 1 20:49:42 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Fri, 01 Feb 2002 15:49:42 -0500 Subject: [OpenAFS-devel] Same problem in a different place. Message-ID: <200202012049.PAA29007@pepsi-one.mit.edu> > Actually, since afs_osi_Sleep() and CV_WAIT() are used so frequently, it > might be easier to make just make two new calls: > > int afs_osi_SleepHonorSig(char *event, int aintrok); > int CV_WAIT_HONORSIG(afs_kcondvar_t *cv, afs_kmutex_t *l, int aintrok) I've just commited code to CVS which does basically that. The two new sleep functions are: int afs_osi_SleepSig(char *event); int CV_WAIT_SIG(afs_kcondvar_t *cv, afs_kmutex_t *l); They return EINTR if interrupted by a signal, and 0 otherwise. They're actually implemented for Linux and Solaris, and are wrappers around the existing non-interruptable functions on all other platforms. I've also made afs_UFSRead() interruptible, at least in the case when the work is being done by a background daemon, just to make sure all this works. My one concern at this point is signal handlers with SA_RESTART: some limited testing on my 2.4.17 Linux box indicates that the system call isn't being restarted, and returns when the signal is delivered, rather than restarting. Do you happen to know how SA_RESTART is supposed to work inside the kernel? -- kolya From shadow@dementia.org Fri Feb 1 21:59:12 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 1 Feb 2002 16:59:12 -0500 (EST) Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state In-Reply-To: Message-ID: On Fri, 1 Feb 2002, Neulinger, Nathan wrote: > We just had a client start to experience continual 'waiting for busy volume' messages against two volumes on a server that is not very loaded. I've got a network trace of communications w/ that client+server, and what's going on is the client is sending two FetchStatus requests (one against each volume), and the server is sending back a RX abort packet. Nothing but that over and over again. > > Any idea what could be causing this? Depends; What version are you running on them? A bug which could cause that was fixed in (I think) 1.2.2 after Jimmy Engelbrecht complained about his Arla clients suffering from it; Clients were not being properly reaped by the fileserver. > We're going to be upgrading file servers to more recent code very > shortly, if there is any instrumentation y'all think it would be worth > adding before I do that, please speak up, cause now is the time I can > add it reasonably. (We're clearing servers then upgrading os and afs > install.) Why not try the upgrade first, then worry about instrumentation if you still have a problem? -D From nneul@umr.edu Fri Feb 1 22:07:13 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 16:07:13 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: Primarily cause I can't easily add the instrumentation afterwards = without a major hassle. Right now, it's convenient for me to take the server = down,=20 later it won't be. They should all be running relatively current code (within 3-5 months of = today) for the clients, but June'ish for the servers.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derrick J Brashear [mailto:shadow@dementia.org]=20 > Sent: Friday, February 01, 2002 3:59 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] RX abort packets, and client=20 > sitting in "waiting for busy volume" state >=20 >=20 > On Fri, 1 Feb 2002, Neulinger, Nathan wrote: >=20 > > We just had a client start to experience continual 'waiting=20 > for busy volume' messages against two volumes on a server=20 > that is not very loaded. I've got a network trace of=20 > communications w/ that client+server, and what's going on is=20 > the client is sending two FetchStatus requests (one against=20 > each volume), and the server is sending back a RX abort=20 > packet. Nothing but that over and over again. > >=20 > > Any idea what could be causing this? >=20 > Depends; What version are you running on them? A bug which could cause > that was fixed in (I think) 1.2.2 after Jimmy Engelbrecht=20 > complained about > his Arla clients suffering from it; Clients were not being=20 > properly reaped > by the fileserver. >=20 > > We're going to be upgrading file servers to more recent code very > > shortly, if there is any instrumentation y'all think it=20 > would be worth > > adding before I do that, please speak up, cause now is the=20 > time I can > > add it reasonably. (We're clearing servers then upgrading os and afs > > install.) >=20 > Why not try the upgrade first, then worry about instrumentation if you > still have a problem? >=20 > -D >=20 >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Fri Feb 1 22:13:25 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 1 Feb 2002 17:13:25 -0500 (EST) Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state In-Reply-To: Message-ID: On Fri, 1 Feb 2002, Neulinger, Nathan wrote: > Primarily cause I can't easily add the instrumentation afterwards without > a major hassle. Right now, it's convenient for me to take the server down, > later it won't be. > > They should all be running relatively current code (within 3-5 months of today) > for the clients, but June'ish for the servers. Well, this is a server-side fix, and since I remember working on it at the Arla hackathon I know it wasn't done in June:-) -D From nneul@umr.edu Tue Feb 5 16:54:53 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 5 Feb 2002 10:54:53 -0600 Subject: [OpenAFS-devel] What is BUGFIX_1165 Message-ID: There are a bunch of instances of code ifdef'd with ENABLE_BUGFIX_1165 = in volser/vsprocs.c. What is that about? If it isn't something that was decided to be = enabled, would it make sense to remove that code?=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Tue Feb 5 17:06:14 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 5 Feb 2002 11:06:14 -0600 Subject: [OpenAFS-devel] re-indenting code... Message-ID: At times, digging through some of the older code (ie. vsprocs.c), it is = very hard to read due to the veyr inconsistent (and sometimes completely = absent) indentation. I'd like to re-indent some of it, however I hate to make my local = checkout that different from the repository, cause it makes any = potential diffs that much less likely to be accepted. (i.e. it would be = easier to work on locally if it were re-indented, but I don't want to do = that if it means I have to hand-rewrite the diff to be suitable for = application.) Would developers be willing to come up with a indent config file that = would be an accepted re-indentation of the code? I don't think we'd = necessarily want to do that to everything, just to specific files as = they are worked on. I personally would like to see this: -cli4 -di0 -nbc -nlp -bad -sob -bap -bl0 -bli0 -cs -npcs -ncdb -nsc -ci0 -i4 -ip0 -npsl -ts4 but I'm sure others have different preferences. It doesn't really matter = much to me, but SOME sort of indentation would make things alot easier = to read than the current code. Derrick, would you accept a diff that did nothing other than reformat = certain files? Ideally, if there were a indent config file preference, it would be = checked into cvs somewhere, or as a helper script that passed all the = desired options.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Tue Feb 5 19:57:16 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 5 Feb 2002 13:57:16 -0600 Subject: [OpenAFS-devel] problems with vos move... Message-ID: I started digging into a problem we've had with vos move for a long = time... Occasionally on large (sometimes not) volumes, we get a failure = in the dump. I added a bunch more debugging to the verbose vos move, and = here is what I get: infinity(16)>/tmp/vos move res.kumar.students afs4 a afs8 a -verbose Locking VLDB entry for volume 536925133 ... done Starting transaction on source volume 536925133 ... done Allocating new volume id for clone of volume 536925133 ... done Cloning source volume 536925133 ... done Ending the transaction on the source volume 536925133 ... done Starting transaction on the cloned volume 537065258 ... done Setting flags on cloned volume 537065258 ... done Getting status of cloned volume 537065258 ... done Creating the destination volume 536925133 ... done Setting volume flags on destination volume 536925133 ... done Dumping from clone 537065258 on source to volume 536925133 on = destination ...Failed to move data for the volume 536925133 Possible communication failure vos move: operation interrupted, cleanup in progress... clear transaction contexts Recovery: Releasing VLDB lock on volume 536925133 ... done Recovery: Ending transaction on clone volume ... Note - There are two problems, first, the failure in the dump (Forward), = and second, that it is hanging when ending transaction on the cloned = volume.=20 Unfortunately, it looks like I will have to start watching the volserver = itself to see if I can determine the reason for the dump failure. Is it = possible that some sort of timeout is being exceeded some how?=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Wed Feb 6 15:30:41 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 6 Feb 2002 09:30:41 -0600 Subject: [OpenAFS-devel] scary vos remove message... Message-ID: This definately needs reworked: infinity(1)>vos remove afs8 c res.kumar.students -verbose res.kumar.students=20 RWrite: 536925133 Backup: 536925135=20 number of sites -> 1 server afs8.cc.umr.edu partition /vicepa RW Site=20 Trying to delete the volume 536925133 ... That is always scary even when you know it isn't saying what it looks = like it's saying.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Wed Feb 6 14:27:31 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Wed, 6 Feb 2002 08:27:31 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose Message-ID: <20020206142729.GA6654@umr.edu> --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Also removes the "WARNING" from "WARNING : removing backup volume on source", which really doesn't need to be a warning since it's completely expected, and you can't back out at that point any way. A vos move -verbose looks like this now: ------ infinity(3)>/tmp/vos move sw.tnsnames afs2 a afs2 b -verbose Locking VLDB entry for volume 536977586 ... done Starting transaction on source volume 536977586 ... done Allocating new volume id for clone of volume 536977586 ... done Cloning source volume 536977586 ... done Ending the transaction on the source volume 536977586 ... done Starting transaction on the cloned volume 537067336 ... done Setting flags on cloned volume 537067336 ... done Getting status of cloned volume 537067336 ... done Creating the destination volume 536977586 ... done Setting volume flags on destination volume 536977586 ... done Dumping from clone 537067336 on source to volume 536977586 on destination ... done Ending transaction on cloned volume 537067336 ... done Starting transaction on source volume 536977586 ... done Doing the incremental dump from source to destination for volume 536977586 ... done Setting volume flags on old source volume 536977586 ... done Setting volume flags on new source volume 536977586 ... done Ending transaction on destination volume 536977586 ... done Releasing lock on VLDB entry for volume 536977586 ... done Deleting old volume 536977586 on source ... done Ending transaction on old volume 536977586 on the source ... done Creating transaction for backup volume 536977588 on source ... done No backup volume exists on source. Ignoring. Starting transaction on the cloned volume 537067336 ... done Deleting the clone 537067336 ... done Ending transaction on clone volume 537067336 ... done WARNING : readOnly copies still exist Volume 536977586 moved from afs2 /vicepa to afs2 /vicepb ------ There are also more "what's happening" diagnostics during recovery and cleanup operations. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vos-move-more-diag.diff" Index: vsprocs.c =================================================================== RCS file: /cvs/openafs/src/volser/vsprocs.c,v retrieving revision 1.10 diff -u -r1.10 vsprocs.c --- vsprocs.c 2001/10/08 22:55:41 1.10 +++ vsprocs.c 2002/02/06 14:24:01 @@ -567,7 +567,7 @@ /* create the vldb entry */ vcode = VLDB_CreateEntry(&storeEntry); if(vcode) { - fprintf(STDERR,"Could not create a VLDB entry for the volume %s %u\n", aname,aid); + fprintf(STDERR,"Could not create a VLDB entry for the volume %s %u\n", aname,aid); error = vcode; goto cfail; } @@ -836,34 +836,38 @@ } #define ONERR(ec, es, ep) if (ec) { fprintf(STDERR, (es), (ep)); PrintError(" ",ec); error = (ec); goto mfail; } +#define VPRINT(es) if (verbose) { fprintf(STDOUT, (es)); fflush(STDOUT); } +#define VPRINT1(es, vol) if (verbose) { fprintf(STDOUT, (es), (vol)); fflush(STDOUT); } +#define VPRINT2(es, vol1, vol2) if (verbose) { fprintf(STDOUT, (es), (vol1), (vol2)); fflush(STDOUT); } +#define VDONE if (verbose) { fprintf(STDOUT, " done\n"); fflush(STDOUT); } /* Move volume on to * . The operation is almost idempotent */ UV_MoveVolume(afromvol, afromserver, afrompart, atoserver, atopart) - afs_int32 afromvol; - afs_int32 afromserver, atoserver; - afs_int32 afrompart, atopart; +afs_int32 afromvol; +afs_int32 afromserver, atoserver; +afs_int32 afrompart, atopart; { - struct rx_connection *toconn, *fromconn ; - afs_int32 fromtid, totid, clonetid; - char vname[64]; - char *volName = 0; - char tmpName[VOLSER_MAXVOLNAME +1]; - afs_int32 rcode; - afs_int32 fromDate; + struct rx_connection *toconn, *fromconn; + afs_int32 fromtid, totid, clonetid; + char vname[64]; + char *volName = 0; + char tmpName[VOLSER_MAXVOLNAME + 1]; + afs_int32 rcode; + afs_int32 fromDate; struct restoreCookie cookie; - register afs_int32 vcode, code; - afs_int32 newVol, volid, backupId; + register afs_int32 vcode, code; + afs_int32 newVol, volid, backupId; struct volser_status tstatus; - struct destServer destination; + struct destServer destination; - struct nvldbentry entry, storeEntry; - int i, islocked, pntg; - afs_int32 error; - char in,lf; /* for test code */ - int same; + struct nvldbentry entry, storeEntry; + int i, islocked, pntg; + afs_int32 error; + char in, lf; /* for test code */ + int same; #ifdef ENABLE_BUGFIX_1165 volEntries volumeInfo; @@ -871,211 +875,273 @@ #endif islocked = 0; - fromconn = (struct rx_connection *)0; - toconn = (struct rx_connection *)0; - fromtid = 0; - totid = 0; + fromconn = (struct rx_connection *) 0; + toconn = (struct rx_connection *) 0; + fromtid = 0; + totid = 0; clonetid = 0; - error = 0; - volid = 0; - pntg = 0; + error = 0; + volid = 0; + pntg = 0; backupId = 0; - newVol = 0; + newVol = 0; /* support control-c processing */ - if (setjmp(env)) goto mfail; - (void) signal(SIGINT,sigint_handler); - + if (setjmp(env)) + goto mfail; + (void) signal(SIGINT, sigint_handler); + if (TESTC) { fprintf(STDOUT, - "\nThere are three tests points - verifies all code paths through recovery.\n"); - fprintf(STDOUT,"First test point - operation not started.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ + "\nThere are three tests points - verifies all code paths through recovery.\n"); + fprintf(STDOUT, "First test point - operation not started.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ } vcode = VLDB_GetEntryByID(afromvol, -1, &entry); - ONERR (vcode, "Could not fetch the entry for the volume %u from the VLDB \n", afromvol); + ONERR(vcode, + "Could not fetch the entry for the volume %u from the VLDB \n", + afromvol); if (entry.volumeId[RWVOL] != afromvol) { - fprintf(STDERR,"Only RW volume can be moved\n"); - exit(1); + fprintf(STDERR, "Only RW volume can be moved\n"); + exit(1); } - vcode = ubik_Call(VL_SetLock, cstruct, 0,afromvol, RWVOL, VLOP_MOVE); - ONERR (vcode, "Could not lock entry for volume %u \n", afromvol); + VPRINT1("Locking VLDB entry for volume %u ...", afromvol); + vcode = ubik_Call(VL_SetLock, cstruct, 0, afromvol, RWVOL, VLOP_MOVE); + ONERR(vcode, "Could not lock entry for volume %u\n", afromvol); + VDONE; islocked = 1; - vcode = VLDB_GetEntryByID (afromvol, RWVOL, &entry); - ONERR (vcode, "Could not fetch the entry for the volume %u from the VLDB \n", afromvol); + vcode = VLDB_GetEntryByID(afromvol, RWVOL, &entry); + ONERR(vcode, + "Could not fetch the entry for the volume %u from the VLDB\n", + afromvol); backupId = entry.volumeId[BACKVOL]; MapHostToNetwork(&entry); - if ( !Lp_Match(afromserver, afrompart, &entry) ) + if (!Lp_Match(afromserver, afrompart, &entry)) { - /* the from server and partition do not exist in the vldb entry corresponding to volid */ - if ( !Lp_Match(atoserver, atopart, &entry) ) - { - /* the to server and partition do not exist in the vldb entry corresponding to volid */ - fprintf(STDERR,"The volume %u is not on the specified site. \n", afromvol); - fprintf(STDERR,"The current site is :"); - for (i=0; i - * we have already done the move, but the volume - * may still be existing physically on from fileserver - */ - fromconn = UV_Bind(afromserver, AFSCONF_VOLUMEPORT); - fromtid = 0; - pntg = 1; - - code = AFSVolTransCreate(fromconn, afromvol, afrompart, ITOffline, &fromtid); - if (!code) - { /* volume exists - delete it */ - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); - ONERR (code, "Failed to set flags on the volume %u\n", afromvol); - - code = AFSVolDeleteVolume(fromconn,fromtid); - ONERR (code, "Failed to delete the volume %u\n", afromvol); - - code = AFSVolEndTrans(fromconn, fromtid, &rcode); - fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Could not end the transaction for the volume %u \n", afromvol); - } - - /*delete the backup volume now */ - fromtid = 0; - code = AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, &fromtid); - if (!code) - { /* backup volume exists - delete it */ - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); - ONERR (code, "Failed to set flags on the backup volume %u\n", backupId); - - code = AFSVolDeleteVolume(fromconn,fromtid); - ONERR (code, "Could not delete the backup volume %u\n", backupId); - - code = AFSVolEndTrans(fromconn, fromtid, &rcode); - fromtid = 0; - if (!code) code = rcode; - ONERR (code,"Could not end the transaction for the backup volume %u \n",backupId); - } - - fromtid = 0; - error = 0; - goto mfail; + /* the from server and partition do not exist in the vldb entry corresponding to volid */ + if (!Lp_Match(atoserver, atopart, &entry)) + { + /* the to server and partition do not exist in the vldb entry corresponding to volid */ + fprintf(STDERR, "The volume %u is not on the specified site. \n", + afromvol); + fprintf(STDERR, "The current site is :"); + for (i = 0; i < entry.nServers; i++) + { + if (entry.serverFlags[i] == ITSRWVOL) + { + char pname[10]; + + MapPartIdIntoName(entry.serverPartition[i], pname); + fprintf(STDERR, " server %s partition %s \n", + hostutil_GetNameByINet(entry.serverNumber[i]), pname); + } + } + VPRINT1("Releasing lock on VLDB entry for volume %u ...", + afromvol); + vcode = + ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + ONERR(vcode, + " Could not release lock on the VLDB entry for the volume %u \n", + afromvol); + VDONE; + + return VOLSERVOLMOVED; + } + + /* delete the volume afromvol on src_server */ + /* from-info does not exist but to-info does => + * we have already done the move, but the volume + * may still be existing physically on from fileserver + */ + fromconn = UV_Bind(afromserver, AFSCONF_VOLUMEPORT); + fromtid = 0; + pntg = 1; + + code = + AFSVolTransCreate(fromconn, afromvol, afrompart, ITOffline, + &fromtid); + if (!code) + { /* volume already moved - delete from source */ + VPRINT1("Setting flags on leftover source volume %u ...", + afromvol); + code = + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + ONERR(code, + "Failed to set flags on the leftover source volume %u\n", + afromvol); + VDONE; + + VPRINT1("Deleting leftover source volume %u ...", afromvol); + code = AFSVolDeleteVolume(fromconn, fromtid); + ONERR(code, "Failed to delete the leftover source volume %u\n", + afromvol); + VDONE; + + VPRINT1("Ending transaction on leftover source volume %u ...", + afromvol); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + fromtid = 0; + if (!code) + code = rcode; + ONERR(code, + "Could not end the transaction for the leftover source volume %u \n", + afromvol); + VDONE; + } + + /*delete the backup volume now */ + fromtid = 0; + code = + AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, + &fromtid); + if (!code) + { /* backup volume exists - delete it */ + VPRINT1("Setting flags on leftover backup volume %u ...", + backupId); + code = + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + ONERR(code, + "Failed to set flags on the leftover backup volume %u\n", + backupId); + VDONE; + + VPRINT1("Deleting backup volume %u ...", backupId); + code = AFSVolDeleteVolume(fromconn, fromtid); + ONERR(code, "Could not delete the leftover backup volume %u\n", + backupId); + VDONE; + + VPRINT1("Ending transaction on leftover backup volume %u ...", + backupId); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + fromtid = 0; + if (!code) + code = rcode; + ONERR(code, + "Could not end the transaction for the leftover backup volume %u \n", + backupId); + VDONE; + } + + fromtid = 0; + error = 0; + goto mfail; } /* From-info matches the vldb info about volid, * its ok start the move operation, the backup volume * on the old site is deleted in the process */ - if (afrompart == atopart) + if (afrompart == atopart) { - same = VLDB_IsSameAddrs (afromserver, atoserver, &error); - if (error) - { - fprintf(STDERR, "Failed to get info about server's %d address(es) from vlserver (err=%d); aborting call!\n", - afromserver, error); - goto mfail; - } - if (same) ONERR (VOLSERVOLMOVED, - "Warning: Moving volume %u to its home partition ignored!\n", afromvol); + same = VLDB_IsSameAddrs(afromserver, atoserver, &error); + if (error) + { + fprintf(STDERR, + "Failed to get info about server's %d address(es) from vlserver (err=%d); aborting call!\n", + afromserver, error); + goto mfail; + } + if (same) + ONERR(VOLSERVOLMOVED, + "Warning: Moving volume %u to its home partition ignored!\n", + afromvol); } pntg = 1; - toconn = UV_Bind(atoserver, AFSCONF_VOLUMEPORT); /* get connections to the servers */ + toconn = UV_Bind(atoserver, AFSCONF_VOLUMEPORT); /* get connections to the servers */ fromconn = UV_Bind(afromserver, AFSCONF_VOLUMEPORT); - fromtid = totid = 0; /* initialize to uncreated */ + fromtid = totid = 0; /* initialize to uncreated */ /* *** * clone the read/write volume locally. * ***/ - if (verbose) fprintf(STDOUT,"Starting transaction on source volume %u ...",afromvol); + VPRINT1("Starting transaction on source volume %u ...", afromvol); fflush(STDOUT); code = AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, &fromtid); - ONERR (code, "Failed to create transaction on the volume %u\n", afromvol); - if (verbose) fprintf(STDOUT," done\n"); + ONERR(code, "Failed to create transaction on the volume %u\n", afromvol); + VDONE; /* Get a clone id */ + VPRINT1("Allocating new volume id for clone of volume %u ...", afromvol); newVol = 0; - vcode = ubik_Call (VL_GetNewVolumeId, cstruct, 0, 1, &newVol); - ONERR (vcode, "Could not get an ID for the clone of volume %u from the VLDB\n", afromvol); + vcode = ubik_Call(VL_GetNewVolumeId, cstruct, 0, 1, &newVol); + ONERR(vcode, + "Could not get an ID for the clone of volume %u from the VLDB\n", + afromvol); + VDONE; /* Do the clone. Default flags on clone are set to delete on salvage and out of service */ - if (verbose) fprintf (STDOUT,"Cloning source volume %u ...", afromvol); - fflush(STDOUT); - strcpy(vname, "move-clone-temp"); - code = AFSVolClone(fromconn, fromtid, 0,readonlyVolume, vname, &newVol); - ONERR (code, "Failed to clone the source volume %u\n", afromvol); - if (verbose) fprintf(STDOUT," done\n"); + VPRINT1("Cloning source volume %u ...", afromvol); + strcpy(vname, "move-clone-temp"); /* why the strcpy? is that name special cased on server? */ + code = AFSVolClone(fromconn, fromtid, 0, readonlyVolume, vname, &newVol); + ONERR(code, "Failed to clone the source volume %u\n", afromvol); + VDONE; /* lookup the name of the volume we just cloned */ volid = afromvol; code = AFSVolGetName(fromconn, fromtid, &volName); - ONERR (code, "Failed to get the name of the volume %u\n", newVol); + ONERR(code, "Failed to get the name of the volume %u\n", newVol); - if (verbose) fprintf (STDOUT,"Ending the transaction on the source volume %u ...", afromvol); - fflush(STDOUT); + VPRINT1("Ending the transaction on the source volume %u ...", afromvol); rcode = 0; code = AFSVolEndTrans(fromconn, fromtid, &rcode); fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the source volume %u\n", afromvol); - if (verbose) fprintf (STDOUT," done\n"); + if (!code) + code = rcode; + ONERR(code, "Failed to end the transaction on the source volume %u\n", + afromvol); + VDONE; /* *** * Create the destination volume * ***/ - - if (verbose) fprintf(STDOUT, "Starting transaction on the cloned volume %u ...", newVol); - fflush(STDOUT); - code = AFSVolTransCreate (fromconn, newVol, afrompart, ITOffline, &clonetid); - ONERR (code, "Failed to start a transaction on the cloned volume%u\n", newVol); - if (verbose) fprintf(STDOUT," done\n"); - code = AFSVolSetFlags (fromconn, clonetid, VTDeleteOnSalvage|VTOutOfService); /*redundant */ - ONERR (code, "Could not set falgs on the cloned volume %u\n", newVol); + VPRINT1("Starting transaction on the cloned volume %u ...", newVol); + code = + AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, &clonetid); + ONERR(code, "Failed to start a transaction on the cloned volume%u\n", + newVol); + VDONE; + + VPRINT1("Setting flags on cloned volume %u ...", newVol); + code = AFSVolSetFlags(fromconn, clonetid, VTDeleteOnSalvage | VTOutOfService); /*redundant */ + ONERR(code, "Could not set flags on the cloned volume %u\n", newVol); + VDONE; /* remember time from which we've dumped the volume */ - code = AFSVolGetStatus (fromconn, clonetid, &tstatus); - ONERR (code, "Failed to get the status of the cloned volume %u\n", newVol); + VPRINT1("Getting status of cloned volume %u ...", newVol); + code = AFSVolGetStatus(fromconn, clonetid, &tstatus); + ONERR(code, "Failed to get the status of the cloned volume %u\n", newVol); + VDONE; - fromDate = tstatus.creationDate-CLOCKSKEW; + fromDate = tstatus.creationDate - CLOCKSKEW; #ifdef ENABLE_BUGFIX_1165 /* @@ -1083,54 +1149,65 @@ * to copy it to the new volume (via AFSSetInfo later on) so that when we move volumes we * don't use this information... */ - volumeInfo.volEntries_val = (volintInfo *)0;/*this hints the stub to allocate space*/ + volumeInfo.volEntries_val = (volintInfo *) 0; /*this hints the stub to allocate space */ volumeInfo.volEntries_len = 0; code = AFSVolListOneVolume(fromconn, afrompart, afromvol, &volumeInfo); - ONERR (code, "Failed to get the volint Info of the cloned volume %u\n", afromvol); + ONERR(code, "Failed to get the volint Info of the cloned volume %u\n", + afromvol); infop = (volintInfo *) volumeInfo.volEntries_val; - infop->maxquota = -1; /* Else it will replace the default quota */ + infop->maxquota = -1; /* Else it will replace the default quota */ #endif /* create a volume on the target machine */ volid = afromvol; - code = AFSVolTransCreate (toconn, volid, atopart, ITOffline, &totid); - if (!code) - { - /* Delete the existing volume. - * While we are deleting the volume in these steps, the transaction - * we started against the cloned volume (clonetid above) will be - * sitting idle. It will get cleaned up after 600 seconds - */ - if (verbose) fprintf(STDOUT,"Deleting pre-existing volume %u on destination ...",volid); - fflush(STDOUT); - - code = AFSVolDeleteVolume(toconn, totid); - ONERR (code, "Could not delete the pre-existing volume %u on destination\n", volid); - - code = AFSVolEndTrans(toconn, totid, &rcode); - totid = 0; - if (!code) code = rcode; - ONERR (code, "Could not end the transaction on pre-existing volume %u on destination\n", - volid); - - if (verbose) fprintf(STDOUT," done\n"); - } - - if (verbose) fprintf(STDOUT,"Creating the destination volume %u ...",volid); - fflush(STDOUT); - code = AFSVolCreateVolume (toconn, atopart, volName, volser_RW, volid, &volid, &totid); - ONERR (code, "Failed to create the destination volume %u\n", volid); - if (verbose) fprintf(STDOUT," done\n"); + code = AFSVolTransCreate(toconn, volid, atopart, ITOffline, &totid); + if (!code) + { + /* Delete the existing volume. + * While we are deleting the volume in these steps, the transaction + * we started against the cloned volume (clonetid above) will be + * sitting idle. It will get cleaned up after 600 seconds + */ + VPRINT1("Deleting pre-existing volume %u on destination ...", volid); + code = AFSVolDeleteVolume(toconn, totid); + ONERR(code, + "Could not delete the pre-existing volume %u on destination\n", + volid); + VDONE; + + VPRINT1 + ("Ending transaction on pre-existing volume %u on destination ...", + volid); + code = AFSVolEndTrans(toconn, totid, &rcode); + totid = 0; + if (!code) + code = rcode; + ONERR(code, + "Could not end the transaction on pre-existing volume %u on destination\n", + volid); + VDONE; + } + + VPRINT1("Creating the destination volume %u ...", volid); + code = + AFSVolCreateVolume(toconn, atopart, volName, volser_RW, volid, &volid, + &totid); + ONERR(code, "Failed to create the destination volume %u\n", volid); + VDONE; strncpy(tmpName, volName, VOLSER_OLDMAXVOLNAME); free(volName); volName = (char *) 0; - code = AFSVolSetFlags (toconn, totid, (VTDeleteOnSalvage | VTOutOfService)); - ONERR(code, "Failed to set the flags on the destination volume %u\n", volid); + VPRINT1("Setting volume flags on destination volume %u ...", volid); + code = + AFSVolSetFlags(toconn, totid, (VTDeleteOnSalvage | VTOutOfService)); + ONERR(code, "Failed to set the flags on the destination volume %u\n", + volid); + VDONE; - /*** + /*** * Now dump the clone to the new volume ***/ @@ -1139,110 +1216,135 @@ destination.destSSID = 1; /* Copy the clone to the new volume */ - if (verbose) fprintf(STDOUT, "Dumping from clone %u on source to volume %u on destination ...", - newVol, afromvol); - fflush(STDOUT); - strncpy(cookie.name,tmpName,VOLSER_OLDMAXVOLNAME); - cookie.type = RWVOL; + VPRINT2("Dumping from clone %u on source to volume %u on destination ...", + newVol, afromvol); + strncpy(cookie.name, tmpName, VOLSER_OLDMAXVOLNAME); + cookie.type = RWVOL; cookie.parent = entry.volumeId[RWVOL]; - cookie.clone = 0; + cookie.clone = 0; code = AFSVolForward(fromconn, clonetid, 0, &destination, totid, &cookie); - ONERR (code, "Failed to move data for the volume %u\n", volid); - if (verbose) fprintf(STDOUT," done\n"); + ONERR(code, "Failed to move data for the volume %u\n", volid); + VDONE; + VPRINT1("Ending transaction on cloned volume %u ...", newVol); code = AFSVolEndTrans(fromconn, clonetid, &rcode); - if (!code) code = rcode; + if (!code) + code = rcode; clonetid = 0; - ONERR (code, "Failed to end the transaction on the cloned volume %u\n", newVol); + ONERR(code, "Failed to end the transaction on the cloned volume %u\n", + newVol); + VDONE; /* *** * reattach to the main-line volume, and incrementally dump it. * ***/ - if (verbose) - fprintf(STDOUT,"Doing the incremental dump from source to destination for volume %u ... ", - afromvol); - fflush(STDOUT); - + VPRINT1("Starting transaction on source volume %u ...", afromvol); code = AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, &fromtid); - ONERR (code, "Failed to create a transaction on the source volume %u\n", afromvol); + ONERR(code, "Failed to create a transaction on the source volume %u\n", + afromvol); + VDONE; /* now do the incremental */ - code = AFSVolForward(fromconn, fromtid, fromDate, &destination, totid,&cookie); - ONERR (code, "Failed to do the incremental dump from rw volume on old site to rw volume on newsite\n", 0); - if (verbose)fprintf(STDOUT," done\n"); + VPRINT1 + ("Doing the incremental dump from source to destination for volume %u ... ", + afromvol); + code = + AFSVolForward(fromconn, fromtid, fromDate, &destination, totid, + &cookie); + ONERR(code, + "Failed to do the incremental dump from rw volume on old site to rw volume on newsite\n", + 0); + VDONE; /* now adjust the flags so that the new volume becomes official */ + VPRINT1("Setting volume flags on old source volume %u ...", afromvol); code = AFSVolSetFlags(fromconn, fromtid, VTOutOfService); - ONERR (code, "Failed to set the flags to make old source volume offline\n", 0); + ONERR(code, "Failed to set the flags to make old source volume offline\n", + 0); + VDONE; + VPRINT1("Setting volume flags on new source volume %u ...", afromvol); code = AFSVolSetFlags(toconn, totid, 0); - ONERR (code, "Failed to set the flags to make new source volume online\n", 0); + ONERR(code, "Failed to set the flags to make new source volume online\n", + 0); + VDONE; #ifdef ENABLE_BUGFIX_1165 code = AFSVolSetInfo(toconn, totid, infop); - ONERR (code, "Failed to set volume status on the destination volume %u\n", volid); + ONERR(code, "Failed to set volume status on the destination volume %u\n", + volid); #endif /* put new volume online */ + VPRINT1("Ending transaction on destination volume %u ...", afromvol); code = AFSVolEndTrans(toconn, totid, &rcode); totid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the volume %u on the new site\n", afromvol); + if (!code) + code = rcode; + ONERR(code, + "Failed to end the transaction on the volume %u on the new site\n", + afromvol); + VDONE; Lp_SetRWValue(&entry, afromserver, afrompart, atoserver, atopart); - MapNetworkToHost(&entry,&storeEntry); + MapNetworkToHost(&entry, &storeEntry); storeEntry.flags &= ~BACK_EXISTS; if (TESTC) { - fprintf(STDOUT, "Second test point - operation in progress but not complete.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ - } - - vcode = VLDB_ReplaceEntry (afromvol, -1, &storeEntry, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); - if (vcode) + fprintf(STDOUT, + "Second test point - operation in progress but not complete.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ + } + + VPRINT1("Releasing lock on VLDB entry for volume %u ...", afromvol); + vcode = VLDB_ReplaceEntry(afromvol, -1, &storeEntry, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + if (vcode) { - fprintf(STDERR," Could not release the lock on the VLDB entry for the volume %s %u \n", - storeEntry.name,afromvol); - error = vcode; - goto mfail; + fprintf(STDERR, + " Could not release the lock on the VLDB entry for the volume %s %u \n", + storeEntry.name, afromvol); + error = vcode; + goto mfail; } - islocked=0; + VDONE; + islocked = 0; if (TESTC) { - fprintf(STDOUT, "Third test point - operation complete but no cleanup.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ + fprintf(STDOUT, + "Third test point - operation complete but no cleanup.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ } #ifdef notdef @@ -1252,189 +1354,257 @@ * we're cleaning this code up in DEcorum, we're just going to kludge around * it for now by removing this call. */ /* already out of service, just zap it now */ - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); + code = + AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); if (code) { - fprintf(STDERR,"Failed to set the flags to make the old source volume offline\n"); - goto mfail; + fprintf(STDERR, + "Failed to set the flags to make the old source volume offline\n"); + goto mfail; } #endif - if (atoserver != afromserver) + if (atoserver != afromserver) { /* set forwarding pointer for moved volumes */ + VPRINT1("Setting forwarding pointer for volume %u ...", afromvol); code = AFSVolSetForwarding(fromconn, fromtid, atoserver); - ONERR (code, "Failed to set the forwarding pointer for the volume %u\n", afromvol); + ONERR(code, + "Failed to set the forwarding pointer for the volume %u\n", + afromvol); + VDONE; } - if (verbose) fprintf(STDOUT,"Deleting old volume %u on source ...", afromvol); - fflush(STDOUT); + VPRINT1("Deleting old volume %u on source ...", afromvol); + code = AFSVolDeleteVolume(fromconn, fromtid); /* zap original volume */ + ONERR(code, "Failed to delete the old volume %u on source\n", afromvol); + VDONE; - code = AFSVolDeleteVolume(fromconn,fromtid); /* zap original volume */ - ONERR (code, "Failed to delete the old volume %u on source\n", afromvol); - + VPRINT1("Ending transaction on old volume %u on the source ...", + afromvol); code = AFSVolEndTrans(fromconn, fromtid, &rcode); fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the old volume %u on the source\n", afromvol); - - if (verbose) fprintf(STDOUT," done\n"); + if (!code) + code = rcode; + ONERR(code, + "Failed to end the transaction on the old volume %u on the source\n", + afromvol); + VDONE; /* Delete the backup volume on the original site */ - code = AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, &fromtid); - if (!code) - { - fprintf(STDOUT, "WARNING : Deleting the backup volume %u on the source ...",backupId); - fflush(STDOUT); - - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); - ONERR (code, "Failed to set the flags on the backup volume on source\n", 0); - - code = AFSVolDeleteVolume(fromconn,fromtid); - ONERR (code, "Failed to delete the backup volume on source\n", 0); - - code = AFSVolEndTrans(fromconn,fromtid, &rcode); - fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the backup volume %u on source\n", 0); + VPRINT1("Creating transaction for backup volume %u on source ...", + backupId); + code = + AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, &fromtid); + VDONE; - fprintf(STDOUT," done\n"); + if (!code) /* if backup volume exists, otherwise code will be zero */ + { + VPRINT1("Setting flags on backup volume %u on source ...", backupId); + code = + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + ONERR(code, + "Failed to set the flags on the backup volume on source\n", 0); + VDONE; + + VPRINT1("Deleting the backup volume %u on the source ...", backupId); + fflush(STDOUT); + code = AFSVolDeleteVolume(fromconn, fromtid); + ONERR(code, "Failed to delete the backup volume on source\n", 0); + VDONE; + + VPRINT1("Ending transaction on backup volume %u on source ...", + backupId); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + fromtid = 0; + if (!code) + code = rcode; + ONERR(code, + "Failed to end the transaction on the backup volume %u on source\n", + 0); + VDONE; + } + else + { + VPRINT("No backup volume exists on source. Ignoring.\n"); } - else code = 0; /* no backup volume? that's okay */ + VPRINT1("Starting transaction on the cloned volume %u ...", newVol); fromtid = 0; - if (verbose) fprintf(STDOUT,"Starting transaction on the cloned volume %u ...",newVol); - fflush(STDOUT); - - code = AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, &clonetid); - ONERR (code, "Failed to start a transaction on the cloned volume%u\n", newVol); + code = + AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, &clonetid); + ONERR(code, "Failed to start a transaction on the cloned volume%u\n", + newVol); + VDONE; - if (verbose) fprintf(STDOUT," done\n"); - /* now delete the clone */ - if (verbose) fprintf(STDOUT,"Deleting the clone %u ...", newVol); - fflush(STDOUT); - + VPRINT1("Deleting the clone %u ...", newVol); code = AFSVolDeleteVolume(fromconn, clonetid); - ONERR (code, "Failed to delete the cloned volume %u\n", newVol); - - if (verbose) fprintf(STDOUT," done\n"); + ONERR(code, "Failed to delete the cloned volume %u\n", newVol); + VDONE; + VPRINT1("Ending transaction on clone volume %u ...", newVol); code = AFSVolEndTrans(fromconn, clonetid, &rcode); - if (!code) code = rcode; + if (!code) + code = rcode; clonetid = 0; - ONERR (code, "Failed to end the transaction on the cloned volume %u\n", newVol); + ONERR(code, "Failed to end the transaction on the cloned volume %u\n", + newVol); + VDONE; /* fall through */ /* END OF MOVE */ if (TESTC) { - fprintf(STDOUT,"Fourth test point - operation complete.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ + fprintf(STDOUT, "Fourth test point - operation complete.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ } /* normal cleanup code */ - if (entry.flags & RO_EXISTS) fprintf(STDERR,"WARNING : readOnly copies still exist \n"); + if (entry.flags & RO_EXISTS) + fprintf(STDERR, "WARNING : readOnly copies still exist \n"); if (islocked) { - vcode = ubik_Call(VL_ReleaseLock,cstruct, 0, afromvol, -1, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); - if (vcode) - { - fprintf(STDERR," Could not release the lock on the VLDB entry for the volume %u \n", - afromvol); - if (!error) error = vcode; - } + VPRINT1("Cleanup: Releasing VLDB lock on volume %u ...", afromvol); + vcode = ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + if (vcode) + { + fprintf(STDERR, + " Could not release the lock on the VLDB entry for the volume %u \n", + afromvol); + if (!error) + error = vcode; + } + VDONE; } - - if (fromtid) + + if (fromtid) { - code = AFSVolEndTrans(fromconn, fromtid, &rcode); - if (code || rcode) - { - fprintf(STDERR,"Could not end transaction on the source's clone volume %u\n", newVol); - if (!error) error = (code ? code : rcode); - } + VPRINT1("Cleanup: Ending transaction on source volume %u ...", + afromvol); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + if (code || rcode) + { + fprintf(STDERR, + "Could not end transaction on source volume %u\n", afromvol); + if (!error) + error = (code ? code : rcode); + } + VDONE; } - if (clonetid) + if (clonetid) { - code = AFSVolEndTrans(fromconn, clonetid, &rcode); - if (code || rcode) - { - fprintf(STDERR,"Could not end transaction on the source's clone volume %u\n",newVol); - if (!error) error = (code ? code : rcode); - } + VPRINT1("Cleanup: Ending transaction on clone volume %u ...", newVol); + code = AFSVolEndTrans(fromconn, clonetid, &rcode); + if (code || rcode) + { + fprintf(STDERR, + "Could not end transaction on clone volume %u\n", newVol); + if (!error) + error = (code ? code : rcode); + } + VDONE; } - if (totid) + if (totid) { - code = AFSVolEndTrans(toconn, totid, &rcode); - if (code) - { - fprintf(STDERR,"Could not end transaction on destination volume %u\n",afromvol); - if (!error) error = (code ? code : rcode); - } + VPRINT1("Cleanup: Ending transaction on destination volume %u ...", + afromvol); + code = AFSVolEndTrans(toconn, totid, &rcode); + if (code) + { + fprintf(STDERR, + "Could not end transaction on destination volume %u\n", + afromvol); + if (!error) + error = (code ? code : rcode); + } + VDONE; } - if (volName) free(volName); + if (volName) + free(volName); #ifdef ENABLE_BUGFIX_1165 - if (infop) free(infop); + if (infop) + free(infop); #endif - if (fromconn) rx_DestroyConnection(fromconn); - if (toconn) rx_DestroyConnection(toconn); - PrintError("",error); + if (fromconn) + rx_DestroyConnection(fromconn); + if (toconn) + rx_DestroyConnection(toconn); + PrintError("", error); return error; /* come here only when the sky falls */ -mfail: + mfail: - if (pntg) + if (pntg) { - fprintf(STDOUT,"vos move: operation interrupted, cleanup in progress...\n"); - fprintf(STDOUT,"clear transaction contexts\n"); - fflush(STDOUT); + fprintf(STDOUT, + "vos move: operation interrupted, cleanup in progress...\n"); + fprintf(STDOUT, "clear transaction contexts\n"); + fflush(STDOUT); } /* unlock VLDB entry */ if (islocked) + { + VPRINT1("Recovery: Releasing VLDB lock on volume %u ...", afromvol); ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + VDONE; + } - if (clonetid) AFSVolEndTrans(fromconn, clonetid, &rcode); - if (totid) AFSVolEndTrans(toconn, totid, &rcode); - if (fromtid) - { /* put it on-line */ - AFSVolSetFlags(fromconn,fromtid,0); - AFSVolEndTrans(fromconn, fromtid, &rcode); + if (clonetid) + { + VPRINT("Recovery: Ending transaction on clone volume ..."); + AFSVolEndTrans(fromconn, clonetid, &rcode); + VDONE; } - if (verbose) - { /* get current VLDB entry */ - fprintf(STDOUT,"access VLDB\n"); - fflush(STDOUT); + if (totid) + { + VPRINT("Recovery: Ending transaction on destination volume ..."); + AFSVolEndTrans(toconn, totid, &rcode); + VDONE; } - vcode= VLDB_GetEntryByID (afromvol, -1, &entry); + + if (fromtid) + { /* put it on-line */ + VPRINT("Recovery: Setting volume flags on source volume ..."); + AFSVolSetFlags(fromconn, fromtid, 0); + VDONE; + + VPRINT("Recovery: Ending transaction on source volume ..."); + AFSVolEndTrans(fromconn, fromtid, &rcode); + VDONE; + } + + VPRINT("Recovery: Accessing VLDB.\n"); + vcode = VLDB_GetEntryByID(afromvol, -1, &entry); if (vcode) { - fprintf(STDOUT,"FATAL: VLDB access error: abort cleanup\n"); - fflush(STDOUT); - goto done; + fprintf(STDOUT, "FATAL: VLDB access error: abort cleanup\n"); + fflush(STDOUT); + goto done; } MapHostToNetwork(&entry); @@ -1443,86 +1613,201 @@ * volume move didn't finish so we remove the volume from the target * location. Otherwise, we remove the volume from the source location. */ - if (Lp_Match(afromserver,afrompart,&entry)) { /* didn't move - delete target volume */ - if (pntg) { - fprintf(STDOUT, - "move incomplete - attempt cleanup of target partition - no guarantee\n"); - fflush(STDOUT); - } - - if (volid && toconn) { - code=AFSVolTransCreate(toconn,volid,atopart, ITOffline,&totid); - if (!code) { - AFSVolSetFlags(toconn,totid, VTDeleteOnSalvage | VTOutOfService); - AFSVolDeleteVolume(toconn,totid); - AFSVolEndTrans(toconn,totid,&rcode); - } - } - - /* put source volume on-line */ - if (fromconn) { - code=AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, &fromtid); - if (!code) { - AFSVolSetFlags(fromconn,fromtid,0); - AFSVolEndTrans(fromconn,fromtid,&rcode); - } - } + if (Lp_Match(afromserver, afrompart, &entry)) + { /* didn't move - delete target volume */ + if (pntg) + { + fprintf(STDOUT, + "move incomplete - attempt cleanup of target partition - no guarantee\n"); + fflush(STDOUT); + } + + if (volid && toconn) + { + VPRINT1 + ("Recovery: Creating transaction for destination volume %u ...", + volid); + code = + AFSVolTransCreate(toconn, volid, atopart, ITOffline, &totid); + VDONE; + if (!code) + { + VPRINT1 + ("Recovery: Setting flags on destination volume %u ...", + volid); + AFSVolSetFlags(toconn, totid, + VTDeleteOnSalvage | VTOutOfService); + VDONE; + + VPRINT1("Recovery: Deleting destination volume %u ...", + volid); + AFSVolDeleteVolume(toconn, totid); + VDONE; + + VPRINT1 + ("Recovery: Ending transaction on destination volume %u ...", + volid); + AFSVolEndTrans(toconn, totid, &rcode); + VDONE; + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + volid); + } + } + + /* put source volume on-line */ + if (fromconn) + { + VPRINT1("Recovery: Creating transaction on source volume %u ...", + afromvol); + code = + AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, + &fromtid); + VDONE; + + if (!code) + { + VPRINT1("Recovery: Setting flags on source volume %u ...", + afromvol); + AFSVolSetFlags(fromconn, fromtid, 0); + VDONE; + + VPRINT1 + ("Recovery: Ending transaction on source volume %u ...", + afromvol); + AFSVolEndTrans(fromconn, fromtid, &rcode); + VDONE; + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + afromvol); + } + } + } + else + { /* yep, move complete */ + if (pntg) + { + fprintf(STDOUT, + "move complete - attempt cleanup of source partition - no guarantee\n"); + fflush(STDOUT); + } + + /* delete backup volume */ + if (fromconn) + { + VPRINT1("Recovery: Creating transaction on backup volume %u ...", + backupId); + code = + AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, + &fromtid); + VDONE; + if (!code) + { + VPRINT1("Recovery: Setting flags on backup volume %u ...", backupId); + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + VDONE; + + VPRINT1("Recovery: Deleting backup volume %u ...", backupId); + AFSVolDeleteVolume(fromconn, fromtid); + VDONE; + + VPRINT1("Recovery: Ending transaction on backup volume %u ...", backupId); + AFSVolEndTrans(fromconn, fromtid, &rcode); + VDONE; + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + backupId); + } + + /* delete source volume */ + VPRINT1("Recovery: Creating transaction on source volume %u ...", + afromvol); + code = + AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, + &fromtid); + VDONE; + if (!code) + { + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + if (atoserver != afromserver) + AFSVolSetForwarding(fromconn, fromtid, atoserver); + AFSVolDeleteVolume(fromconn, fromtid); + AFSVolEndTrans(fromconn, fromtid, &rcode); + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + afromvol); + } + } } - else { /* yep, move complete */ - if (pntg) { - fprintf(STDOUT, - "move complete - attempt cleanup of source partition - no guarantee\n"); - fflush(STDOUT); - } - - /* delete backup volume */ - if (fromconn) { - code=AFSVolTransCreate (fromconn,backupId,afrompart, ITOffline,&fromtid); - if (!code) { - AFSVolSetFlags(fromconn,fromtid, VTDeleteOnSalvage | VTOutOfService); - AFSVolDeleteVolume(fromconn,fromtid); - AFSVolEndTrans(fromconn,fromtid,&rcode); - } - - /* delete source volume */ - code=AFSVolTransCreate (fromconn, afromvol, afrompart, ITBusy, &fromtid); - if (!code) { - AFSVolSetFlags(fromconn,fromtid, VTDeleteOnSalvage | VTOutOfService); - if (atoserver != afromserver) - AFSVolSetForwarding(fromconn,fromtid,atoserver); - AFSVolDeleteVolume(fromconn,fromtid); - AFSVolEndTrans(fromconn,fromtid,&rcode); - } - } - } /* common cleanup - delete local clone */ - if (newVol) { - code = AFSVolTransCreate (fromconn, newVol, afrompart, ITOffline, &clonetid); - if (!code) { - AFSVolDeleteVolume(fromconn,clonetid); - AFSVolEndTrans(fromconn,clonetid,&rcode); - } + if (newVol) + { + VPRINT1("Recovery: Creating transaction on clone volume %u ...", + newVol); + code = + AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, + &clonetid); + VDONE; + if (!code) + { + VPRINT1("Recovery: Deleting clone volume %u ...", newVol); + AFSVolDeleteVolume(fromconn, clonetid); + VDONE; + + VPRINT1("Recovery: Ending transaction on clone volume %u ...", + newVol); + AFSVolEndTrans(fromconn, clonetid, &rcode); + VDONE; + } + else + { + VPRINT1("Recovery: Unable to start transaction on volume %u.\n", + newVol); + } } /* unlock VLDB entry */ - ubik_Call (VL_ReleaseLock, cstruct, 0, afromvol, -1, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); - -done: /* routine cleanup */ - if (volName) free(volName); + VPRINT1("Recovery: Releasing lock on VLDB entry for volume %u ...", + afromvol); + ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + VDONE; + + done: /* routine cleanup */ + if (volName) + free(volName); #ifdef ENABLE_BUGFIX_1165 - if (infop) free(infop); + if (infop) + free(infop); #endif - if (fromconn) rx_DestroyConnection(fromconn); - if (toconn) rx_DestroyConnection(toconn); + if (fromconn) + rx_DestroyConnection(fromconn); + if (toconn) + rx_DestroyConnection(toconn); - if (pntg) { - fprintf(STDOUT,"cleanup complete - user verify desired result\n"); - fflush(STDOUT); + if (pntg) + { + fprintf(STDOUT, "cleanup complete - user verify desired result\n"); + fflush(STDOUT); } exit(1); } + /* Make a new backup of volume on and * if one already exists, update it --ikeVEW9yuYc//A+q-- From jhutz@cmu.edu Wed Feb 6 17:12:10 2002 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 6 Feb 2002 12:12:10 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: <20020206142729.GA6654@umr.edu> Message-ID: On Wed, 6 Feb 2002, Nathan Neulinger wrote: > Also removes the "WARNING" from "WARNING : removing backup volume on > source", which really doesn't need to be a warning since it's > completely expected, and you can't back out at that point any way. Please don't go around making gratuitous changes to messages. There are people and programs which depend on the output format of various AFS commands, and changing that format can break them. So make sure you have a _good_ reason before you change something like that. From rra@stanford.edu Wed Feb 6 18:26:17 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed, 06 Feb 2002 10:26:17 -0800 Subject: [OpenAFS-devel] scary vos remove message... In-Reply-To: ("Neulinger, Nathan"'s message of "Wed, 6 Feb 2002 09:30:41 -0600") References: Message-ID: Neulinger, Nathan writes: > This definately needs reworked: > infinity(1)>vos remove afs8 c res.kumar.students -verbose > res.kumar.students > RWrite: 536925133 Backup: 536925135 > number of sites -> 1 > server afs8.cc.umr.edu partition /vicepa RW Site > Trying to delete the volume 536925133 ... > That is always scary even when you know it isn't saying what it looks > like it's saying. I don't understand. You told it to remove a volume and it says that it's trying to remove the volume. What's scary about that? It's going to fail in a second since you gave it the wrong partition.... -- Russ Allbery (rra@stanford.edu) From rra@stanford.edu Wed Feb 6 18:28:25 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed, 06 Feb 2002 10:28:25 -0800 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 6 Feb 2002 12:12:10 -0500 (EST)") References: Message-ID: Jeffrey Hutzelman writes: > On Wed, 6 Feb 2002, Nathan Neulinger wrote: >> Also removes the "WARNING" from "WARNING : removing backup volume on >> source", which really doesn't need to be a warning since it's >> completely expected, and you can't back out at that point any way. > Please don't go around making gratuitous changes to messages. There are > people and programs which depend on the output format of various AFS > commands, and changing that format can break them. So make sure you > have a _good_ reason before you change something like that. With all due respect to the people concerned with that sort of thing, I think it's pretty unreasonable to never change the output of any command to make it more user-friendly because people are doing things that they should never have had to do in the first place. We badly need a programmatic interface to AFS operations, and then at that point I (even being one of the people with scripts with that issue) think people should feel free to change the output of the commands all they want. Some of the output badly needs to be fixed, and I don't want to see the user interface and user-friendliness be stalled by old, evil hacks that we all wrote back in the days when there was no better alternative. -- Russ Allbery (rra@stanford.edu) From nneul@umr.edu Wed Feb 6 18:35:39 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 6 Feb 2002 12:35:39 -0600 Subject: [OpenAFS-devel] scary vos remove message... Message-ID: No... actually, it's not... I was cleaning up after a failed volume move, so there was a stray copy of that volume in the other location.=20 The scary part is that it looks from the message like it is going to delete the volume listed - even though I told it to delete something else. (It actually is deleting the other one, it just looks like it's going to delete the volume on a, not c) -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Russ Allbery [mailto:rra@stanford.edu]=20 > Sent: Wednesday, February 06, 2002 12:26 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] scary vos remove message... >=20 >=20 > Neulinger, Nathan writes: >=20 > > This definately needs reworked: >=20 > > infinity(1)>vos remove afs8 c res.kumar.students -verbose >=20 > > res.kumar.students=20 > > RWrite: 536925133 Backup: 536925135=20 > > number of sites -> 1 > > server afs8.cc.umr.edu partition /vicepa RW Site=20 > > Trying to delete the volume 536925133 ... >=20 > > That is always scary even when you know it isn't saying=20 > what it looks > > like it's saying. >=20 > I don't understand. You told it to remove a volume and it=20 > says that it's > trying to remove the volume. What's scary about that? It's=20 > going to fail > in a second since you gave it the wrong partition.... >=20 > --=20 > Russ Allbery (rra@stanford.edu) =20 > >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Wed Feb 6 20:14:27 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 6 Feb 2002 15:14:27 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: Message-ID: On Wed, 6 Feb 2002, Russ Allbery wrote: > > Please don't go around making gratuitous changes to messages. There are > > people and programs which depend on the output format of various AFS > > commands, and changing that format can break them. So make sure you > > have a _good_ reason before you change something like that. > > With all due respect to the people concerned with that sort of thing, I > think it's pretty unreasonable to never change the output of any command > to make it more user-friendly because people are doing things that they > should never have had to do in the first place. At minimum, though, not in a minor version update to the code. 1.2.3->1.2.4 should not be expected to break your scripts. From shadow@dementia.org Wed Feb 6 20:18:40 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 6 Feb 2002 15:18:40 -0500 (EST) Subject: meta Re: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: Message-ID: if you reply, please prune openafs-bugs from your reply; a new ticket is opened for every reply which doesn't contain e.g. [grand.central.org #817] in the subject. -D From Craig_Everhart@transarc.com Wed Feb 6 18:37:11 2002 From: Craig_Everhart@transarc.com (Craig_Everhart@transarc.com) Date: Wed, 6 Feb 2002 13:37:11 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: References: Message-ID: <8wMLTLU99g8801KfA0@transarc.com> Actually, what worries me about the patch is how many gratuitous diffs it contains, presumably "cleaning up" indentation, spacing, and the like. While the short-term results may look OK, it means that all kinds of patches down the line will keep seeing these gratuitous differences. Worse, if someone "cleans up" in some other way, still more gratuitous differences will abound, obfuscating real (functional) changes. The OpenAFS code may not be beautiful, but efforts to re-indent and so forth need to be coordinated a lot better than this to circumvent merge grief in the future. Regards, Craig From nneul@umr.edu Wed Feb 6 21:16:08 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 6 Feb 2002 15:16:08 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose Message-ID: Actually, since the diagnostic msg output touches about every other line in the routine, it's kindof pointless not to reindent at the same time. (Not re-indenting that subroutine when I did the changes would shrink the size of the diff by maybe 10-15% at most.)=20 Yes, I'd prefer that the reindenting be done projectwide independently, but if a patch is going to be submitted that changed so much of a subroutine, it really is pointless to delay unless someone objects to the different formatting.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Craig_Everhart@transarc.com=20 > [mailto:Craig_Everhart@transarc.com]=20 > Sent: Wednesday, February 06, 2002 12:37 PM > To: openafs-bugs@openafs.org; openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Patch to add much more=20 > diagnostics to vos move when run with -verbose >=20 >=20 > Actually, what worries me about the patch is how many gratuitous diffs > it contains, presumably "cleaning up" indentation, spacing, and the > like. While the short-term results may look OK, it means=20 > that all kinds > of patches down the line will keep seeing these gratuitous=20 > differences.=20 > Worse, if someone "cleans up" in some other way, still more gratuitous > differences will abound, obfuscating real (functional) changes. >=20 > The OpenAFS code may not be beautiful, but efforts to re-indent and so > forth need to be coordinated a lot better than this to=20 > circumvent merge > grief in the future. >=20 > Regards, > Craig >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From rra@stanford.edu Thu Feb 7 01:48:12 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed, 06 Feb 2002 17:48:12 -0800 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: (Derrick J Brashear's message of "Wed, 6 Feb 2002 15:14:27 -0500 (EST)") References: Message-ID: Derrick J Brashear writes: > On Wed, 6 Feb 2002, Russ Allbery wrote: >> With all due respect to the people concerned with that sort of thing, I >> think it's pretty unreasonable to never change the output of any >> command to make it more user-friendly because people are doing things >> that they should never have had to do in the first place. > At minimum, though, not in a minor version update to the code. > 1.2.3->1.2.4 should not be expected to break your scripts. Oh, definitely agreed. Those are the kind of patches to save up and do all at once during a major version change. -- Russ Allbery (rra@stanford.edu) From nneul@umr.edu Thu Feb 7 13:54:08 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 7 Feb 2002 07:54:08 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose Message-ID: Seems reasonable to me... It would be nice though to get some re-indentation/re-formatting patches applies, if for no other reason than to ease maintaining of the other patches until they can be applied. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Russ Allbery [mailto:rra@stanford.edu]=20 > Sent: Wednesday, February 06, 2002 7:48 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Patch to add much more=20 > diagnostics to vos movewhen run with -verbose >=20 >=20 > Derrick J Brashear writes: > > On Wed, 6 Feb 2002, Russ Allbery wrote: >=20 > >> With all due respect to the people concerned with that=20 > sort of thing, I > >> think it's pretty unreasonable to never change the output of any > >> command to make it more user-friendly because people are=20 > doing things > >> that they should never have had to do in the first place. >=20 > > At minimum, though, not in a minor version update to the code. > > 1.2.3->1.2.4 should not be expected to break your scripts. >=20 > Oh, definitely agreed. Those are the kind of patches to save=20 > up and do > all at once during a major version change. >=20 > --=20 > Russ Allbery (rra@stanford.edu) =20 > >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From nneul@umr.edu Thu Feb 7 13:59:21 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 7 Feb 2002 07:59:21 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose Message-ID: On a side note... it would be really nice if there was an easy way to keep track of all the various patches out there, even if they have no intention of being applied to the mainline project. This is in regards to Craig's comment about patches impacting other patches. I'm not sure that we should _not_ apply something if it impacts someone else's patch, but having a central repository would be an easy way to at least see if it is likely to impact someone else. Even if the repository only held information on what files a particular patch touched in the case of patches that can't be released, such as the MR-AFS stuff.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Neulinger, Nathan=20 > Sent: Thursday, February 07, 2002 7:54 AM > To: Russ Allbery; openafs-devel@openafs.org > Subject: RE: [OpenAFS-devel] Patch to add much more=20 > diagnostics to vos movewhen run with -verbose >=20 >=20 > Seems reasonable to me... It would be nice though to get some > re-indentation/re-formatting patches applies, if for no other reason > than to ease maintaining of the other patches until they can=20 > be applied. >=20 >=20 > -- Nathan >=20 > ------------------------------------------------------------ > Nathan Neulinger EMail: nneul@umr.edu > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 >=20 >=20 > > -----Original Message----- > > From: Russ Allbery [mailto:rra@stanford.edu]=20 > > Sent: Wednesday, February 06, 2002 7:48 PM > > To: openafs-devel@openafs.org > > Subject: Re: [OpenAFS-devel] Patch to add much more=20 > > diagnostics to vos movewhen run with -verbose > >=20 > >=20 > > Derrick J Brashear writes: > > > On Wed, 6 Feb 2002, Russ Allbery wrote: > >=20 > > >> With all due respect to the people concerned with that=20 > > sort of thing, I > > >> think it's pretty unreasonable to never change the output of any > > >> command to make it more user-friendly because people are=20 > > doing things > > >> that they should never have had to do in the first place. > >=20 > > > At minimum, though, not in a minor version update to the code. > > > 1.2.3->1.2.4 should not be expected to break your scripts. > >=20 > > Oh, definitely agreed. Those are the kind of patches to save=20 > > up and do > > all at once during a major version change. > >=20 > > --=20 > > Russ Allbery (rra@stanford.edu) =20 > > > >=20 > > _______________________________________________ > > OpenAFS-devel mailing list > > OpenAFS-devel@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-devel > >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Thu Feb 7 15:59:44 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 7 Feb 2002 10:59:44 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: Message-ID: On Thu, 7 Feb 2002, Neulinger, Nathan wrote: > Seems reasonable to me... It would be nice though to get some > re-indentation/re-formatting patches applies, if for no other reason > than to ease maintaining of the other patches until they can be applied. It's another thing that belongs in a major version, and it should be done by script, not by submission of patches to the whole source, anyhow. From ota@transarc.com Thu Feb 7 16:22:21 2002 From: ota@transarc.com (Ted Anderson) Date: Thu, 7 Feb 2002 11:22:21 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: References: Message-ID: While it may not be the perfect solution, the TWiki does allow uploading/attaching files. (I haven't tried this yet though). So that might be a reasonable place to lodge patches that aren't going into the main branch for whatever reason (like maybe they are Transarc AFS patches (i.e. afs-contrib like stuff). Ted Anderson From adam@fsf.net Thu Feb 7 22:33:47 2002 From: adam@fsf.net (Adam Thornton) Date: Thu, 7 Feb 2002 16:33:47 -0600 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... Message-ID: <20020207163347.X314@dev-linux.fsf.net> Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) system. I've built and installed K5 (I'm using it as a client). After much futzing around I can make it compile. But then when I try to run aklog, I get: ./aklog: error while loading shared libraries: /usr/local/lib/libkrb5.so.3: undefined symbol: stat Which, as far as it goes, is reasonable. libkrb5 certainly doesn't provide stat. But, uh, who does? What do I need to link against to get stat to resolve? I don't remember seeing anything like this when building on S/390. Adam From warlord@MIT.EDU Thu Feb 7 22:50:05 2002 From: warlord@MIT.EDU (Derek Atkins) Date: 07 Feb 2002 17:50:05 -0500 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207163347.X314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> Message-ID: Did you try just building it from the SRPM? There is a patch to the afs-krb5-1.3 system, but the results worked fine in all my tests. Um, wait, why is it linking against /usr/local/lib/libkrb5.so.3? Don't you have the krb5 that comes with SuSE? -derek Adam Thornton writes: > Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) system. I've > built and installed K5 (I'm using it as a client). > > After much futzing around I can make it compile. But then when I try to > run aklog, I get: > > ./aklog: error while loading shared libraries: > /usr/local/lib/libkrb5.so.3: undefined symbol: stat > > Which, as far as it goes, is reasonable. libkrb5 certainly doesn't > provide stat. But, uh, who does? What do I need to link against to get > stat to resolve? I don't remember seeing anything like this when > building on S/390. > > Adam > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From adam@fsf.net Thu Feb 7 23:12:02 2002 From: adam@fsf.net (Adam Thornton) Date: Thu, 7 Feb 2002 17:12:02 -0600 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207163347.X314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> Message-ID: <20020207171202.A314@dev-linux.fsf.net> On Thu, Feb 07, 2002 at 04:33:47PM -0600, Adam Thornton wrote: > Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) system. I've > built and installed K5 (I'm using it as a client). > > After much futzing around I can make it compile. But then when I try to > run aklog, I get: > > ./aklog: error while loading shared libraries: > /usr/local/lib/libkrb5.so.3: undefined symbol: stat Hmmm. Actually it looks like it can't find stat in afsd because afsd died. That makes some sense. Now I need to figure out why afsd segfaulted. Adam From warlord@MIT.EDU Thu Feb 7 23:17:54 2002 From: warlord@MIT.EDU (Derek Atkins) Date: 07 Feb 2002 18:17:54 -0500 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207171202.A314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> <20020207171202.A314@dev-linux.fsf.net> Message-ID: Adam Thornton writes: > > ./aklog: error while loading shared libraries: > > /usr/local/lib/libkrb5.so.3: undefined symbol: stat > > Hmmm. Actually it looks like it can't find stat in afsd because afsd > died. Huh? Doesn't make sense to me. WHat does afsd have to do with stat? Note that 'stat' should be in libc. > That makes some sense. Now I need to figure out why afsd segfaulted. What version of AFS and what Linux Kernel are you using? > Adam -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From shadow@dementia.org Thu Feb 7 23:56:30 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 7 Feb 2002 18:56:30 -0500 (EST) Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: Message-ID: On 7 Feb 2002, Derek Atkins wrote: > Adam Thornton writes: > > > > ./aklog: error while loading shared libraries: > > > /usr/local/lib/libkrb5.so.3: undefined symbol: stat > > > > Hmmm. Actually it looks like it can't find stat in afsd because afsd > > died. > > Huh? Doesn't make sense to me. WHat does afsd have to do with > stat? Note that 'stat' should be in libc. I'm with Derek, and I had this problem a while ago (RH 5.2/sparc, I think) stat was versioned and i think /lib/libc.so was a loader script, and somehow i was trying to link against one of the underlying objects. Which libc do you have? From hartmans@mekinok.com Fri Feb 8 02:05:05 2002 From: hartmans@mekinok.com (Sam Hartman) Date: 07 Feb 2002 21:05:05 -0500 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: References: Message-ID: >>>>> "Ted" == Ted Anderson writes: Ted> While it may not be the perfect solution, the TWiki does Ted> allow uploading/attaching files. (I haven't tried this yet Ted> though). So that might be a reasonable place to lodge Ted> patches that aren't going into the main branch for whatever Ted> reason (like maybe they are Transarc AFS patches Ted> (i.e. afs-contrib like stuff). Why can't patches like this go onto the mainline and just not get pulled to the release branch? From hartmans@mekinok.com Fri Feb 8 02:08:07 2002 From: hartmans@mekinok.com (Sam Hartman) Date: 07 Feb 2002 21:08:07 -0500 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207163347.X314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> Message-ID: >>>>> "Adam" == Adam Thornton writes: Adam> Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) Adam> system. I've built and installed K5 (I'm using it as a Adam> client). Adam> After much futzing around I can make it compile. But then Adam> when I try to run aklog, I get: Adam> ./aklog: error while loading shared libraries: Adam> /usr/local/lib/libkrb5.so.3: undefined symbol: stat Adam> Which, as far as it goes, is reasonable. libkrb5 certainly Adam> doesn't provide stat. But, uh, who does? What do I need to Adam> link against to get stat to resolve? I don't remember Adam> seeing anything like this when building on S/390. You built krb5 incorrectly. I think the quick fix is to build both with -D_REENTRANT and to build with optimization. I believe 1.2.3 fixes this. From nneul@umr.edu Fri Feb 8 04:36:28 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Thu, 07 Feb 2002 22:36:28 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose References: Message-ID: <3C6355CC.E0E010F@umr.edu> Sam Hartman wrote: > > >>>>> "Ted" == Ted Anderson writes: > > Ted> While it may not be the perfect solution, the TWiki does > Ted> allow uploading/attaching files. (I haven't tried this yet > Ted> though). So that might be a reasonable place to lodge > Ted> patches that aren't going into the main branch for whatever > Ted> reason (like maybe they are Transarc AFS patches > Ted> (i.e. afs-contrib like stuff). > > Why can't patches like this go onto the mainline and just not get pulled to the release branch? There may be some that people want to publish, but aren't appropriate for the mainline either. MR-AFS is the one that always pops into mind... It's not widely released, yet it's still actively used. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From ota@transarc.com Fri Feb 8 13:23:10 2002 From: ota@transarc.com (Ted Anderson) Date: Fri, 8 Feb 2002 08:23:10 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: References: Message-ID: <8wMx4yg99g1Q0QzU40@transarc.com> On 07 Feb 2002 21:05:05 -0500 Sam Hartman wrote: > Ted> ... TWiki does allow uploading/attaching files. So that > Ted> might be a reasonable place to lodge patches that aren't > Ted> going into the main branch for whatever reason > > Why can't patches like this go onto the mainline and just not get > pulled to the release branch? I don't really know much about CVS. But is it really suitable for managing patches or deltas that just linger on the sidelines for an exteneded period of time? Generally patches are a problem to maintain and keep up to date. But on the otherhand it is also painful to haul a whole bunch of stuff into the main code base that is enabled only with special compilation options. There clearly isn't an ideal solution. It makes sense for possibly peripheral features to start life as a patch used and maintained by a few advocates. As the feature matures and gains adherents adding it to the mainline makes more sense. A repository where patches can live during this maturation phase seems like it might help this process. Ted From reuter@rzg.mpg.de Fri Feb 8 15:21:15 2002 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Fri, 08 Feb 2002 16:21:15 +0100 Subject: [OpenAFS-devel] patch for afs_vnop_remove.c Message-ID: <3C63ECEB.C6EB66B0@rzg.mpg.de> Hi, this caused some oopses: obviously tdc can here be zero! --- /opt/openafs/src/afs/VNOPS/afs_vnop_remove.c Wed Nov 21 17:01:31 2001+++ ./afs_vnop_remove.c Fri Feb 8 14:29:09 2002 @@ -417,7 +417,7 @@ if (adp) { tdc = afs_FindDCache(adp, 0); ObtainWriteLock(&adp->lock, 159); - ObtainSharedLock(&tdc->lock, 639); + if (tdc) ObtainSharedLock(&tdc->lock, 639); /* afsremove releases the adp & tdc locks, and does vn_rele(avc) */ code = afsremove(adp, tdc, avc, unlname, cred, &treq); ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 RZG (Rechenzentrum Garching) fax +49-89-3299-1301 Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From haba@pdc.kth.se Fri Feb 8 15:23:39 2002 From: haba@pdc.kth.se (Harald Barth) Date: Fri, 08 Feb 2002 16:23:39 +0100 (CET) Subject: [OpenAFS-devel] 1.2.3 compile barfs on AIX 4.3.3 In-Reply-To: <8wMx4yg99g1Q0QzU40@transarc.com> References: <8wMx4yg99g1Q0QzU40@transarc.com> Message-ID: <20020208.162339.103611991.haba@stacken.kth.se> On AIX 4.3.3.0 OpenAFS includes /usr/include/net/proto_net.h which wants to include . Seems that IBM has forgotten that file. Anyone with a ready workaround? Details: /* @(#)18 1.21 src/bos/kernel/net/proto_net.h, sysnet, bos43R, r1999_45B0 11/8/99 18:14:31 */ bos.adt.include 4.3.3.75 COMMITTED Base Application Development Include Files Harald. From kolya@MIT.EDU Fri Feb 8 17:30:10 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Fri, 08 Feb 2002 12:30:10 -0500 Subject: [OpenAFS-devel] patch for afs_vnop_remove.c Message-ID: <200202081730.MAA29986@pepsi-one.mit.edu> > this caused some oopses: obviously tdc can here be zero! Oops; thanks for catching this. I've applied it. -- kolya From yeejiun@yahoo.com Sat Feb 9 01:29:21 2002 From: yeejiun@yahoo.com (Yee Jiun) Date: Fri, 8 Feb 2002 17:29:21 -0800 (PST) Subject: [OpenAFS-devel] win2k compilation problems Message-ID: <20020209012921.85056.qmail@web11507.mail.yahoo.com> Hi, I downloaded release 1.2.3 and tried to compile it in the win2k environment. I followed the instructions in the README-NT file but I'm still having problems. I'm getting the following error: ---- begin --- ***** pthread cd src\WINNT\pthread nmake /nologo /f ntmakefile install cd ..\..\.. echo ***** procmgmt ***** procmgmt cd src\procmgmt nmake /nologo /f ntmakefile install link /OUT:c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.dll -debug:full -debugtype:cv -debugtype:both /NODEFAULTLIB /INCREMENTAL:NO /PDB:NON E /RELEASE /NOLOGO -entry:_DllMainCRTStartup@12 -dll /FIXED:NO msvcrt.lib oldna mes.lib kernel32.lib wsock32.lib advapi32.lib binmode.obj procmgmt_nt.obj redir ect_nt.obj afsprocmgmt.res c:\openafs-1.2.3\DEST\lib\afspthread.lib c:\openafs-1 .2.3\DEST\lib\afs\afsutil.lib /DEF:afsprocmgmt.def Creating library c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.li b and object c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.exp procmgmt_nt.obj : error LNK2001: unresolved external symbol _SwitchToThread c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.dll : fatal error LNK1 120: 1 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. NMAKE : fatal error U1077: '"c:\program files\microsoft visual studio\vc98\bin\N MAKE.EXE"' : return code '0x2' Stop. C:\OPENAF~1.3> --- end Anyone has any ideas? Yee Jiun. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From saurav_lahiri@yahoo.com Sun Feb 10 10:56:43 2002 From: saurav_lahiri@yahoo.com (=?iso-8859-1?q?SAURAV=20LAHIRI?=) Date: Sun, 10 Feb 2002 10:56:43 +0000 (GMT) Subject: [OpenAFS-devel] afsUUID uuid Message-ID: <20020210105643.15552.qmail@web11304.mail.yahoo.com> Hi, I was going through the source code for afs_server.c . I do not understand the real significance of afsUUID uuid. for instance afs_FindServer if ( !uuid) { i=SHash(aserver) and then a search is done in afs_srvAddrs Hashtable } if (uuid) { i = afs_uuid_hash(uuidp) % NSERVERS; and then a search is done in afs_Servers Hashtable. } I dont understand since all the servers are already there in afs_Servers HashTable why do we need a seperate Hash Function. and a seperate hash Table. We could have easily have given each of the servers a uuid. And the possibility of certain servers not having uuid would not have arise. Can some one explain Thanks and Regards Saurav __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From shadow@dementia.org Mon Feb 11 06:15:13 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 11 Feb 2002 01:15:13 -0500 (EST) Subject: [OpenAFS-devel] afsUUID uuid In-Reply-To: <20020210105643.15552.qmail@web11304.mail.yahoo.com> Message-ID: On Sun, 10 Feb 2002, [iso-8859-1] SAURAV LAHIRI wrote: > Hi, > I was going through the source code for afs_server.c . I do not > understand the real significance of afsUUID uuid. > for instance afs_FindServer [] > I dont understand since all the servers are already there in > afs_Servers HashTable why do we need a seperate Hash Function. and a > seperate hash Table. We could have easily have given each of the > servers a uuid. And the possibility of certain servers not having uuid > would not have arise. > Can some one explain Not all AFS versions support UUIDs. You don't arbitrarily decide the server has a UUID. -D From saurav_lahiri@yahoo.com Mon Feb 11 06:48:26 2002 From: saurav_lahiri@yahoo.com (=?iso-8859-1?q?SAURAV=20LAHIRI?=) Date: Mon, 11 Feb 2002 06:48:26 +0000 (GMT) Subject: [OpenAFS-devel] afsUUID uuid In-Reply-To: Message-ID: <20020211064826.65728.qmail@web11303.mail.yahoo.com> --- Derrick J Brashear wrote: > On Sun, 10 Feb 2002, [iso-8859-1] SAURAV LAHIRI wrote: > > > Hi, > > I was going through the source code for afs_server.c . I do not > > understand the real significance of afsUUID uuid. > > for instance afs_FindServer > > [] > > > I dont understand since all the servers are already there in > > afs_Servers HashTable why do we need a seperate Hash Function. and > a > > seperate hash Table. We could have easily have given each of the > > servers a uuid. And the possibility of certain servers not having > uuid > > would not have arise. > > Can some one explain > Hi, Derrick reply : Not all AFS versions support UUIDs. You don't arbitrarily decide the server has a UUID. My query: How does one decide that a server has UUIDs . Is it that only file servers have a uuid. It seems that when trying to locate volume location servers one uses a ip and when trying to locate a file server one uses uuid. Is it right? Thanks and Regards Saurav Lahiri __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From nneul@umr.edu Mon Feb 11 18:28:42 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Mon, 11 Feb 2002 12:28:42 -0600 Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure Message-ID: Feb 8 09:48:04 afs8 fileserver[561]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 10:05:15 afs8 fileserver[562]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 10:15:50 afs8 fileserver[567]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 12:23:17 afs8 fileserver[555]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 12:40:19 afs8 fileserver[561]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Any way to determine what volume that's on? I completely cleared one file server to another, and the failure followed with the same exact inode number, device changed though. If that's a real inode - it's rather large, and disagrees with anything on disk, so I'm assuming that's an AFS inode. It's 135,011,520 or 3,223,063,560 if LE. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From shadow@dementia.org Tue Feb 12 05:30:30 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 12 Feb 2002 00:30:30 -0500 (EST) Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure In-Reply-To: Message-ID: On Mon, 11 Feb 2002, Neulinger, Nathan wrote: > > Feb 8 09:48:04 afs8 fileserver[561]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 10:05:15 afs8 fileserver[562]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 10:15:50 afs8 fileserver[567]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 12:23:17 afs8 fileserver[555]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 12:40:19 afs8 fileserver[561]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > > Any way to determine what volume that's on? I completely cleared one > file server to another, and the failure followed with the same exact > inode number, device changed though. > > If that's a real inode - it's rather large, and disagrees with anything > on disk, so I'm assuming that's an AFS inode. > > It's 135,011,520 or 3,223,063,560 if LE. http://www.mit.edu/afs/athena/contrib/watchmaker/src/afscalc/calcfid.c note that it guesses about the volumeid, and sometimes is wrong because there's isn't enough information to readily determine it. -D From nneul@umr.edu Tue Feb 12 14:23:16 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 12 Feb 2002 08:23:16 -0600 Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure Message-ID: Bummer... it isn't coming up with a valid volume id with either interpretation of the inode value. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derrick J Brashear [mailto:shadow@dementia.org]=20 > Sent: Monday, February 11, 2002 11:31 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Error diagnosis - ReallyRead failure >=20 >=20 > On Mon, 11 Feb 2002, Neulinger, Nathan wrote: >=20 > >=20 > > Feb 8 09:48:04 afs8 fileserver[561]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 10:05:15 afs8 fileserver[562]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 10:15:50 afs8 fileserver[567]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 12:23:17 afs8 fileserver[555]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 12:40:19 afs8 fileserver[561]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > >=20 > > Any way to determine what volume that's on? I completely cleared one > > file server to another, and the failure followed with the same exact > > inode number, device changed though. > >=20 > > If that's a real inode - it's rather large, and disagrees=20 > with anything > > on disk, so I'm assuming that's an AFS inode. > >=20 > > It's 135,011,520 or 3,223,063,560 if LE. >=20 http://www.mit.edu/afs/athena/contrib/watchmaker/src/afscalc/calcfid.c note that it guesses about the volumeid, and sometimes is wrong because there's isn't enough information to readily determine it. -D _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel From ota@transarc.com Tue Feb 12 15:13:27 2002 From: ota@transarc.com (Ted Anderson) Date: Tue, 12 Feb 2002 10:13:27 -0500 (EST) Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure In-Reply-To: References: Message-ID: The problem is that that these print statements are in error. They contain a %X but are passed a (pointer to) a string representation of the inode value. >From viced/physio.c:82: ViceLog (0, ("ReallyRead(): read failed device %X inode %X errno %d\n", file->dirh_handle->ih_dev, PrintInode(NULL, file->dirh_handle->ih_ino), code)); Where PrintInode is defined in sys/afssyscalls.h as: extern char *PrintInode(afs_ino_str_t, Inode); So the (second) %X needs to be turned into a %s. A quick scan of src/viced turns up several more of these. Ted Anderson From nneul@umr.edu Tue Feb 12 18:30:39 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 12 Feb 2002 12:30:39 -0600 Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure Message-ID: just sent a patch for the ones in viced, have not checked over all the instances elsewhere in src yet. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Ted Anderson [mailto:ota@transarc.com]=20 > Sent: Tuesday, February 12, 2002 9:13 AM > To: openafs-devel@openafs.org; Neulinger, Nathan > Subject: Re: [OpenAFS-devel] Error diagnosis - ReallyRead failure >=20 >=20 > The problem is that that these print statements are in error. They > contain a %X but are passed a (pointer to) a string representation of > the inode value. >=20 > From viced/physio.c:82: > ViceLog (0, > ("ReallyRead(): read failed device %X inode %X=20 > errno %d\n", > file->dirh_handle->ih_dev, > PrintInode(NULL, file->dirh_handle->ih_ino), code)); > Where PrintInode is defined in sys/afssyscalls.h as: > extern char *PrintInode(afs_ino_str_t, Inode); >=20 > So the (second) %X needs to be turned into a %s. A quick scan of > src/viced turns up several more of these. >=20 > Ted Anderson >=20 From haba@pdc.kth.se Tue Feb 12 22:26:12 2002 From: haba@pdc.kth.se (Harald Barth) Date: Tue, 12 Feb 2002 23:26:12 +0100 (CET) Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure In-Reply-To: References: Message-ID: <20020212.232612.68034577.haba@pdc.kth.se> > Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > > Any way to determine what volume that's on? I completely cleared one > file server to another, and the failure followed with the same exact > inode number, device changed though. I don't know what is going on eiher , but I _did_ post a very similar question 2001-01-30 18:41. It is archived at https://lists.openafs.org/pipermail/openafs-devel/2002-January/002475.html And yes, I am still curious if someone knows the answer to my question The error handling could be improved in this case. As it is now, the error message tells the admin incomplete or misleading information and does that in the wrong way. Harald. n From nneul@umr.edu Wed Feb 13 13:54:05 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Wed, 13 Feb 2002 07:54:05 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow References: <20020213040914.470119C3F@grand.central.org> Message-ID: <3C6A6FFD.5C011E11@umr.edu> cvs@GRAND.CENTRAL.ORG wrote: > > Update of /cvs/openafs/src/rxgen > In directory GRAND.CENTRAL.ORG:/data/sb/openafs/src/rxgen > > Modified Files: > rpc_hout.c rpc_parse.c rpc_parse.h > Log Message: > DELTA rxgen-generate-function-prototypes-20020212 > AUTHOR bartbanter@hotmail.com > > actually from David Howells of Red Hat. > generates function prototypes in rxgen-emitted headers > > --- DELTA config follows --- > rxgen-generate-function-prototypes-20020212 openafs/src/rxgen/rpc_hout.c 1.4 1.5 > rxgen-generate-function-prototypes-20020212 openafs/src/rxgen/rpc_parse.c 1.11 1.12 > rxgen-generate-function-prototypes-20020212 openafs/src/rxgen/rpc_parse.h 1.1 1.2 > _______________________________________________ > OpenAFS-cvs mailing list > OpenAFS-cvs@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-cvs Hey, wait a minute... I thought we weren't supposed to have prototypes in those headers cause they could be used with kernel compiles? -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From derek@ihtfp.com Wed Feb 13 14:12:17 2002 From: derek@ihtfp.com (Derek Atkins) Date: 13 Feb 2002 09:12:17 -0500 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: <3C6A6FFD.5C011E11@umr.edu> References: <20020213040914.470119C3F@grand.central.org> <3C6A6FFD.5C011E11@umr.edu> Message-ID: Nathan Neulinger writes: > Hey, wait a minute... I thought we weren't supposed to have prototypes > in those headers cause they could be used with kernel compiles? Um, what's wrong with prototypes for kernel compiles? The point of prototypes are to get compiler warnings when you use a function improperly. > -- Nathan -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From nneul@umr.edu Wed Feb 13 14:17:13 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 08:17:13 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: Well, there has always been a history of "don't use prototypes" in the AFS source cause of certain kernel-compilers not being able to handle it. Or at least, be very careful about where they are used... Dig back in archives about the _P() discussion.=20 I'm not disagreeing with their use (I've held back on a ton of cleanup that would have added LOTS more prototyping), I'm just wondering about what appears to be a sudden change in policy.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com]=20 > Sent: Wednesday, February 13, 2002 8:12 AM > To: Neulinger, Nathan > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Re: OpenAFS CVS Commit:=20 > openafs/src/rxgen by shadow >=20 >=20 > Nathan Neulinger writes: >=20 > > Hey, wait a minute... I thought we weren't supposed to have=20 > prototypes > > in those headers cause they could be used with kernel compiles? >=20 > Um, what's wrong with prototypes for kernel compiles? The point of > prototypes are to get compiler warnings when you use a function > improperly. >=20 > > -- Nathan >=20 > -derek >=20 > --=20 > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com >=20 From mbacchi@btv.ibm.com Wed Feb 13 15:27:25 2002 From: mbacchi@btv.ibm.com (Matthew A. Bacchi) Date: Wed, 13 Feb 2002 10:27:25 -0500 Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 Message-ID: <200202131527.KAA40014@bilbo.btv.ibm.com> Did bos.adt.include 4.3.3.75 forget it? Or did you accidently remove it? # lslpp -l bos.adt.include Fileset Level State Description = -----------------------------------------------------------------------= ----- Path: /usr/lib/objrepos bos.adt.include 4.3.3.12 COMMITTED Base Application Develop= ment Include Files ------------------------ # ls -l /usr/include/net/proto_net.h -r--r--r-- 1 bin bin 18735 Nov 10 1999 /usr/include/net/pr= oto_net.h /** ** Matt Bacchi mbacchi@us.ibm.com ** IBM Global Services SDC Northeast ** F6TG; MD Filesystems/Internet (802) 769-4072 ** ADSM & AFS/DFS Backup (tie) 446-4072 **/ From haba@pdc.kth.se Wed Feb 13 16:33:09 2002 From: haba@pdc.kth.se (Harald Barth) Date: Wed, 13 Feb 2002 17:33:09 +0100 (CET) Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 In-Reply-To: <200202131527.KAA40014@bilbo.btv.ibm.com> References: <200202131527.KAA40014@bilbo.btv.ibm.com> Message-ID: <20020213.173309.79422363.haba@pdc.kth.se> This is AIX specific, so anyone not concerned with AIX can skip this. I am talking about that /usr/include/sys/call_ie.h is missing from bos.adt.include because /usr/include/net/proto_net.h version 1.21 needs it. I have got /usr/include/net/proto_net.h from bos.adt.include so /usr/include/sys/call_ie.h should be in bos.adt.include or in another set that is required by bos.adt.include. If I comment out the atm crap from proto_net.h I actually get all the way through make dest. I have not tested the result yet. I wonder if IBM has a "compile kernel module" regression test prior to shipping bos.adt.include 4.3.3.79? Harald. From shadow@dementia.org Wed Feb 13 17:50:13 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 12:50:13 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > Well, there has always been a history of "don't use prototypes" in the > AFS source cause of certain kernel-compilers not being able to handle > it. Or at least, be very careful about where they are used... Dig back > in archives about the _P() discussion. Yeah, and we may well need to do this. > > I'm not disagreeing with their use (I've held back on a ton of cleanup > that would have added LOTS more prototyping), I'm just wondering about > what appears to be a sudden change in policy. There was one serious issue remaining in the head which was making the client go south on Linux. It's fixed. You were going to see a proposal here shortly about prototypes, but instead I'll just give the short version. Please, by all means, let's discuss it. -all functions prototyped, starting with kernel. this patch provides an opporunity to explore what if any kernel compilers suck. -all functions in kernel not being used outside local file actually changed to "static" -all prototypes for use outside file actually in header and correct, not just () and then the rest of the code: -more or less same deal, but obviously not changing bits of the API to "static" even if nothing is obviously "using" them -new header for prototypes, or "abuse" the existing main header for each system? (leaning toward the latter) From nneul@umr.edu Wed Feb 13 18:01:57 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 12:01:57 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: > -all functions prototyped, starting with kernel. this patch=20 > provides an > opporunity to explore what if any kernel compilers suck. > -all functions in kernel not being used outside local file actually > changed to "static" > -all prototypes for use outside file actually in header and=20 > correct, not > just () Sounds great to me! Standard prototypes or using _P()? Worst case scenario can hardwire _P() to blank when doing kernel compiles on affected systems. > and then the rest of the code: > -more or less same deal, but obviously not changing bits of the API to > "static" even if nothing is obviously "using" them > -new header for prototypes, or "abuse" the existing main=20 > header for each > system? (leaning toward the latter) Well, having them in the main header for each system (I presume you mean vos/pts/etc. for the system) seems like a reasonable approach to me, however, I'd like to see them organized in the headers consistently. I.e. always in a block at the end of the header, or something like that. Right now, they are pretty badly scattered. Similarly in some of the source files, there are scattered places where a .c file will include a prototype for a function outside that file, I'd like to see that go away.=20 I personally like to autogenerate prototypes (cfunc) but I think that'd be a bit messy here, although it would make using separate .h files for prototypes really easy.=20 I might add to that list - get the data type usage of the routines (including APIs) consistent. I started to do some of this way back, and got that committed, but there's a ton left to do. Also use of 'const' where appropriate. What about ANSI v. K&R on the routines themselves? I'll definately dig in on this when you're ready to move on it, cause it's the type of cleanup/rework stuff I usually enjoy working on.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From mbacchi@btv.ibm.com Wed Feb 13 18:22:55 2002 From: mbacchi@btv.ibm.com (Matthew A. Bacchi) Date: Wed, 13 Feb 2002 13:22:55 -0500 Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 In-Reply-To: Your message of "Wed, 13 Feb 2002 17:33:09 +0100." <20020213.173309.79422363.haba@pdc.kth.se> Message-ID: <200202131822.NAA40666@bilbo.btv.ibm.com> > = > I wonder if IBM has a "compile kernel module" regression test = > prior to shipping bos.adt.include 4.3.3.79? Harald, I see your point. I looked into this a little on an internal website(I t= hink = it's internal, if you can go to "http://rshelp.austin.ibm.com" then it's = not = internal), and it appears that this will not be fixed at AIX 4.3.3. From= what = I gather, they can't just add it to bos.adt.include, because it's already= in = devices.common.IBM.atm.rte, and this conflict can't(won't?) be fixed unti= l a = more major release. Thier workaround seems to be to install the atm fileset. Or I guess you c= ould = stick with your workaround of removing the stuff which would be in the at= m = header file. -Matt From shadow@dementia.org Wed Feb 13 18:23:46 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 13:23:46 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > Sounds great to me! Standard prototypes or using _P()? > > Worst case scenario can hardwire _P() to blank when doing kernel > compiles on affected systems. If there are no systems which need _P() now there's not much point in using it; We're not likely to port to old crufty systems, we already have ports for all of them. The only port I can't check is HPUX 11. > What about ANSI v. K&R on the routines themselves? presumably ansi, if we can do it safely. K&R is dead. > I'll definately dig in on this when you're ready to move on it, cause > it's the type of cleanup/rework stuff I usually enjoy working on. no time like the present. let's figure out what we're doing and do it. From adam@fsf.net Wed Feb 13 18:46:27 2002 From: adam@fsf.net (Adam Thornton) Date: Wed, 13 Feb 2002 12:46:27 -0600 Subject: [OpenAFS-devel] Aaargh! Incompatible includes. Message-ID: <20020213124627.A6029@dev-linux.fsf.net> How hard would it be to make OpenAFS rely on the more-or-less-standard-by-now set of includes that OpenSSL and most (Linux, anyway) distributions provide? I ask, because I've been having the very devil of a time getting AFS to build on a SuSE 7.3 Pro system, or to get AFS to play nicely with Samba 2.2.3 built with the --with-afs configuration option. And let's not even go into SASL 2 and Cyrus IMAPD, which really ought to be able to use AFS ACLs since that's what its faking on a normal filesystem. I still haven't even gotten afsd to run on a SuSE 7.3 Pro (i386) system; it immediately segfaults; probably because it's picking up the wrong library somewhere, but I haven't had time to investigate. It mostly seems to be traceable to differing sets of header files and libraries; the XDR headers in rpc are one set whose different interpretations cause SuSE 7.0+patches on S/390 to refuse to build Samba with the --with-afs option; for another, AFS, OpenSSL, and MIT K5 all appear to use mutually incompatible DES headers. I just want to build OpenAFS to use MIT K5 as its authentication source, and integrate with Samba and Cyrus IMAPD. It really shouldn't be as hard as it is. Adam From nneul@umr.edu Wed Feb 13 18:56:46 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 12:56:46 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: > > Sounds great to me! Standard prototypes or using _P()? > >=20 > > Worst case scenario can hardwire _P() to blank when doing kernel > > compiles on affected systems. >=20 > If there are no systems which need _P() now there's not much point in > using it; We're not likely to port to old crufty systems, we=20 > already have > ports for all of them. The only port I can't check is HPUX 11. Have builds worked ok on all the systems since that rxgen change? Actually, I can test that one easily enough, just not a full kernel compile. As far as I know, on hpux 11, the compile that is used is fully ansi and prototype capable. It's using the -Ae option, and usually on HP-UX when -Ae or -Aa are used, they are a halfway reasonable compiler. > > What about ANSI v. K&R on the routines themselves? >=20 > presumably ansi, if we can do it safely. K&R is dead. >=20 > > I'll definately dig in on this when you're ready to move on=20 > it, cause > > it's the type of cleanup/rework stuff I usually enjoy working on.=20 >=20 > no time like the present. let's figure out what we're doing and do it. What about the: int x(void) vs. int x() issue? Should void be used, or should a blank parameter list be used? I'd say that your list, w/ a little editing and expansion, could just be added to README.DEVEL, and then we can start with the changes just in the afs/libafs dirs as you mention as a starting point. It might also be worth suggesting that each C file document where it's prototypes should be located somewhere near the top of the file. I'm not sure if the prototype list should indicate the file the prototype is for, but that might not be a bad idea. i.e. /* Prototypes */ /* afs_osi.c */ void osi_Init(); ... /* afs_util.c */ char *afs_cv2string(char *, afs_uint32); ... /* End of prototypes */ I need to look at cfunc again. If we segment out the block of prototypes with distinct marker strings, we might be able to leverage cfunc to do some of the initial work on generating the prototypes. Wouldn't be necessary initially, but might make auditting the whole source for completeness easier. Is there a gcc option to absolutely require prototypes? I guess -Wall -Werror might be a reasonable check, but liable to be more trouble than it's worth. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From shadow@dementia.org Wed Feb 13 18:55:24 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 13:55:24 -0500 (EST) Subject: [OpenAFS-devel] Aaargh! Incompatible includes. In-Reply-To: <20020213124627.A6029@dev-linux.fsf.net> Message-ID: On Wed, 13 Feb 2002, Adam Thornton wrote: > How hard would it be to make OpenAFS rely on the > more-or-less-standard-by-now set of includes that OpenSSL and most > (Linux, anyway) distributions provide? Relying on external packages violates a constraint we've been working under for a while, but: > It mostly seems to be traceable to differing sets of header files and > libraries; the XDR headers in rpc are one set whose different > interpretations cause SuSE 7.0+patches on S/390 to refuse to build Samba > with the --with-afs option this should be fixable; it's been fixed for all the other platforms which had similar problems > for another, AFS, OpenSSL, and MIT K5 all > appear to use mutually incompatible DES headers. I haven't looked in a while but last I did the types may have been different but the net result was the same. Has something changed? I have ADM building against AFS, Heimdal, OpenSSL, SASL and libcyrus, and yes, all being linked into one binary. I did need to explore this, and honestly I don't remember what the answer was. -D From nneul@umr.edu Wed Feb 13 19:02:08 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 13:02:08 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: What do we want to do for cases like afs_osi.c and afs_osi.h. Some of the files in afs/ have their own .h files, others don't. Should the prototypes go in the afs_osi.h file, or afs.h, or somewhere else entirely? I tend to wonder if it might be cleaner to add a X_proto.h file for each dir X/ that would contain prototypes and externs only, and move all the prototypes to there, and just include that prototypes file in appropriate places. For some of the other subsystems it's not as confusing, they already have distinct header files, but it still may be easier for auditing to segregate. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From openafs-devel@openafs.org Wed Feb 13 18:56:24 2002 From: openafs-devel@openafs.org (Derek Atkins) Date: 13 Feb 2002 13:56:24 -0500 Subject: [OpenAFS-devel] Aaargh! Incompatible includes. In-Reply-To: <20020213124627.A6029@dev-linux.fsf.net> References: <20020213124627.A6029@dev-linux.fsf.net> Message-ID: Adam Thornton writes: > I just want to build OpenAFS to use MIT K5 as its authentication source, > and integrate with Samba and Cyrus IMAPD. It really shouldn't be as > hard as it is. I dont know what's so special about SuSE -- the Red Hat RPMS build OpenAFS and use MIT K5 as its authentication source. It works just fine. Yes, there are compiler warnings during the build process, but I've found that they can pretty much all be safely ignored. What errors, in partcular, are you seeing? > Adam -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From shadow@dementia.org Wed Feb 13 19:24:49 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 14:24:49 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > > already have > > ports for all of them. The only port I can't check is HPUX 11. > > Have builds worked ok on all the systems since that rxgen change? Can't tell you authoritatively, I'm unable to log into my AIX box, but that will be resolved shortly. > Actually, I can test that one easily enough, just not a full kernel > compile. As far as I know, on hpux 11, the compile that is used is fully > ansi and prototype capable. It's using the -Ae option, and usually on > HP-UX when -Ae or -Aa are used, they are a halfway reasonable compiler. > What about the: > > int x(void) > vs. > int x() > > issue? Should void be used, or should a blank parameter list be used? the former makes more sense, but i know recently i had an issue where a compile objected; i just wish i could remember what and where. (it might have been a c++ compiler, in which case i don't care; fingers in too many pies means i can't remember what's what) From nneul@umr.edu Wed Feb 13 19:51:22 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 13:51:22 -0600 Subject: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() Message-ID: Is it really necessary to have AFS_GLOCK()/GUNLOCK() wrapped with an #ifdef RX_ENABLE_LOCKS everywhere in the source? It appears that the definitions of those macros are #ifdef'd already. Seems like it would clean up the code quite a bit to get rid of all the spurious ifdef's.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From kolya@MIT.EDU Wed Feb 13 20:11:29 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Wed, 13 Feb 2002 15:11:29 -0500 Subject: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() Message-ID: <200202132011.PAA14906@pepsi-one.mit.edu> > Is it really necessary to have AFS_GLOCK()/GUNLOCK() wrapped with an > #ifdef RX_ENABLE_LOCKS everywhere in the source? It appears that the > definitions of those macros are #ifdef'd already. Seems like it would > clean up the code quite a bit to get rid of all the spurious ifdef's. There's RX_AFS_GLOCK() and RX_AFS_GUNLOCK() in the mainline (which I snuck in with the dcache locking changes), which are defined to be AFS_GLOCK/AFS_GUNLOCK when RX_ENABLE_LOCKS is set, and blank otherwise. So, you can replace the #ifdef/AFS_GLOCK/#endif combo with RX_AFS_GLOCK, etc, if you want. -- kolya From nneul@umr.edu Wed Feb 13 20:22:33 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 14:22:33 -0600 Subject: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() Message-ID: Cool. Yeah, that'll clean the code in afs/ up nicely.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Nickolai Zeldovich [mailto:kolya@MIT.EDU]=20 > Sent: Wednesday, February 13, 2002 2:11 PM > To: Neulinger, Nathan > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() >=20 >=20 > > Is it really necessary to have AFS_GLOCK()/GUNLOCK() wrapped with an > > #ifdef RX_ENABLE_LOCKS everywhere in the source? It appears that the > > definitions of those macros are #ifdef'd already. Seems=20 > like it would > > clean up the code quite a bit to get rid of all the=20 > spurious ifdef's.=20 >=20 > There's RX_AFS_GLOCK() and RX_AFS_GUNLOCK() in the mainline (which > I snuck in with the dcache locking changes), which are defined to > be AFS_GLOCK/AFS_GUNLOCK when RX_ENABLE_LOCKS is set, and blank > otherwise. So, you can replace the #ifdef/AFS_GLOCK/#endif combo > with RX_AFS_GLOCK, etc, if you want. >=20 > -- kolya >=20 From shadow@dementia.org Wed Feb 13 22:54:47 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 17:54:47 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Derrick J Brashear wrote: > On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > > > > already have > > > ports for all of them. The only port I can't check is HPUX 11. > > > > Have builds worked ok on all the systems since that rxgen change? > > Can't tell you authoritatively, I'm unable to log into my AIX box, but > that will be resolved shortly. Of course, I built the wrong tree after the patch, there's work to be done to resolve it; I'm working on it now. -D From luan@almaden.ibm.com Thu Feb 14 02:35:35 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Wed, 13 Feb 2002 18:35:35 -0800 Subject: [OpenAFS-devel] Java API for AFS Admin Message-ID: We briefly discussed this topic earlier. A list of Javadoc HTML files defining a proposed Java API for AFS Admin are now available at http://grand.central.org/twiki/bin/edit/AFSLore/JavaAdminAPI for your review. We especially look forward to the feedback from experienced administrators as well as those who have written tools for managing AFS. Here is the rationale for having such an API: In large AFS environments, local tools are frequently developed to manage AFS more effectively. Today these tools are usually written in scripts. These scripts typically issue AFS commands and parse the command output. This is not a good practice as command output are not well defined. Their format or even contents can change in new releases. An AFS Admin API is needed. Today some internal C libraries exist and are used by the AFS command suite as well as the Windows Admin GUI. But they are not clearly defined for external use. Here a set of Java Admin API is proposed. The goal is to make the API suitable not only for administrators to write custom AFS automation tools but also for developers to write general and powerful tools for easy and efficient AFS management. Shyh-Wei Luan From luan@almaden.ibm.com Thu Feb 14 02:48:57 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Wed, 13 Feb 2002 18:48:57 -0800 Subject: [OpenAFS-devel] Java API for AFS Admin -- CORRECTION! Message-ID: Oops, I gave a wrong URL earlier that would send everyone to the editing window for the Wiki topic. The following is the correct URL for viewing. Please use this one instead. http://grand.central.org/twiki/bin/view/AFSLore/JavaAdminAPI Sorry for the mistake. Shyh-Wei Luan Shyh-Wei Luan/Almaden/IBM@IBMUS@openafs.org on 02/13/2002 06:35:35 PM Sent by: openafs-devel-admin@openafs.org To: openafs-devel@openafs.org cc: Subject: [OpenAFS-devel] Java API for AFS Admin We briefly discussed this topic earlier. A list of Javadoc HTML files defining a proposed Java API for AFS Admin are now available at http://grand.central.org/twiki/bin/edit/AFSLore/JavaAdminAPI for your review. We especially look forward to the feedback from experienced administrators as well as those who have written tools for managing AFS. Here is the rationale for having such an API: In large AFS environments, local tools are frequently developed to manage AFS more effectively. Today these tools are usually written in scripts. These scripts typically issue AFS commands and parse the command output. This is not a good practice as command output are not well defined. Their format or even contents can change in new releases. An AFS Admin API is needed. Today some internal C libraries exist and are used by the AFS command suite as well as the Windows Admin GUI. But they are not clearly defined for external use. Here a set of Java Admin API is proposed. The goal is to make the API suitable not only for administrators to write custom AFS automation tools but also for developers to write general and powerful tools for easy and efficient AFS management. Shyh-Wei Luan _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel From luan@almaden.ibm.com Thu Feb 14 07:07:59 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Wed, 13 Feb 2002 23:07:59 -0800 Subject: [OpenAFS-devel] Java API for AFS Admin Message-ID: We don't need to deal with the RPC. The implementation of the Java API could communicate with the native AFS administrative library (libadmin, which is already available in OpenAFS) through a JNI (Java Native Interface) layer. The libadmin library is currently used for the implementation of the AFS command suite and the Windows Admin GUI. But it is not a documented external API. The idea is to build a well-defined and easy-to-use Java API around this C library, so that powerful Java-based management tools can be easily developed. Shyh-Wei Luan Jimmy Engelbrecht @e.kth.se on 02/13/2002 09:25:10 PM Sent by: jimmy@e.kth.se To: Shyh-Wei Luan/Almaden/IBM@IBMUS cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Java API for AFS Admin "Shyh-Wei Luan" writes: > Here a set of Java Admin API is proposed. The goal is to make the API > suitable not only for administrators to write custom AFS automation tools > but also for developers to write general and powerful tools for easy and > efficient AFS management. I have some questions. As you know the different servers allow you to do a few hundred different RPC-calls, is the idea that all of them should be accessible though the java-API ? How do you want to do RPC-calls from java ? Is there a usefull and working package that can do that for you ? You want to generate the RPC-stubs yourself ? Or you just steal the stubs from some exsisting AFS-implementation ? /Jimmy From nneul@umr.edu Thu Feb 14 20:26:33 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 14 Feb 2002 14:26:33 -0600 Subject: [OpenAFS-devel] cool, already found something from prototype work Message-ID: =09 in VNOPS/afs_vnop_lookup.c: if (tvcp && retry) { ReleaseWriteLock(&afs_xvcache); afs_PutVCache(tvcp); } } while (tvcp && retry); everywere else, afs_PutVCache() takes two arguments, the second is a lock type.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Thu Feb 14 20:38:56 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 14 Feb 2002 14:38:56 -0600 Subject: [OpenAFS-devel] cool, already found something from prototype work Message-ID: BTW, there are a whole pile of these mismatches in that file. In my local checkout I'm just making second arg 0, but would be good for someone more knowledgable to commit a more appropriate fix. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Neulinger, Nathan=20 > Sent: Thursday, February 14, 2002 2:27 PM > To: openafs-devel@openafs.org > Subject: [OpenAFS-devel] cool, already found something from=20 > prototype work >=20 >=20 > =09 >=20 > in VNOPS/afs_vnop_lookup.c: >=20 > if (tvcp && retry) { > ReleaseWriteLock(&afs_xvcache); > afs_PutVCache(tvcp); > } > } while (tvcp && retry); >=20 > everywere else, afs_PutVCache() takes two arguments, the second is a > lock type.=20 >=20 > -- Nathan >=20 > ------------------------------------------------------------ > Nathan Neulinger EMail: nneul@umr.edu > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Thu Feb 14 20:40:49 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 14 Feb 2002 15:40:49 -0500 (EST) Subject: [OpenAFS-devel] cool, already found something from prototype work In-Reply-To: Message-ID: On Thu, 14 Feb 2002, Neulinger, Nathan wrote: > in VNOPS/afs_vnop_lookup.c: > > if (tvcp && retry) { > ReleaseWriteLock(&afs_xvcache); > afs_PutVCache(tvcp); > } > } while (tvcp && retry); > > everywere else, afs_PutVCache() takes two arguments, the second is a > lock type. Yabut PutVCache is: ObtainReadLock(&afs_xvcache); AFS_FAST_RELE(avc); ReleaseReadLock(&afs_xvcache); Useful to fix, but not a real problem -D From nneul@umr.edu Thu Feb 14 20:45:26 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 14 Feb 2002 14:45:26 -0600 Subject: [OpenAFS-devel] cool, already found something from prototypework Message-ID: That's rather scary... Cause there are cases where PutVCache is called with a parameter of WRITE_LOCK.=20 No matter. It won't compile without the argument if prototyped.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derrick J Brashear [mailto:shadow@dementia.org]=20 > Sent: Thursday, February 14, 2002 2:41 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] cool, already found something=20 > from prototypework >=20 >=20 > On Thu, 14 Feb 2002, Neulinger, Nathan wrote: >=20 > > in VNOPS/afs_vnop_lookup.c: > > > > if (tvcp && retry) { > > ReleaseWriteLock(&afs_xvcache); > > afs_PutVCache(tvcp); > > } > > } while (tvcp && retry); > > > > everywere else, afs_PutVCache() takes two arguments, the second is a > > lock type. >=20 > Yabut PutVCache is: > ObtainReadLock(&afs_xvcache); > AFS_FAST_RELE(avc); > ReleaseReadLock(&afs_xvcache); >=20 > Useful to fix, but not a real problem > -D >=20 >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From nneul@umr.edu Thu Feb 14 21:34:55 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Thu, 14 Feb 2002 15:34:55 -0600 Subject: [OpenAFS-devel] starter patch for prototypes... Message-ID: <20020214213454.GA8370@umr.edu> --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (This includes three local patches marked UMR-ONLY, I just haven't edited them out for this.) Would appreciate hearing any comments on how this has been done... Documentation change for README.DEVEL is in afsdoc.diff. I'd also be interested in hearing if anyone has any trouble compiling with this patch applied. I've tested on sun4x_56, and i386_linux24. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="afsdoc.diff" Index: README.DEVEL =================================================================== RCS file: /cvs/openafs/README.DEVEL,v retrieving revision 1.2 diff -u -r1.2 README.DEVEL --- README.DEVEL 2002/01/02 04:12:20 1.2 +++ README.DEVEL 2002/02/14 17:52:42 @@ -16,3 +16,51 @@ Try to test builds using gmake -j # MAKE="gmake -j #", it seems like a good way to find missing or order-dependent dependency rules. (Is there a better way to do this?) + +-- Prototyping and Style -- +Prototypes for all source files in a given dir DDD should be placed +int the file DDD/DDD_prototypes.h. All externally used (either API +or used by other source files) routines and variables should be +prototyped in this file. + +The prototypes should be a full prototype, with argument and return +types. (Should not generate a warning with gcc -Wstrict-prototypes.) + +Format of the prototype files should look like: + + Standard Copyright Notice + + #ifdef AFS_SRC_DDD_PROTO_H + #define AFS_SRC_DDD_PROTO_H + + /* filename.c */ + prototypes + + /* filename.c */ + prototypes + + #endif /* AFS_SRC_DDD_PROTO_H */ + +The declaration of the routines should be done in ANSI style: (can we +do this safely on all platforms? might want to use ansi2knr if not) + + rettype routine(argtype arg) + { + + } + +All routines should have a return type specified, void if nothing returned, +and should have (void) if no arguments are taken. (still checking on this +to make sure it works everywhere) + +Header files should not contain macros or other definitions unless they +are used across multiple source files. + +All routines should be declared static if they are not used outside that +source file. + +Compiles on gcc-using machines should strive to handle using +-Wstrict-prototypes -Werror. (this may take a while) + +Routines shall be defined in source prior to use if possible, and +prototyped in block at top of file if static. --pf9I7BMVVzbSWLtt Content-Type: application/octet-stream Content-Disposition: attachment; filename="afs.diff.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWS0q3RcAUaj/gH/+hkd7/////+///7////9gZH999lo+tdC+9wF8hnuYAaCt d7vj32zQUnei7ust96vvl5097p973PuK+d9qve6PTuw7aQLHu5Z29bod282tDpiGjJx72R7x 5DAL3PdePb7Grd0vOfbvvju3RXK2AaB6drhyPQPXQ909ZDkW2IjZc3TnGOuS24Id1rbo3MM1 2aXbq3XVLqLYA0bNWZdrYXbX3t09pu3dN6HVXW6fACtc977289vabvtq+sT7DyYvtve+znqr TL3YfPC3UuNEIm7Vybu5O2tmRcqW2TVd8vLjwLmK0lbjw+2+982t7t3VPo95tG99xz293dO5 oidYxvtuvWvWeAlNEEAIAICZGTSZMk2kbQUT/RBqBlHtSYINPU0aekeo8oNNAEghCZDSTJ6m p5E9qNT1NGjTanlA0aGgDQ0AAAaAxpIiU0pkfpQbSepoz1T0gHqHqaPakNAAANAAGgYgGgk0 kRCTTQmJo0GgTBFNkjamnmhop6m1PIgeUBoDT1MgyMgiSIETU8UwGkZGQTBFT/I0GhpAp5pq mnqZPTRqG1NMTQyGjCJEggJppoIMTU0yaqfkk/NU2p6app5TaYUeoPSBoAAAA9R2vjuEohED 4QoiRgoyCiHlAQCiKKF4hQQkAFGSQFP4yRFaQIJD5HD758matkoNBkKUpSlA+U0uBwOBoiXm WwjdOGEaGoyKQYMLLLC1wQWQh9W+2whiOYxgxzGJEzMwyLAYiIIgsR1Ov9X9E/n/7QT+mBl7 YaSJrGJBi6xiQbLUflouXIx1MVBFRYiqKqRFiwRjBiKDFxXFcVEAWIKLMVxXFzMMgoM8ni+6 60dfovh/X04NaG/21tWGSQEkS/N+Pt78XpHb1/ONIwxeRTLNFgfX5S9Z/xbkTUYpFEVBYR8e jX7Ty+cnkrA9UYCTDI88qPkbaYodLFgxrC5KW2Uwb36yFii9iIPSRrOIWxgsFRRYcovK8zWC U1SEiRDQqggsfT9UQuqH9PqDxP/phxba/z9XWvfZRnR566zTt8uii6RYcuW5lgbcbTCOQy0n CvO9a0G2ZrnMcEL+e4/aycHnuknFo29K4Z13cQTfOY8CsKaOHA5jvCgnDrBs3rUw7Nhzpwch whI2YmseyF1Nmb8dExrytNRkYhsiusbqbVW7XPteW2LKSVDElShFqPjLlxydL63QW6yci10K sab7l2ukXG1di1DKIlzWq2qooKGmGapp0i6az236edHLdVHlALjeXHToCs6ZreYKQ8vEsXzO pMRrVez5jNSZYd18YMNTqDLbZ0EhdIuvJzp0IjulYqNyo4kRlgjbPEyaXLNSiSlYVG41JjGC M4bLa1VY2JR8uQwy0WS2wHUIXYzBwDDih2yS6LabYUad9CuJLUpF9vpQ6O7iZ5i+H0vPBDaV si82DXxt7VeSdY71HMsdeiRUUjm0oJSwk8KJbE0wkk6EM//bYOWo6/VqhSvpHxNdCI/dGdf9 u2V6kmvsKQO0t7+pH6ocaW0p5V3SrN5tZmSZYPwHxfV4fZm9nmLzcN4AfccmvQutoU7OLI9Y a8NvnaLZ2b8vS3rFUc9MtVXdpZGvF392dI4LiqugpTiZlDJFErRnNhJqLrolVZ+zO6otAlrD eCa0ClHZZZeCu1WXed4m+l48Vl3vPLdYM6ZmHaEqBpkxkUmMqDXDSYSVAPuMlSYoh5RKOxMC BIDEgSISvb76SS9vMKCa8r3QXFozM5a8TkFZ6QWlQbVy7+37315Ws2xZrnK/BSToSo0p9Nns 9vy/M/ueI+b8EkKkUVVFZUxx4hnDpMyTIVTPVpYsWLCtYqtbWFVVVrVa1Va1WsKxVkFnsaqu IVsZFgqIixgjBQiiwVURFZFFFiwKPwDNs0laaS48NdRd5UwxPKK6oSF49cfXz6ySiENoTmzj AxgcaMlW+mt6iKPShpS2KVLlxJVRTHLdZKcEk1mQk6pCLC7sAORg58OCm2TTalCAiwGPBZFK HNKADJI5ZJUhbLwJQYaCJAxgbGBvKFA2UJaYzzOgel9KG2SBMUU4+6lNY65Vf2UiXG4JHAtR WHCFQxG2c/fPvIoKpFFJ4GxGIptAUOlw9kEde/jqEqE2uZMCd6acthbRiKLlKdfLeWcO/2tF BBDLReHjKaalW6yFcaWnO/rydGbVBZOGnHGGorDTJeN5tm2cMqAcKiwl3nUbgHuIJcBhDPNu 6B8abJY1nld2DQN3hLbcMMiYLVzO88aKCqRRSeHOj5noG5/kjYv1IwUP6YLUSVysTHF+dfyR NvB3EhpuPbXM70vLe4diaPTTWm7c5tdJdcOHudKcIapZ3eRZpHPPGXKD8uLmJdyZLBeGHc4t AkdqQrfmluX3MzCslHl5rc+uRqRZZlxnpXA7LwzoseUDsvTE7YszxJzs+UZmtDLHvbwPHw6i kvTKhDdjkfI4f+0XWgAgfeAg8ZH+UBtAhAZFWEBhOO9HJYpLwCSQJFXkiJ6/L7srgc8OEPBB XWTVIa0KfBBvOEqBeDM3xb5AzvvEkDZbBN0goSskUIbyyBxgpgIMRQQKnjNkJFykIoIgXhRB IozzX9noiJREbKxSKwH2KwgyRh8qBjHLIWQlSScPz5QUTRQkqKq2SMCMkSoAVJBgyFYSSF4S kAkRcCyjFWAZ4Q556X87uyBtBSSZzYAVKCJGQqQLFSTgSVCCAyEUkFJFIpJEQAFggxZIgggy bZA5BnvfD7NBphFkUifieww6M0gZ/H34ukJrzPAbDZmx0aMIUKGUpkxId/uX6DW2HJqCI8Nj BTpW0rswIP1QT0+nGwxTUr4VUbhsPD7rskGdYJREaUPWnlgLA0/FZ7MgaDPPhcEsBrT+DnmY GpEBIiwOeOid2ybmZ/c/8d/3bvzmfnozfogSQnMVHuD4MuhnzsK3nlkfEHIjGEisIBsPzxAv nObzrHPnn+fLbP4+v69g/z22X64d76qM19ZUoqyIUzUTIYx2fwguraTEWMwUn/p30IFBwsry RexEQN4REEkB9SB3D/rj+YwIwZvFNxQBwTE1JF6fzbd85cqM/YwcJ88oCEoc70dR/aNNgi0+ vLNuu7/3d/36ZN/8/xpFnh/6fPe8hp7fo5xXCj44ynLW/+787v6PS5dI4dVvCWoQWBS+BZe7 /SxgZh7xAS96Ui8KJu6IggpLwfRx6z5vodH3ceQPYb320dX8+y43qhQVD5HwbnXDecRVk8eT vPz83eyTl3de2+6k7OykHpwPnF3+ldEpps1D0Ee8KJJBJroNBMwoRRqtAkEvFw8kebIoYEjY YZJTgHXfZapEiC7BZBhJJGQRUk5CE3iIcQgGJT5+CEDjIdjiXDvC8if2TtLAyQ69OuhB6No2 FTfDxo7Nxpy/1G6jXPeljXurc2bSrdmKeHUEExRsd8ySTJmIBsdxNjXbUkL4/d9n06+qZNQv phOffV3Fc4qy6tuUl36i3iXE0ZlN2ZzJxxVrjVxAKpZLExSsLt7NzENbfYvLVqiwtRYzJDTm ZMedOBroEyXk4m4ZabxTegmsulFQAhdzOS841M6hiCrs71KvBlplfEbH6T3enr4qO3n/5P2C IfUjBR4FUiJp/9RfAi9HuGp8klE2ysySjFh9uQgTM+xKJB/x4XLaUo8tBRy4mP2z4RU+N+2E nd+Du8Pye7Z+uWEqpJ2Pk7nu7cR7Ir0hBgJIwJFhA/D38mz6NuR9i53MM3gfDux1M0peRrJs x/psijDNPdu8uGy48PYa0v+f8nJUSWzefJt+rq/oas/NRAe+1xWr5frkM1hFhAr39jOguP/M enkE/bx2MB4+7u41n5KwuIA3LEf7Ebe9yuLjBkIQksxsEyzgsI99v/21fpvxRZbsRVkSTUhy y83W4T+5G1aJUpdXFk8vn4OznZ8PQ7pN37HVQlqOqLJM7M1dXVvhBIjW8yvUxzFMoW3jVU+4 w0pjaLlsgiCFoWZN9OAKgPEsCSIendlouRPxFThlolne1wrTMAu3rx1blnSlMU5T5vVIfHaH 8E+SPprRp94lx+9PplN6GKFLVdz9l5hAZt3X1D8vNNH3EZ9+v7suP0aX+r+Zv3Mjg403sKce 5HLIvsIm2Zi13PhR87wcLGQBYdZZ8/6vzXbjDK5lZi8WnkWB7I1vTXuE+BfHw6l4znXXvrth D5tsklhIoBILZSrWq+4ejMXStVG3p8QeLWtqqq9aVXOyZjWqNV451koeGzwkidCeEEHBEHI5 ii8wmvBTYZkCF3GUwqt/ru5kgZyW/fDW0YC6C0E0+B8Pg5YKfyFnYkunkJzZTZOXOHM+GD/N a7XPMhE3fSo5JDIQIBnRhOsuxGBhWgISENiG3b6sdKAe5OzLF8My/YlRVCTBOdSDdwKcb8Xv wzxCRqc+2tJCJnRz5VnxdqIhiBDUz3QQvmdnx2eNcZS9MpSlfLFwtnP1UqJpu9nS7y6Dv7nf j2gTO8y76fQd9PIkGI+1FIHf3PId5d3eHcdaS0qrqpRAelIyEXxmZmenlE7vagNjWGT8WiQR gsFFg5qAlukbwSGG0LP4TLKgYExXxh5ckbsTltYFHnntzOJ5+pRYfzYKmZ6s+H3vId5wXfpv QHjEeuIzmZ1z2ISO17jd0BkAkUkCRHXXz1u9l7zc7imyLgZe4hPJ9/EKm+/fvu7+bu79zuOe eB8qi787sQGgcftoHqgHdBSokgEgRQYCO8oEcYoMRHPx2w8U55+nTz+TS2H37TpsVc99q+Tq a7zFFqXflOim68KDMDX7GvauaHsowwGnUcsqVLXs/BxOpQgbVQQI3Zd9ZAevQ5DMlj8DvKAj fFQWCGYt9atgg4zomtWSAsuye71G+Bov/Y2LFUWdGEdFluvjrht6PAsGmmZlt0L8sjYud51C 3MhsmNTBRnB5okbhePRia9qxSUfRI2NjMB2NMgmRKbd0TgTUbFk7GiFXTfW5vj2t+5uAebnO c5u4MiLUyDhhabq2mFbhiojdeOin5NYhJyWG6IJ6EPumU4PPOxui+NCZALd1y94BPblVsVhg +19xGd5nhu5eW+zTgm6DIpIqa9WPOXNnE431Xfgi35xK9quw5PkVGP+Eexayjbd1hlljMOO5 W57mztY9tjtYVR/Wfv6KNqKFPPhxuJk6ogjfKJIIHJq01H7667H0h8WsV6cTo9JDM6QIEQ7o XcjpNp03h1uOka9a8/RhfHbi8K6K7Eg1nRhrp7b6zFhEzCfd95Igu5WahsQpkSPQwd9Hgo4M IEaQ21DSCjICizTDeFhbrcDUNFweJFmjXBSEIDhIZCY0M29Fsl9bE9hx5MPmfLX9bzm/reXw 1A7vydsGpaLrfqX0ys1FYMtptNkXl0kKtcvo0pJmvE3KHusbMRpBCFACQnrm/Uq1jV59/Wqf be5KbhugdfXCfKID5RjI30KQcS3AvY1QC7sG+uPevgQlaYMu8lPDbIkVuXba0Y0u9KbejKlU Yaf+Ixz1EpQ6HuF5CvrMN17ny69MqmIlW25nXpmXUvnYdAhSujaE3EwdqYwWDsqbMoU00TgJ yHN9Cmsplmh7Y/AlFcca5L4VxnI1X87v6pnVpOkrToewNzHWnBJoVHwxziVdxHaRa0N5Oqlx mwzTMFc79mNNoNmzZZPuRiqC83v+EMzaGOxZiJXAMJuG1NprJeJlH32UGJFo6pAw7ykL9HGG Pnz4r0Pwn6vyZb4w4AA0U4HsRO6inpqzwPfO2ves6MzsWWHPoBtiIMwN3I28Jo0VXAYCwsML IWDFQSbsDEuWUQ2MhcwwK4yNmkMkZVSaELS4GIBjCYSBI0hD3Z7N0Iee3WW+qb7H5F0Zt6Wj fmXTIHDsbCLsRFW36ss8TKmGdtr1cpKh6C20aaW1LfBnAO2eXlnfQObl91C8AdhQfqvy2AEF ta+t/gGwwba+R+K7Lv4ioQp4+ShHLibT0bblw48775yrKllhfmXBdJ9KbOI+e66Cxc7BxjHV 3Uk2Ahm6F4ec788y6ox9pjpNpnnqT1apIMzyUE7CtpdRJHs1qRh0xZ7C9oxgHQhCD1RIsILB RvOj7/IQ6p1EAh/L5Ne/u+9TXHiYurA650KSNh+VuK3WKrKdzFkweQu1khJgQlOEDjKhURZB zptDquBU467XrgtQCgdCYsmxNEAVQSQQIuX++/+GDEmKMaINEJCwRggeJK+TwPH7T7ZwoIjF gh+7jRbkIcuzAhiB3DD8KKQKgSA1GRKsSFKFZSpGCkUZIERVoiMbSMRpGSBKIi1ESLIfV+5P zHyBqKEQSHIgu3xMlGYLAVSMT/Z58Vcd2goVJYjED+s7/c8ovgAccHs7qEL6unP2KXWOr8bN nUZuc2bq7cH5Jbdl0Wb/tm08EY5muXldT1XWFnSraEI716vU7rhyeEuFfKV11kNi9nw53zvr TE/GEiiISaSChG92SVO9bYnJUoo9ytNEfQUynhymUgQBFiBCS4wj4mXg1KsR9xr08lGJfG7M uLBLfSo6EZ0nDkbYu6jnfdPd3rr4awgO1ZsxxR+wGEzQfrR8OlCQJMkyZIoKLCRZRJCiQEDQ dup5+PTvt+k9XDfU3lidXPCMGS8zjpbaUlTxGfuTR0vKU4MvRqbn41XonCnggcV5tyWr6jKh NBU8MVs4t/ab0ow2eip2UnRXbc9ju3jF5DoTb05iaF508JscAxyX4y7RXze7dkQPsc8UF6IL ykEIzUhedF7bOuki9TWIr7S6BwqIRu6JFixXQmxFhaz5Ue7zOHB//P+thPMdWDcCJfvWZ0yx 7TXxqE79IGHN0pNuyNyJeSOFjTs/mjo44Vgnl/Cew/eWooq5/yIZvXTRshphdsDJ0EEMxpCL 463iESeS16nD1+fBNp3d5T1dL/iiXKzrjNf0KBHX42dUtUS/tW86hS5p19nmg4qV78tc5zn0 OkYIazP5fivu0/1p8OhXz7BnHEa4x+jhesT1WEb7K8pa4uFkPhVy/TeIA+db3cDWFY8PByyh 1BQIUBKFCU7M2qVITwQd5p/vqnbv8oSwCCU9c57I8JWJCxwbmUraUm9lq/Z7QKXY2eU4sw8+ 3/gYldd338+7LM/Hx+qXHz8xvwy+3temrsrkSRIyjf9Qdk+JMxIHeHSjZWJzfcNTlLsnDZPd 0/TZZ1Z9T+GPd5g3sX3XQOauzqUdL5bfV+EUp5HVvykPWhdspaJu6zyjTLs12bhhj2LjkoxG tn7UBuRujRAdPRwsyIdBOzHHtwcEP1beovx4Jqg6MCTJvyddI70NgL/ZA1VzW9T65WHs6J+3 dbWX9250jVi3pyjdMeAomSotXZmq24vcuRZpndDSv61k0jR37kFavWTl1Xa2HQ3abY7JOHMz hx8msuEx43lYHLdrvobkMW6QR4FLIuvW2H0x13dSJXrpdtSec+F0V1Ek4rvwGfoOj+MqWWVZ jpuXLvzzgRECOO8e/6YL7DhA16wkRT2LhY80jZ5Qq4Ndk62ZjAGy3o3mW3ffo3K6vbNooj8Y 49Prn8nXu8A7ZM3oGSYQgQv0JmhX7VQqREEQiqLIsgSIwFWKCkIIiybtJ6kKwFjEUimmsigL AgoxE1aO6WfRe2UITsw4kEjzoa30H+GKtxUE/onwhnDHfJT7I7oiGUAtBDSI9cOEA8cEe74U G4gyQFB/NGHmGE9DGJBZFCHwoQ39qNEaWwtFhUZaUbQAD8SEJ/EhCZwBEyYokGJhE/Ig2iGk AC8AkAQ4ConvRaKRddhXrsi9TupFxx+zjsiI5hDAVRkBU6O7k6echDwdVFq9lmvrP8t5MYK/ QdZum+iOw3j74cy7iDqfdLaEEGpgn5JR8hJ8pJM+9PaxPK60o6dp4bhhh/4yjgfCZ43lcZaN b0fq+blQrQdnQ4ZiHTrXhEfW+GDyo/1NrZgPpKDXoNq1clumODfWmSZpfQ+HLP14hCnmuaHw bAxZfb2m7HVoa8tmmM5XaQmZtwoOqg3oCOiZaRQcKDbrALUGNzHK7b122mNkubDWnruHXRRG 96rc3U6RhOMZfOjbZKt+4zYRQiZo1Tqfjlxz04tjuswMDXpXK1K3UVd6W55yJ1dryo2EPPPX 88Tx8DXu4YcdmhmpLMvkWmwg7b6DqxF88aZfDVPpVa1aunH825ZUlncOi0yNDkamrhXXda3V zRyMeX28O5cYeX0ywUx8ElY/FLAy4Yn42Y4tE291CzTtNEut24m7vAssbzMCvFOq4t263i5Y qMdYg5LYs5itOG8d4aMqpouYdwtXFQ1SolxTStKVK3lOYlwXerdzVAlsMmTUurpLysq0PU4t SyipVzWU0LNwYEMrSWexIeqVyLDLgMRZzFgjJdnFTSm1mbqQssFGGHxSGdbUHDFzlBRAZntc dnosMp6E1KzLmRbXDAmQ9rTGHL59uBo0utOaq3rF0mOsqJubvMWYgSsHJ2Vto8wrFJ9XHV3H e3FpNvbj97c29PS0i/gx22Wsi5g5jFikU+uEhAPuxf1xRSEQ4cJILdEBaRfmUFCvvMCguTxN N/A5kDrMCH0CWdlr8CBIxIRM/Q9+Mxnwp35XlqbAdBMzOM16txuP0METlvSoj5CHfRYCw2t2 Ga+AYSYFhXU7l9vjL03fd6dnO6/jbJU+OUsbn01ZnFpxTB5NmrQz5dZhj8UCyB5lRO40MV7z DXtrpu1KvReXpVgclyGlVlVeWCqoaoZjVuzEK9ss21g3D0FdLIZrZblrBuHoK499VGCFycXV xhEjrpTsqrepjYjWr2kaI1q5fRMKzqF7Os7t3XWmdPi2aOp3NRa0alGp3p143kYmcaI463wa HqNcTxIApwgj9RQQ9dM/x/C/QUTWSAnNHk7LWoo1akj1squBqWJRsIE0LOKfZu7OG5wyzDSs W22liWrURtYrn78/ezg0cdJrE1VL+RKbp14zrrfcUq9EL3MqIP9FIBZl4cOtP3pk7FoHDxv0 EIqxhD3v1UyH0xKIB7yNsEW/YgU36fg+APiPoQFkFRjEGSgB9YEPo2otN+7ztvIRF/gGdTH4 a7qukO8UfXW7k+Cl8W+9MWpaSjSk1CtZE1575LfGqo16o0vYUX5VFNe33t2G/nwz+ycileh0 iHS1ysuDmK70MFOMzjezCigSIndP9f6J03x0ZIaMNkKLu6AAMiIjXctBJFGC4SQ76svMC0p3 w2jK0u21iQzwtBwF323t4Q0bO2RreKI0VKYc603MtyduKHewUiKDIKBBRUHimP8Xihbn5rKT Zx4gZh4RigSwaxmls3TKiDKj+vysh3O8Q5LKMvh269tB78YfDQjVThSyblZmiROpz06I446b hxvhmc713vK7oAxjEIQAAhCAAAAEIQxjGMYhCGMYHcb6lSSLPafsc4JV8OM8HTuOnbJJczup Cc6Kds3hSh4QjE5ebz0yLRmW27dkzNfgixOkyEIENLRHy9ZNiHHPOj6enTwpsyiLWrBFNY7d QAZwbOHLjqzpuSQlSpgGILkKxCjh9WKDAm3Vj1FgAbV4iZNqoIJCqFy66DEG52zw1p1AUm0T gUDtBg2pZStMtCmjfmR1j2S5wq6YOgTcbIfQO02thmxWDLgfogElURGmSOhOIZMCI6W1dFmk 5Q5iVRhIABEsXNWWPfRazcgHCRQIE71f1W/OnoZPf7dfTedpdl4WS7s7h4lQrqIXpzN25eve UAADB6T1S2WWvDEReTlbQqEnHl5N68+OUyKpqqKmQr0TuVJAkcdlq+CpYjNLIg7rRqFBoa6D Y1hyrQ4qhSqkrIrQV5FToekDGkrhXTseyh2uCVLKC+6UI12iqW1Ykbiy/dUjLUm1KqOlfT0H 7dld8o9HaZ97ikSEVcIaotpIZl2T6t9SX1dG9ezu0vt4WlTUOIUTuwVTch3LyLZbmCJTM8Eb a2M77rIi6e02iEpv1/wL2BryV9cL3kpI73eK96TAMwf8vrcY2ZGypZe6E7v0HUZ+QcK7iyx9 cy+ggyo6oEQo3kpHcrEEVb46QUx2YdNeJfwhRzMyEglqvwkSL05ejKlpbIoSCjMkMwqj9qOP VrMOE1URqmkCopmRQLWqibt3DPLhM5tDup7wsQ5benBjaa2Cg5lYJaAqoe+et1hluwhfg8ev IrAvQYWXFrw08BbPV6Zoe2yqmxYarLTMA8K4kkZEFuGVrhqchVysyBOAdUQKOYHVgApCEQoU 8Onam0Z42znVRUzcvYhosMsbdRx02I9A2e+F3PVRXBJcLDuWpYmoSYJPKtRVjToMiC0wSbDU CWWGDgTGRNUn76Dt4IxQjaSFBIIB3UBEUh04l46s9K+zq/bkmG4dgTdLeA5Vl+G9Cjo6RjhX 5qYdvxh8uNF5rP1zwXX/Ib7DpxLrbLnLB9LqGvF60nRQQzZMbHSQ+oGhAGxClEQIHU+P92++ uF32xRsXlXlu+aaqFrQtL9Bci3u86MRCt0DuztUVdRmsanWhbKGwRqlvBVWZlZh8eHK097ST qI/MCqw6BI6hAxAUhwCgQAsqB05vkaXmrhsKqGYDmpgQ22CWoQ0LKijFTEp6jduN9Do82Fg7 NsvTOI01HNcWsHtFxDcOxednyYlkhpcy8zkhXNlUx2DyoHTWiVxBLkiyI5RcRTFYo93Dj1am yaZcL3XtubdW4oiS2PLlmeFcmxODrOJ0m3alaFB6qsy27LtWqqd9uo+O9XsoXd2302nMidlX QWSPf+wn1fZJ+2yLzmZJASQZ9/ZexDTcPeZv2Juo3kazHpHt7sxLIKaXaLRWmNmVYrQvafz6 1OdP+A9lX3/Rjy/PbH8siUKGNy5F+aAW71Wr6Sw+WCXh1CALhQiEDGir0u1ya/xTt92xwvj5 pywb3wQWycaup7V1oD6Uwy97usVbvti/cnE713u1d29m04GENRjUwKqn/k8LHbvg/qF+tWzc 0f9EUTEatuezwm9lf68p5qTFwmbCQ6Ez5wf077C69PjSWBzB795hSEG5RIzzv8DP6/vTv3bb 66K3ksMeFHfvLVUaFhe4gWKicDg+8Vds6R93bmwfSz+MTo7jH7fXj8aHxPmQUnw9W3ChVDGZ PTZXNJqKzrL5ShWw0l1pic9ijhHQ8F7vs5PcmZ0Xonm9xzxg3yz51U71iijNBvTpCTuaob9a GsoZRCoIkZIY7EY9ycaiFtpFqlGVbtZuHjff6feydkUUVZywrWAVUrK1SdJCTF/wylNkWFKW 420cv2/tuLre9Rb9+Bzk3KAxwkpGVsTVKZVlQnvVBByReiqbzLBW6+5X478B9+a7999yDdrc 0plF7yT3KWKlGW6VeGyKFo9uHbM1JmEmSEkmzW+wYbXJT6tJDMToCg57r8b4v08fNfdUpoVM hhozyzqgUC1oCE0FwzDoED1oDzacRLYmJxWqqDjFWCbEBRgcHYNvOmPCq3z09WufDoiD7dmy zIi+BOMArh9NVVovQ3UTvLhiuoGz1A1ZyXXuzjDSUdWuzplcixI0RYjollCr7eWsEhLW05XL kBJ7R9RuOp5qoUMviwWNMEQ6tvAGhmbAOy6ewGRhpZXhFsL/isJvsWmx5Vcvir+fXI7Ox4WW lOq/R8LMCMKFsbpc69lpGL/HG0u1YIoRy8yjWLzVelXzRouSrs5Ul1qLuSnKyCC7Jbolz3X4 X2VyJeFwXYlE638jXd7vP69K2U39urq9/Dly1brFd5+Hs+dv80d6A3wU/Q3oQ5IgloH9VNAE D+0KairmVSJiSDIf6Tp7N/WWQud116fwzO42I/0ou9US/Jw7+qukM1+2fmzsIAZ5aIsx/uIF 7f3iIjZER4kRH5fqfsEQfQeQ/wT+uiO/X/pj+JGfsId6yT+QQP5R/kv7qYwwrtzPRoKFeZJD +eEKMGn+mhoatZsr/Sfw5j/1mCOBkZNOdDQ1djauprqa7Q03baNkHEAoxSQkKLsb3oURWUIS Eg2NIhiBcOx/REZB/5919A/Wh0Bgtujq4PQ/zzKA5+AE/sMw/aarXVFsjpl4Q7kOz4iWCWIE gaUm5/UGNgxTDCGMWoyD+XyfZbpzfoS19PlplUUUb9vsD5f+szIhz/l+4f5AoNsIHD+rL2J3 zBDYR2g7+T7yq37AzEHcN222H+AO1dTfnwEK1feMRX46zQsW18juzx2dIQDZyP3cS8iwiPUb CJJheXXPI0RZR2zYYuiI5xYQRBi2HgD52KIxysh6dkhSGijoGXFemlN4H7kQ9KLc2LnbE+0y kYQ169YQzBRmPLzdELx2hJBhASQSa24zb+zhJggbybwbnMP5il/aIkd49qrfdYqpRKxq79JW MV9eYbtWhD0DtTcpEP2URgnvDQ1lD3guN2I5wIHvoNm/tKdRvNnhRDsoQ3WvsLifs9ZDYZ9F H02T4Dd/cvMHnLrwb4jDDdD1pAU8HZBr7m0JCuUNAZ44tGGeyDIvYYduy8G2DZDMbjbemSSO TfY7rMTD8UjyKYTbX0/ouJMKwwLE1S8Zm+7bD4nepErfJC3QF9hb6DbcU46OXJ0SKi1PoPQW FC2BzcVwDitcIFOp9W0RB70FMQ6Bz9rcEMQ3u3bh84aFJuDAgJAkhCvGTDX4lhjipJf6hQDE uH1xiKEYGvS7WrDHYNnAwwNITepryeveLxL2c5Ehh+6UvJP6h0OFzFAe4XNtwznD3MeAGLGy bdPSdXo5gRHcBADa6TfYigWDARfto4gZFNE42gNADYfm/APm47WkLvNE0TD0NQi8xIQbH8ye Jq6XWBUCawyE9WCh5g+nHk5Hh1YKvRN0jPEl0FDn0CiERBwDAEZ9PvcgaQWDIgwBJFAYgodb CgiKS02T5KHITeHvsvxkHbhJfLOh91Mj6zxavd5cDceTwZkk+bw+c9o69OYPXT5nzedhHlRO ccW7tfHvOYA3r06b/X0M2DHW2r4D4Mww09uC7TZr50x2Z92NuQecwTWrRu4RT1+nit1lzD7k Xz90nl7dr/+p9jCcSYBD07DAf76KZch3c0h/XQKDXIUrXAKKCAoMJD7Oo7/Q8hEcye4/fDAY JlJCEhDKigzNAPaCg9rjqAmo9T9+OK74ncFGTfv+EFEEVGRkQSMRiCRRkZBWRYrFRRFVjGMV IkSJFViRkjJERURXiTxsO5IQHWuNePOls+gNgO43LxNKWFRmVP9348wTo9zr/e5cT5wLng8Z qiQnVSe63yNB4uQPnDfRXGdTzHTWBxf9KNtUR9z0RRM3rLNj5DH0fsxf1BOlHbEyYF/Ocgs6 +T/t8Tzc+r5KunTuk7G83G2AfRhHERB6HExvzuCpY+UPz8Dfc1Ki5uytuGgcolJvOAUbtym3 Re5R48B3mHaD8NUyTAIQKT6KzJgPLxI+OY3IJDoROryfYFMhIEIMDZy85/DWTPLJMn6pc6NY fJu4V6KQyhjdFEcAUecLaz6JI4HTmPUeBeQzYanV8Gaagy0AmNb4PXxKHe41dIN4wn5xIfmy 0HQz4GYTiHos55N6THf0PqZuAc9TFo0z7vkx/n0g7fcduJt7725fb8vNONIOB52cR4ETxh5X twMWEIR+1ophCDERERH5KURtKMRP+NsRiI5S+3SiIiIiIny0+h96QhE0IiIiIiIjPRSjhSwo Hud+GhEREREoFKJ1pRERtLaFLSiIiIiZcw8+FERE0bc4+AntIY2ZgfMHY88kkIcsogGDkExD 52hH5PeNc3N5mci/Yi39Zib921EKuD9oY2t6nb92AaaKeEg0iWB5oAaaIVFNi0ochjc1FkPN XL5aQlFYnpoPJHnMmfRChgVy3/K7gBaAflPyxxsYGNOVDQVkYyMhyV00ssyBQe05nSzlOPqD yH7JfNSafSecHlhjMd12TwoCAtuYHIRKbLDCgTA0A9nn4/OB4mOf5JIFZIKSAzIxaIMovxov jskw9BIXPHjnxAQzNQmjqyoLkr279vdgj6w5e85A9OPoDoB3mZgSxLHw3qerLodqG8j1bPHA +fGbXhlqkBZg/NmbkekDqkYbGZmNNWpj2FXQoEIDATv7Gtl3ESIdW81kDsyLm3p1rZbZWRTm QNQGIRECMEIhFG4REaBIIjmZm49B7aJ6a6/S0fnKDAy93kQNTFZBJCxyGcy08F6bWvYui0ym KleUEaBSikSiJIjUEohG/nNE/NUCWLt9OTDpITu4t+LXtKgfEDEy08mHLfea7i6qqKukuyoV XWnTfT1nYEHSoWG8+hfafwPrtB9jCGRGvb6bj5KIGmaYUb2amMsuWwDHqfEhqU7IA56gUdXb xOg1+fW7MSGMYEgSQVCoEdHQe8iX/Yc54esKPRaThoHN2vD6rFQPCeyHy2AzzjlGjrCjFNz4 7FfvjiiHrSBD5nb7A6QfUWa4J60YecBHu8RY8XYdoZMVVrGtx2LduB3OG0q3RxSCdgwZoYLc dxCSSFPp8rOu7ogYfF2YOkxLzdrdmO48QPW0jcUIjttKD+eJzTwOB2u85uyY6/042AHgE3+F hdlgUbzMZkbmPiPwDVtgGTdmrNC1k2JwD8cRzr4bPmmz5mGT5/qU9fywRfGEmoiogm2+7nl+ VTf+P3yv91mEIZOpaGd4Jned3jTYzgH08XN3Ig9sEQePVYNkA8j5PtDz7H428Nqur/j8+hfp EUbA6XB2GF1C7nlDrWweb7T+9fetFx9qj9J+su1/ojnEJMjOpG9umvzyH1Hw8kQdMD2cYQIQ IBxIH4Z5L7VYJhDOCDRkwWlyGGBnGY0fox/u1dke7WJoRZTrUK16+tSsi5D+ev1N1zve+SFy HJEd5Ai8cUIQIjSU3AoEHpAEfp0yGR7Y2JdTFARtjTnqPg5Dh6p/fOQR84TghAlA0C0vbqXU SaSb2x8+NUY/PsHmGomadSiO0s3jrv4megSYfK8xiKMYNp4zXKGHVIQGMPudKaGRjlekkgQ4 HGpxCnSaOQbMjNELNUP6SzQmSFONrkGOMIzIJDSGD7EAdjITCTRTGIJ7SI+Y9spcvfRlBkUs xj76A9RmUDhDaWmluE9saI+z2lNxThNNh+/ifZxDEaIO1f4pQqIdf9AbrK5aGrQuDgmNKm4s zKGwrjQCazdxKMEArqoCMU1YGDEVw+/cFlSEXaJF3jHQiUR64WgnJ+YHA0+Ad8gCwulDSUZZ 5vNDbBdkUOkQ56FHOHKCgUREOo/IHSLIskJEkxhnjuJ+I1hlaK/ntguJwb0bOrsyQmpU8wyF 0zSeEdYWUlB02vgoSQHGIu5WHlIST8isFgIgorBSSMREVgAjICkEVEQWKyRkmjp633kUYMj1 BoM/WdeIsUI9QKBLQX2vUY5qnrJklxkTOG68cTB2VJgDbk74paPVwRizldB1uNJWZQ2VtX8K qwH4KJ4Qkf8yfbqHHBQWB+xMTSQ/KgbSDBU1aEtqCn58wnCXVkQEGBlkMTFdsS5izhN7KIfa y2i274wBBknRgoNsFJfEUOE0MYk0kWAoIgLI7shcLCpFkowqSevCgMg6sLDTiTodeRKWZbLb RVEiwsyhZnX/rrJr9t40UrOcKGIG9lAhohNBYGgm9YawaopBZvdMFGG0rFJWVKyF5yGGRFWl 5yx3Sia5JhJpEdYuwIx1ysTExAa3UX1YtZBjFyjYwknQQ0kdmhkyMQ6JKDqJwYXolEMEOtsY w3qFhUigxYIDYUDT0ZOrBEAUESAsixQu6BB4g9vghRIUkYfPRTzw6nhQBy83k8M1mgrifE8X momSgyWUhttUGE7JkfzP7WAQJuJn8KvE4fL6TQhzt+MvDhS8bzecJDGHmmuU1GFh2T7hMCaZ BWhHUByZGAjDR+sYnwzie3fgz+zIm1wHGfM4xKMA9vzKAn4VIKigwYKCjCMUgw6nkNhPq5h5 dm7eN0q9CZfFyIBMytMrnX1JWP1Qz4TZmazonNVKDARiLIKQEf+LCxOHQBhY/dThb4hb+Ynf OsOtBX3QDpCw6MjDHpl9vN1DN3nCyiQiEICMCPnctBfljoVu/Fce4XeGKFTUG3o7oQyTt4A4 5dXdnlzMLIdZq5k5faNi0ACW83W0LQuYuBA2Y45KeRtB021DU5GlUU9UV70+awkGRIwJA1s3 cT175cLfWZSaHYMFQukxuGTDA1bqNu/k80Q5r05D2APXEQov8iU0fLzlhig2qVQR9mSlyWYV HuHbDL0yrih+UNAsR+Slku4Y69gV2U+7us7Oc/kTibsOJDFNIVecgs1tGuMPu+JQmH8KDicV No/iHyPzK6wXy1oekiTcalGWSdDj30Zi/XszLKzvG8pPyxV6SSZjINbmdpWp4jAwANWpoxP1 Cptgqd0Goola0PkIE0kgLA8QksrKk85d7FIb3g5VZvgZlZ4JEVkHET1OqpShgAhCMzHp6UWr NzVnVtRSiWgNyS9HDDEfXo+TV0nUcrYhbSUERAilNLzmGQJC6Ipizx6LoVvvTKW2222yWowL kauOYJCQO2n4ljBObkwFvZbxxCuyYnPUCW9BJUCm1rebrXJanZhp8uzCGxkJVbuAZnDq1hbx D/DK4uw2nxCHEzsgcDbUZGIF5IBAgWntxvQcbyGyHY43LQGQQcOUyndCThoTEdPMewhjZwTh WUCEsiFOwyOHMSuh/ittMPmsgkh+CWGwl+nJDShlDZvMdGH2Ve5DEhYbDoIiFjeSkeJ5HK9z CoieLvZ4b9GrPIJSbGAUUVkUSylBZlkxZBBgYwpACyywrqMoioRCQU7kKHdlqvr8eCDa8ePg Xzonf1/WeQe4yxLvUvq4Xn8MhoR/JDc5zm6FKkSUpJ5v/FQjXbB+7qdDQh3Q9u4DCjaUE6WE lGB5iNOOEgU89zWQsgb1wDxUqXWqlo1c0mwn3kPgbQqSQp3RD1Rai/I9hbkH6+ALXGvPKi5C /poBuR1fEDE9EO473cjrARfUREALJmOh5MRAu4EvSZWAz1yg2HsRe/rHt6cMOzCVUICd3t3h 1IG8pADg0GWUakahECBMPRtjWpl4u27MqE1LNaRDbIaQ5s4PPoCc3VxmZq6o4lIrJDZZVK1G aTSTHSUQIjFAmrQK7ZMBmD96MxjHTAT5sMSRebREjBeLiYwbAva9XXIF44LMO1gbOxqcjqYO PFdKTMdkGvqORZfZr9W4yd8hmJ475FgPcG50D0BRIiCqLEgk8PQQGCEAXEqDIgpqmfI38mb4 0ECSRRFdndP7CQqSHKWewYo+x+IxW5Qw5e8m9erhcosOMMt7DggNHChFD/Ii5NnfmyB3oGUb m/NHEJq4ytmbn/jv/0t5IOREO3mTOCHHeSSG6JwBDSLrhmVOZfuMaGp0rKFj+EPfH7uwgj5r e2smh9575A14N6cG1GulE+rPJN3Xfwp8rlYuXIRJCEOobGm0uCEsZE6Xh6bJo2Uk7CRN2gom HSkhtkcOEw8RDlWKFtFOvx9r3lw6DqbnGZuPyt9jOBo2eCHKaB+M2QsKLAGdJ0kJosGUCuAo o3zLXijc6uGeF2xEunHznYFODIgUw13rhTsUHbQVd7adBcWWgo1Kjx27PKGultCNjQN17FI8 Pn3F6PXiuI42gOhptpvee8cmUDCMIkdLqtqCdXdF27GByguAs792rdR1WQUOTLsQr5LOFfTh XiKRgIBA5Qzjs6ulMjgAFAORuGO1E+nYQW3nts0OsOqxEB0cIiMCx6sKtMbnsM4cCgeuoQoO vLMAVB4JqQgoTXWNyIQ6ldC40qsdyqSSEQKeTOouoRAEoaoK7d9C4CoSSN+GsF/IoPiSErpz 07tup69WTYs6uXLOrlHd2cppy0xldFsx01VU6W713muHrNwkexuQYukRAFFWJfmgFqGSAQCQ iM+7qgshyrLg3aidW8ma201xrjRTElcVKlzGlaJNwokUqu6iGAZU1pRkhZFvj5tTVsBYA7wF 4BAzDWb8BtN64dDJczQhMCUW1TBkkcnIMATQNwZiZhkkzetdyYCwxziGgH4G0eLUEg542i2O J16q0dWWC7QrJMmE208DxwN+MRWKiB+Mp3rIZZDqdfL+ikhINM6GRZjaFwwE5yGX+YXXN6JB gHpDGE3Ft43pdFxeBreaS1u7SAh6lS/k4iIARSFRBhARhA5TntRPC5nGatCazMhpDTiVnYOt 3YP0G/BkQV694Sl7zjtn6Q4jkEAAIBBEIQi9ICVExBVDnwTxDft9SZyczs1haKya8fT26JyG pB/QCSRiRfFACoIgkQSMWAyJODgT6LS/OfgtTQH0RBLoDUujHEDo8RmNmwZqhxoFXAVvedIS EhIi8XMO/TviKGHg/NnIyNAdXCTr31ujRVGaJ35Ogr3DnSKwbV9oMecYjYwgw2iHEDw6ybyO 8c4AhkkmYYDuEAMOGT6Y+fWjco0NDUpDIYIgmEpEywTCeamoSfbAeGdANTIDjWDGdqKXDKNE Lempyhd0gQNLUM1VW1xYe72s1kAgBsMzMkNauFWGJpwy1W3GVMQ6wwLI7KbZTHwzfo0Uq4Af Cu3vLxgIqinfq7HEPBPN4b15WxYiq+HkuVLAyD4k6uHpEgJBAjCBFgSEU6rK9U4pv03mVhzY eUaIcqK7iOQ4xJfPs2LBu23cKSKK2IN7TryIMRl651cLTY5vqHe77TuJEzoKhD5AiXwfdfJP dOnkycZb7VgQ1qozLhtmfpEREVFRRUYCiookUhP0tUVFVUBVB4JaIqE6JKqojDoe56g/cwIP fjt6c+BuFDLeMoAejACQXBteYJ17Xt7Gbu7kbUIZlotivY7ggJCAQJHSJggOKdhtqlPnqvfY 4sKkMMm5DQgfH8yO/puONStrVa1FUtoqqKqKirMpVUUFPntltFG0n15RRSKKxTdLpW5aqKqF QGXLafXbqlbmYuKFZrjI60KMclKKumFUiJXWVPIQCQQZEiSOylK7SRzBO0wFctwxNRKKyESi hEIGAyNQoNsavger0ntB9wEikAUkge2FDISZIElBEBj7EJCJChaRtz9dC0kDfBPa9GeGDkFA XAIGxNEhnZUXAEfxIJgB7Gi6LgGn7Yitz/A/WGDCY9P0yaH3baShI3CDdnCbcFwLSB9/TgaB MkH4Q4oacCthJ2E0mHlAJUkjKK+dHFzMBn/K4Vb5EeE5kObbAfAY5ZAXVEhptr3H4dlwHqzl dL3cidxc2jPnLSpdoNiYUfMFg1PsYKCgoIlDEJAoMCQkOjIqNxRMEUR3diEdSzKjVL1tstUG Dfee8UcgQaSZ4JAi8oVpTJmP20c0vUkiUgV7CWdC8kWAQwKWCMEirEuDAFgwihBqUVgwZUY1 DTlJC8E8A3iqFmoOdjWYGH2aGIO2A7oLqQsTaP7QdIEe+JH1pg2YjYwvf8F2QHWyq1oyxUZt h5Jsnn44Wb8t54DeIkylQQN2fgLLTDd14XLQUAgHzjDQ5T0mIXAxGokJFYQViLIwEiJFD9SV QSIiMiMiAWMeuc0qNXPgix4iMmJl2ywCTEyVbMZiyZ+qyZ6wdqPrBhIeJkJA5zN+NtSBLHFy lrvviGp0o5jaFwkkgkXPAD7/2Tvh0P1HsruOSwu5c1ApOURkH/hbyMGRFZEPP3C7dofSLZt4 PLgApeA9zI8uVdifAPmXzuTu6xPrAqhpGIF4ihYkgj4tWF89cb5BhmqYV2ooVaC8JmWZQsEk ZLmEqQLF3ZKh3nf2h18YGZmGfPomYnfAkReM+MgxEInqfA5098gsiiv2sdi9rxW73JSn/DJY 8qnb9kbC3It03CC7h4Qycv4volh75YZCi1oi+kJOYuhfvmHGtQ6z7TIDM7T9HjXLJYneiicE jw2eEhvnZPc7tY+kSQkSAc0wfNu4y26AGzUADXHSm8/SG2yCOaYlpz8acZhfROcU91rY7MiN CFzeQ0SYAmkEd8cOZoR5EZB+5vRIstF82JY+P1pfd04RLpj1sM1vOwyLxWKsRPkSjZx0AzM0 dTatZNjcxHQedDsdydDia5s3aaSSflYiflYE5OfmzGYhxsvCRYIyRTtGAYmyE2FgYE4sN6A+ Vu9Gy2cboqIP02csNsm0hw8AmJWuHP1JCRYSRQFIAIkAWQIggCkV9r+ZLplT2DIPAgSQnDmq nIfWK5IegzRz/QkQUSLnkdaLBJCQCuyhyPI+auO+hrDrf0cWFnj7Df4vxHJ1hzATgMZGEiQY wq5D6+416IuDgmzN7EObzg0eQVQ0MMWbWJQV+soPqkgNowZF4VT4IFiUpnYHAmz9u340Udhq IcPZ8wnysqwUkgxVCRUIxZERhFpKUOL3M8PbGpYr7gm7pDWQ36FEP6kIaVO5qisBGIzSKFZG 2HKYMEScblhggI0obhkkA9QxA4PQYGwzPkA1KCR+zRmtU6cQoooHVA90FMwMh6aUlKRXWAXG S/GiohdYU7aLObFD4ODMizMJQGaumN6YKBiuWgiSerzWGuKbOlxFqW0tLWDaGmGk8yRtgpIZ 0KQYiwZElGBIBnZYFx13BaF755qvhJCQkJ7tun8oRDZNivMPqMaO8qgkaXmUckOR3lBTypKJ C2UsgIUjQcNRTcnr7+OfY7fedC2olS/y+00k/n3c9ovJ47v0pAgbq5D3Bk7Dw8+Hm5Sgh0A8 Xpg5CmVGSd9ihU8bcSxtKSJGCrAZEQUGVCiqqKsDTYkxnjDAlJFIVsBAdTUosjlEwZVJEIMS AFqWpSHDQfRHgA7SJLg/cHKUdULCdoe9QkFYQYFB7IeYzvVEjYU0U6w5/ReT09iVonhHrk57 6hIYm++XKDudxEO+xrmN+fBtCoz8WYDlGHNiaPbsQbAwqB1nvQeGWMjf6baJJO/xxg+jI6pc V6B7AbMi5lR0IBIIRxjsalGoUZT2jkBJ4gV8HvHvm71obb1IanrQru5lZRDE3qaDSfHDpB0e B1sAoFWieNxBmRbLRVVikjI0RFrRUpWSxKCIIkU0gWbPos2j5P40b+neOxNDcESDuLgaJW66 /jnCw7Y7hdhAK8vCm4nbVERy3vdbRt3TvhTw+LJM0DUo01mgHLqm7hDXzNrK60h7B0bABZF0 wDyYFBgjiYFCK0cVKXiBzrcumahJHQyqjAhLFUwsKGUADFn8ORkYr22dC7t02ibrNsavCzBQ Si8Ml2El0Jc2qJgMTFqDvUGE4YVM1jgGb5ytzHELwQlQQYGYlCOCCHfouHlOcWSBGb5M4BVG Ih7dD87RO9hmzhixHcNA3IDTNx8ZAhQQRpnuJAYN+3ltPUc4JilN9HGNYaQZ1ZDFvAkDE8gk YmqUhr2QN4dggKrJwQkDYuIa3i4CXBWMgfroMTowiZUqbgr+pDAXEu6GTncg60ijnUuAJCol EEsWDO0ZOgcRUQhFIvcPeQpPDsaPTfTP903x2CckSCIgIrJhAxLaQUhQZPUGQbtx2QJAVM89 v3WodJPaf2CyuBULC0ojcM4htCg5xcGXggbk9U7AIpnOAGtHl6F6yTleAoz3VVzJICwCAsFg CiIoaQ4QBYGaIjKMNa+LQSSBt2CqqWGmyZIwDY2mTPV2wJ6wkHGcx+qTWz7nAPXDREmNuy6n GtYQh4nhD1L6iL2R5IGOFPgqgyaov+zDYBclmvR8TG+YZ3bTNQ5h1RGBBkJEjBkSQ97Bo9o8 LXChAkk3xKiQIKBfypLigZwZO8AdUYRHb6D4+E2MUWEknsaL2KQtBbkg3FZBIwJAIgU8w71H 1KQPKQ3hxA+Y8z2qCHQe0DwQsPoYxf5TdyG+VcFLKmKSMUiwgMQ6egN5ilEWIwyzzk9sAOzP OlQ5kyBT0JQdcO38ahVmkCHQbkO2UG7JQyFgAwdXYwItguXKJKe8cc4+U0GdSYqn4xeZNib0 OzrRcHgd6q5fOlF894bgyCJYqgoge6NokCiSMfXZg6dAZxDGYGD7S3XzU4kJA2iHoSyCppk5 fITmwOHnH+T8D994hllWcGLMgMP40PbFPv0NTLfw4WejxfZ8CBUVRXv8w+6vK6KCpI1ETomr fuqGOFZ9qM0R/17tJPgVPez3u6Gz4E+qBWNViKi5v34fKfd/wcqFH3sEZEH0Igj46pkGg6bA Dcc+01O+1wHZAQy8gbyEw19Wxad5npPFx67/mpnbDt6Q28Yq7wQpd2zVhnr+aAjurtdxBuQ4 3QZDfNlokJFcDf3P+KthWbSPk5ncfaDBMDlPJgo4CT3BdjP2e59hk5sMK4z60Tv1e6euk9jx dOlFWy2zVJGBoflOOxYn1bdkTrI6n5kDg6eeMIHVA+5j3mMnA1p9YW6eRN2w1fxxdTvJKO/9 gNySCSAnlzHiDYMzcq4W3MtauBt3s6iuBiVsYOjZGNnu2R0XJL6YJDRd/TKQ2zQJKTEgQIsB eGmDN58qZwN/VN9TRCaw7GJty9d0W0UvaZBIJv6C1lkz6jwOfMauses0DQeCBbFENGCrzOsE oQhz8IS2J0WaIXhCikEGRgHsChYJABGJHi0UQMLLFlI0QRMaJMY7h5WhkJNGWEaPS0wpbAiU qWUCjRGKqiEkEnNMprAwQNs2qH12qqoh5mpA+II1hDlged/hhJ0osVHbBawigeK1SYRU3x0g eZ8jgj1nA9uzXLltWuKL35kC98NpC5zYJg3/slaqvjC60p+efdhzGqQ45Wt3DRzhxBPligZw V3GvGx9fKekoaIjFNQbQIcchTAFAMPwp80h+hCYDgM+MMMwWLEKe9qU1PdGG3Wkt+ksAwy04 sJSYUC144HJXB8MB8h3YFIeuMCAxgLzdaCG4qnDhkYdAdYGHVD+hFj9fmrF758CIe0kF1GFt RWrFtgKCIFaeqBvpF2qHJeJBkVw31ucQCj6sZI5ZN5Y+U/mknQDfJv2DyxmKN2AShABAEkkR kgRBgskkpQRIlrv3osVJHoh4hNYfe8Q5/IWMYdHV7/Wr6N7wgGzq9NydOS9ZkH0tlX9lwhBi B5Q4zSdsS4YkbVBREDzwOk3JIsBmFlEARkiDJUscwRV/QhD4mR8hfugUIpBfJttzqj9tkOwg VB8WPteq5Em3YGqbiVFDNMcxmnL3u/tQchka66uuW+58KXwdc3Lk0WcITCN7mUMw6VEMzdR2 BQPbdXZXJEiWDK7ElCV5T5esfseUy7VrUVkUzFGYimhrewHJPaLJYkmZLZl67sId0NzhYDfY aYYnG7fQ+OXHi7hh0qe4D5tM/PGui5ypjp77v3Ru2+7FcbZzf7BFKwazo6OUm7b1kDYDAqhJ G4I3R0s3vtttC3GyjcpcWaqCGZiTaxN5dZSkTnJ+5Cb3SxKMH7KA8KfJV6ShcIAJ53RHUdB2 aUUknWFukBADmLe7ynFaSKRY7szBuF7GGZDME7pmOW6cYmVJS2ZO8tD+BuEVmV3PKKz7bMMw 92PYJSg3kPRgAHAENeUMOG8+TU33CaALDXeCTe7CQgKCveiKI80Q2RQU3EAV5Tt39ie84d+T D2deZepOSoczV3WeCHRxubuuhYGIuMNeMacsWMQyiuPLaQLtn4ZQqzCfA1LEMhUIwSbOSB2K eUh0kRxQE8PB4D1pdDI76aUG4cEEnIQxHlLlSya/gGaZoiKMSMnhSggwQeILyQYDMEThYThQ 32AhtgA6jxpgGebpM+Js5ovaT6UkEk7aekWRxneCG/s9LkXlySYr7GmKcoNbU6lOrdnib4Xj iHWdATnmvlvqqubDN2EHA1rDFkgTZyRbE1DgG7r9YPHmEAJup2sQgd7E9WHqHDiPkLeJvjMC 01GiILEJDIIohyVG+OGUfO10EjPbDXTyYj3gJMkkJEUgpP0yjYFtCDUVlo0aL5MC0auw4BoA BqQANwMLPev2ijh0dy2qAEzzb2uJXPMumjmZBwq4Gbom9XCqyfxIbVhoZOMuDRhTaKOva0Vr NqO0u0LImhRpGhvjBp7jsRM0bnaMbW5sMZKgoKEOVtq0aGXdzbUgsMZkeebIYiPAskHgGxEN hGhgyBoS5ahjAxVkI4DA0ESxUD3YkNcDk667/WvZD5WfjgZFoUQYHL1h5Cjilh8IsvhCijzN bvhnM8OJZk6GYRUCFKSsjWgpsyg36NZAjnSLUYARRLu0sBkLEJQEBAUlMBCiEIwg+H0Zl/Vn kfNq48dWsR2Zl7Kt0otVlSJqiUgKQTfN8bDr0OhgI9g6b6XXzmuMkiaNpgrO286Fs1BPGIV5 vc5IxEOAfDJHkwDIgFS5qGAGjnk41Hr1u8wCF3qfSZWmYhoXSCm8mZRSJewoFDJy103WZqjS whI0xvU6OoUCTpBSlKDs4oFGZDoLhXQt6oXmAQDEqCdrfeVILwVIRAndcAmLYcd2nXToIrpq 5NaCSQEeLeEs7VavNL1kJrihWENGo8YazTvu6QNDkKHknUNAYRIVJyMDDYnTDoJUUOwyMSJo jik2hnkZDYSBo5XFTMwU6aRFuKCWIyRhFCTQpYQXTTMO/dv0MEywMDuMTUqEDDM7DVfUm1MB vA/2JCQFQjGKkITxoWCDEZCLA7cjDuHXZ1Jvwf+mJA1EMFDJQFJomMS0dxImMatWqBd7ddAG BgxnCcm2c1TiYAyhiT4UWR1XKxi3UpCX3hffVRkkUkGZhsDkw2E0ABd0JIUYmKCqqDBgHs5x RRTmyTiE1GvN8D5dm3bl6UjImbUIapErFVciVs+xLBnAzlREbxsGSIO837NBqDSEdqDs6JsV srWwjqVLhwhCk46TcGvbbO7MzRDL4/u5Xsg658jljgcyhNILpHcnKy/JC4balmx3I9vMjOac G3s/F16mPBeSLwDbARVuXS9FFJBI0abDbxcePuzwNJtqnSluluydV4hbXbRsNMynivBoxgvK h2c4maAGUAMkQ0M3+Ix08YuMkq7Gnv/fQOTPSbTZyOJd2bDcdgRh0Az4G0Ds6AGI+EbB80Wc 5xwJi+MhoQ3htxsNjUdB7+n6Ty4d8EVboPHD+0JSUUUDxFNFlRP5JAZMk2RRNCDCKbzvUYPu 6ePAqd4WOHhzB0dDyH3bnWn4dIX+0ntIp0FWRDb3EL2gI9ykN0eH75u93MQ+1F/u0nj41oKE nGvMhE/IeVX2mY9niDhfonugUgQYnj9HJ9ehQiwUWKQwE2P0QDyicRDdKsaDKkveG+dIiXs/ Nj+mHwKx8GYbfFCoqj6/llII0BQDxqlx5Aw96d03jZNcDTIme/1dfq7j9KL4XrljWm0mR0Ed pvLGRJkoSdxYwzqbseG0A8uJjBgKwZBQEVFgwQkUhEcJIH3WLD30esjJ/htBeJD6mCgb6dDy HdSmUt2Q9ouBENnHgAajIGJBYCLBADnt388jQMSWXmTzgrnEXMKifZA0L1LKhbH8ATXn+g1i Xo/ITGl25mNFwAABJERGq1tWlti20ltgoW0BRRBnXMtawrg0MO+euInaYWNG6EtOo6EBwChw Rd7xpGS9MglIkSC+3ByAnFCmZT8voaFg4ZiC/fP/0/SEMszd3YEpUcKPEjksKh2LJkIXyk97 phvj1tETCDD8CBhiwoBgUraIYgP6wwbXWkzyTOzQCOU8pg1SQIC+gXNAMyCxSZRkoOjBHGIo p6AmE3QHOJ1m3wISGhVb6+xOnS3LZNbGrepaopq1guYkPn3KFp7OYKK8qLHdoLsSg4joH5BC wmPqO/bbDqaMe1yF/tBwGLoq8GSMYjkLoYmQQQ2hrhI7TaDxgHhhAgAyAoQYggdu4BO6MRVj GMRFRIrBQSKgKMBEIsUCVgHyjAmP8K6qDPxs/pYgwOPrOER/GwpqHQQCbmi4qKGGB8wNxVm0 Fh1UTruaXaf2uJhqmzoz/+LuSKcKEgWlW6Lg --pf9I7BMVVzbSWLtt-- From jimmy@e.kth.se Thu Feb 14 05:25:10 2002 From: jimmy@e.kth.se (Jimmy Engelbrecht) Date: 14 Feb 2002 06:25:10 +0100 Subject: [OpenAFS-devel] Java API for AFS Admin In-Reply-To: References: Message-ID: "Shyh-Wei Luan" writes: > Here a set of Java Admin API is proposed. The goal is to make the API > suitable not only for administrators to write custom AFS automation tools > but also for developers to write general and powerful tools for easy and > efficient AFS management. I have some questions. As you know the different servers allow you to do a few hundred different RPC-calls, is the idea that all of them should be accessible though the java-API ? How do you want to do RPC-calls from java ? Is there a usefull and working package that can do that for you ? You want to generate the RPC-stubs yourself ? Or you just steal the stubs from some exsisting AFS-implementation ? /Jimmy From haba@pdc.kth.se Fri Feb 15 01:31:16 2002 From: haba@pdc.kth.se (Harald Barth) Date: Fri, 15 Feb 2002 02:31:16 +0100 (CET) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: References:

Message-ID: <20020215.023116.123968733.haba@pdc.kth.se> > If there are no systems which need _P() now there's not much point in > using it; We're not likely to port to old crufty systems, we already have > ports for all of them. The only port I can't check is HPUX 11. Have you checked on osf1 -eh- dux -eh- tru64? I thought that kernel stuff was compiled with cc -std0 which means K&R. I think standards.h defines __(x) to () in this case. I have not checked this with an actual compile, but Mattias had the same opinion ;-) Harlad. From shadow@dementia.org Fri Feb 15 04:16:50 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 14 Feb 2002 23:16:50 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: <20020215.023116.123968733.haba@pdc.kth.se> Message-ID: On Fri, 15 Feb 2002, Harald Barth wrote: > > > If there are no systems which need _P() now there's not much point in > > using it; We're not likely to port to old crufty systems, we already have > > ports for all of them. The only port I can't check is HPUX 11. > > Have you checked on osf1 -eh- dux -eh- tru64? I thought that kernel stuff I haven't checked anything, yet. I was busy with other fun, appearing in CVS near you soon. > was compiled with cc -std0 which means K&R. I think standards.h defines > __(x) to () in this case. I have not checked this with an actual compile, > but Mattias had the same opinion ;-) From drosih@rpi.edu Fri Feb 15 20:45:04 2002 From: drosih@rpi.edu (Garance A Drosihn) Date: Fri, 15 Feb 2002 15:45:04 -0500 Subject: [OpenAFS-devel] Aaargh! Incompatible includes. In-Reply-To: <20020213124627.A6029@dev-linux.fsf.net> References: <20020213124627.A6029@dev-linux.fsf.net> Message-ID: At 12:46 PM -0600 2/13/02, Adam Thornton wrote: >How hard would it be to make OpenAFS rely on the >more-or-less-standard-by-now set of includes that OpenSSL and most >(Linux, anyway) distributions provide? > >I ask, because I've been having the very devil of a time getting AFS to >build on a SuSE 7.3 Pro system, or to get AFS to play nicely with Samba >2.2.3 built with the --with-afs configuration option. I have not tried Samba 2.2.3 yet, but the --with-afs option under Samba 2.2.2 is basically pointless. We run samba 2.2.2 on a linux machine, and we did not include the --with-afs option. The problem is there were a lot of changes made to samba since the original AFS support was added to samba, and most of the people doing that samba work have no contact with AFS. So, the AFS support has fallen apart as the rest of samba gets improved. Perhaps things have improved now that OpenAFS is available, and more people might be running AFS/OpenAFS clients. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From nneul@umr.edu Mon Feb 18 15:48:52 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Mon, 18 Feb 2002 09:48:52 -0600 Subject: [OpenAFS-devel] bad volume headers Message-ID: <415FFB77FC9411448DF6014DF8A5C2C11AC1C7@umr-mail3.umr.edu> It seems that most of the afs tools and server processes cannot deal with bad volume headers. In particular, if you somehow get a zero-length volume header in /vicep*, the only way to ever deal with that situation is to remove the Vfile by hand. Might be nice if some of the tools could handle this case better. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From haba@pdc.kth.se Mon Feb 18 17:58:57 2002 From: haba@pdc.kth.se (Harald Barth) Date: Mon, 18 Feb 2002 18:58:57 +0100 (CET) Subject: [OpenAFS-devel] bad volume headers In-Reply-To: <415FFB77FC9411448DF6014DF8A5C2C11AC1C7@umr-mail3.umr.edu> References: <415FFB77FC9411448DF6014DF8A5C2C11AC1C7@umr-mail3.umr.edu> Message-ID: <20020218.185857.84355859.haba@pdc.kth.se> Hi everyone, Funny, I just produced empty volume headers today. How? I was building Openafs 1.2.3 on AIX 4.3.3.0 and as soon as I create a new volume, I get the error message ": I/O error" from vos create and the Volserver logs: Mon Feb 18 18:41:25 2002 VCreateVolume: Problem lseek inode 512 (err=22) Mon Feb 18 18:41:25 2002 1 Volser: CreateVolume: Unable to create the volume; aborted, error code 103 Mon Feb 18 18:41:25 2002 : For future use Mon Feb 18 18:41:53 2002 VAttachVolume: Error reading volume header /vicepa/V0537039890.vl Mon Feb 18 18:41:53 2002 1 Volser: ListVolumes: Could not attach volume 537039890 (V0537039890.vl) error=101 Any enlightening tips and tricks before I dive into the source? Btw, how do I enable the Linux way of running the fileserver, I mean without depending on the inodes? Harald. From nneul@umr.edu Mon Feb 18 18:01:30 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Mon, 18 Feb 2002 12:01:30 -0600 Subject: [OpenAFS-devel] bad volume headers Message-ID: <415FFB77FC9411448DF6014DF8A5C2C11AC1CB@umr-mail3.umr.edu> I'm pretty sure it's a compile-time only option. --enable-namei or something like that.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Harald Barth [mailto:haba@pdc.kth.se]=20 > Sent: Monday, February 18, 2002 11:59 AM > To: Neulinger, Nathan > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] bad volume headers >=20 >=20 >=20 > Hi everyone, >=20 > Funny, I just produced empty volume headers today. How? I was building > Openafs 1.2.3 on AIX 4.3.3.0 and as soon as I create a new=20 > volume, I get > the error message ": I/O error" from vos create and the=20 > Volserver logs: >=20 > Mon Feb 18 18:41:25 2002 VCreateVolume: Problem lseek inode=20 > 512 (err=3D22) > Mon Feb 18 18:41:25 2002 1 Volser: CreateVolume: Unable to=20 > create the volume; aborted, error code 103 > Mon Feb 18 18:41:25 2002 : For future use=20 > Mon Feb 18 18:41:53 2002 VAttachVolume: Error reading volume=20 > header /vicepa/V0537039890.vl > Mon Feb 18 18:41:53 2002 1 Volser: ListVolumes: Could not=20 > attach volume 537039890 (V0537039890.vl) error=3D101 >=20 > Any enlightening tips and tricks before I dive into the source? >=20 > Btw, how do I enable the Linux way of running the fileserver, I mean > without depending on the inodes? >=20 > Harald. >=20 From rtm@cert.org Tue Feb 19 15:15:09 2002 From: rtm@cert.org (Rudolph T Maceyko) Date: Tue, 19 Feb 2002 10:15:09 -0500 Subject: [OpenAFS-devel] pam_afs.krb.so.1 ticket file naming problem (from OpenAFS 1.2.1 on) In-Reply-To: References: Message-ID: <43490000.1014131709@a4.blue.cert.org> I *still* see this problem with OpenAFS-1.2.3 (locally built from the SRPM for Red Hat 7.2 but w/o any source changes). auth sufficient /lib/security/pam_afs.krb.so try_first_pass ignore_root setenv_password_expires Now what? :-) Red Hat 7.2 +all errata Thanks, -Rudy --On Friday, November 02, 2001 02:50:13 -0500 Derrick J Brashear wrote: > On Thu, 1 Nov 2001, Jaroslaw Polok wrote: > >> I recently saw a problem with kerberos ticket file >> naming: >> >> all users logging (telnet) on a (linux) system get same >> ticket file name: >> >> /tmp/tkt0 >> . . . > Previously the code in afs_auth.c which called ka_VerifyUserPassword > set KA_USERAUTH_DOSETPAG in addition to KA_USERAUTH_VERSION whereas > now setpag() is called explicitly. I believe if after the calls to > setpag() in afs_auth.c and afs_setcred.c you add: > > #ifdef AFS_KERBEROS_ENV > ktc_newpag(); > #endif > > and compile, it will fix your problem. From Jaroslaw.Polok@cern.ch Tue Feb 19 14:22:22 2002 From: Jaroslaw.Polok@cern.ch (Jaroslaw.Polok@cern.ch) Date: Tue, 19 Feb 2002 15:22:22 +0100 (CET) Subject: [OpenAFS-devel] OpenAFS 1.2.3 - build of pam_afs.krb.so (krb4) is broken Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1970719967-205159589-1014039350=:1421 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Despite the comment in the RELEASE NOTES for 1.2.3: - the krb version of the module again correctly manages ticket files. Well , almost: still users may get tickets like /tmp/tkt0 ... Please find attached patch to src/pam/Makefile.in which fixes the build. Jaroslaw PS: I tested this on source tree from openafs-1.2.3-rh7.2.2.src.rpm (but I guess its the same for other package formats) -- ------------------------------------------------------- _ Jaroslaw_Polok ___________________ CERN - IT/ADC/LE _ _ http://home.cern.ch/~jpolok ___ tel_+41_22_767_1834 _ ______________________________________+41_78_7920795___ ---1970719967-205159589-1014039350=:1421 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="openafs-1.2.3-pam_afs.krb.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="openafs-1.2.3-pam_afs.krb.patch" KioqIG9wZW5hZnMtMS4yLjMtb3JnL3NyYy9wYW0vTWFrZWZpbGUuaW4JTW9u IEZlYiAxOCAxMzo1NToxOCAyMDAyDQotLS0gb3BlbmFmcy0xLjIuMy9zcmMv cGFtL01ha2VmaWxlLmluCU1vbiBGZWIgMTggMTQ6MDY6MDQgMjAwMg0KKioq KioqKioqKioqKioqDQoqKiogMzgsNDkgKioqKg0KICBMREZMQUdTID0gJHtT SEFSRV9MREZMQUdTfQ0KICAgICBMSUJTID0gJHtUT1BfTElCRElSfS9saWJr YXV0aC5hICR7TElCU0F9ICR7VE9QX0xJQkRJUn0vbGliYXV0aC5hIFwNCiAg CSAgJHtBRlNMSUJTfSAke1BBTUxJQlN9IEBMSUJfQUZTREJADQogICAgS0xJ QlMgPSAke1RPUF9MSUJESVJ9L2xpYmthdXRoLmtyYi5hICR7TElCU0F9ICR7 VE9QX0xJQkRJUn0vbGliYXV0aC5rcmIuYSBcDQogIAkgICR7QUZTTElCU30g JHtQQU1MSUJTfSBATElCX0FGU0RCQA0KISAgU0hPQkpTID0gYWZzX2F1dGgu byBhZnNfYWNjb3VudC5vIGFmc19zZXNzaW9uLm8gYWZzX3Bhc3N3b3JkLm8g XA0KISAJICBhZnNfcGFtX21zZy5vIGFmc19tZXNzYWdlLm8gYWZzX3V0aWwu byBBRlNfY29tcG9uZW50X3ZlcnNpb25fbnVtYmVyLm8NCiAgICAgT0JKUyA9 ICQoU0hPQkpTKSB0ZXN0X3BhbS5vDQogIElOQ0xVREVTPS1JJHtUT1BfU1JD RElSfS9jb25maWcgLUkke1RPUF9JTkNESVJ9IFwNCiAgCS1JL3Vzci9pbmNs dWRlIC1JL3Vzci9pbmNsdWRlL3N5cw0KICBDRkxBR1MgPSAgJHtERUJVR30g JHtJTkNMVURFU30gJHtQQU1fQ0ZMQUdTfQ0KICANCi0tLSAzOCw0OSAtLS0t DQogIExERkxBR1MgPSAke1NIQVJFX0xERkxBR1N9DQogICAgIExJQlMgPSAk e1RPUF9MSUJESVJ9L2xpYmthdXRoLmEgJHtMSUJTQX0gJHtUT1BfTElCRElS fS9saWJhdXRoLmEgXA0KICAJICAke0FGU0xJQlN9ICR7UEFNTElCU30gQExJ Ql9BRlNEQkANCiAgICBLTElCUyA9ICR7VE9QX0xJQkRJUn0vbGlia2F1dGgu a3JiLmEgJHtMSUJTQX0gJHtUT1BfTElCRElSfS9saWJhdXRoLmtyYi5hIFwN CiAgCSAgJHtBRlNMSUJTfSAke1BBTUxJQlN9IEBMSUJfQUZTREJADQohICBT SE9CSlMgPSBhZnNfYWNjb3VudC5vIGFmc19zZXNzaW9uLm8gYWZzX3Bhc3N3 b3JkLm8gXA0KISAJICBhZnNfcGFtX21zZy5vIGFmc19tZXNzYWdlLm8gQUZT X2NvbXBvbmVudF92ZXJzaW9uX251bWJlci5vDQogICAgIE9CSlMgPSAkKFNI T0JKUykgdGVzdF9wYW0ubw0KICBJTkNMVURFUz0tSSR7VE9QX1NSQ0RJUn0v Y29uZmlnIC1JJHtUT1BfSU5DRElSfSBcDQogIAktSS91c3IvaW5jbHVkZSAt SS91c3IvaW5jbHVkZS9zeXMNCiAgQ0ZMQUdTID0gICR7REVCVUd9ICR7SU5D TFVERVN9ICR7UEFNX0NGTEFHU30NCiAgDQoqKioqKioqKioqKioqKioNCioq KiA1Myw5MiAqKioqDQogIAkke0NDfSAke0NGTEFHU30gLWMgYWZzX3NldGNy ZWQuYyAtbyBhZnNfc2V0Y3JlZC5vDQogIA0KICBhZnNfc2V0Y3JlZF9rcmIu bzogYWZzX3NldGNyZWQuYyBhZnNfcGFtX21zZy5oIGFmc19tZXNzYWdlLmgg YWZzX3V0aWwuaA0KICAJJHtDQ30gJHtDRkxBR1N9IC1EQUZTX0tFUkJFUk9T X0VOViAtYyBhZnNfc2V0Y3JlZC5jIC1vIGFmc19zZXRjcmVkX2tyYi5vDQog IA0KISBwYW1fYWZzLnNvLjE6ICQoU0hPQkpTKSBhZnNfc2V0Y3JlZC5vDQog IAlzZXQgLXg7IFwNCiAgCWNhc2UgIiQoU1lTX05BTUUpIiBpbiBcDQogIAlo cF91eCopIFwNCiEgCQkkKExEKSAkKExERkxBR1MpIC1jIG1hcGZpbGUuaHAg LW8gJEAgYWZzX3NldGNyZWQubyBcDQogIAkJCSQoU0hPQkpTKSAkKExJQlMp IDs7IFwNCiAgCXN1bipfNSopIFwNCiEgCQkkKExEKSAkKExERkxBR1MpIC1N IG1hcGZpbGUgLW8gJEAgYWZzX3NldGNyZWQubyBcDQogIAkJCSQoU0hPQkpT KSAkKExJQlMpIDs7IFwNCiAgCSpsaW51eCopIFwNCiEgCQkkKENDKSAkKExE RkxBR1MpIC1vICRAIGFmc19zZXRjcmVkLm8gJChTSE9CSlMpICQoTElCUykg OztcDQogIAkqZmJzZCopIFwNCiEgCQkkKENDKSAkKExERkxBR1MpIC1vICRA IGFmc19zZXRjcmVkLm8gJChTSE9CSlMpICQoTElCUykgOztcDQogIAkqICkg XA0KICAJCWVjaG8gTm8gbGluayBsaW5lIGZvciBzeXN0ZW0gJChTWVNfTkFN RSkuIDs7IFwNCiAgCWVzYWMNCiAgDQohIHBhbV9hZnMua3JiLnNvLjE6ICQo U0hPQkpTKSBhZnNfc2V0Y3JlZF9rcmIubw0KICAJc2V0IC14OyBcDQogIAlj YXNlICIkKFNZU19OQU1FKSIgaW4gXA0KICAJaHBfdXgqKSBcDQogIAkJJChM RCkgJChMREZMQUdTKSAtYyBtYXBmaWxlLmhwIC1vICRAIFwNCiEgCQkJYWZz X3NldGNyZWRfa3JiLm8gJChTSE9CSlMpICQoTERGTEFHUykgJChLTElCUykg OzsgXA0KICAJc3VuKl81KikgXA0KICAJCSQoTEQpICQoTERGTEFHUykgLU0g bWFwZmlsZSAtbyAkQCBcDQohIAkJCWFmc19zZXRjcmVkX2tyYi5vICQoU0hP QkpTKSAkKExERkxBR1MpICQoS0xJQlMpIDs7IFwNCiAgCSpsaW51eCopIFwN CiEgCQkkKENDKSAkKExERkxBR1MpIC1vICRAIGFmc19zZXRjcmVkX2tyYi5v ICQoU0hPQkpTKSAkKEtMSUJTKSA7O1wNCiAgCSpmYnNkKikgXA0KISAJCSQo Q0MpICQoTERGTEFHUykgLW8gJEAgYWZzX3NldGNyZWRfa3JiLm8gJChTSE9C SlMpICQoS0xJQlMpIDs7XA0KICAJKiApIFwNCiAgCQllY2hvIE5vIGxpbmsg bGluZSBmb3Igc3lzdGVtICQoU1lTX05BTUUpLiA7OyBcDQogIAllc2FjDQog IA0KICB0ZXN0X3BhbTogdGVzdF9wYW0ubw0KLS0tIDUzLDEwNCAtLS0tDQog IAkke0NDfSAke0NGTEFHU30gLWMgYWZzX3NldGNyZWQuYyAtbyBhZnNfc2V0 Y3JlZC5vDQogIA0KICBhZnNfc2V0Y3JlZF9rcmIubzogYWZzX3NldGNyZWQu YyBhZnNfcGFtX21zZy5oIGFmc19tZXNzYWdlLmggYWZzX3V0aWwuaA0KICAJ JHtDQ30gJHtDRkxBR1N9IC1EQUZTX0tFUkJFUk9TX0VOViAtYyBhZnNfc2V0 Y3JlZC5jIC1vIGFmc19zZXRjcmVkX2tyYi5vDQogIA0KISBhZnNfYXV0aC5v OiBhZnNfYXV0aC5jIGFmc19wYW1fbXNnLmggYWZzX21lc3NhZ2UuaCBhZnNf dXRpbC5oDQohIAkke0NDfSAke0NGTEFHU30gIC1jIGFmc19hdXRoLmMgLW8g YWZzX2F1dGgubw0KISANCiEgYWZzX2F1dGhfa3JiLm86IGFmc19hdXRoLmMg YWZzX3BhbV9tc2cuaCBhZnNfbWVzc2FnZS5oIGFmc191dGlsLmgNCiEgCSR7 Q0N9ICR7Q0ZMQUdTfSAtREFGU19LRVJCRVJPU19FTlYgIC1jIGFmc19hdXRo LmMgLW8gYWZzX2F1dGhfa3JiLm8NCiEgDQohIGFmc191dGlsLm86IGFmc191 dGlsLmMgYWZzX3V0aWwuaA0KISAJJHtDQ30gJHtDRkxBR1N9IC1jIGFmc191 dGlsLmMgLW8gYWZzX3V0aWwubw0KISANCiEgYWZzX3V0aWxfa3JiLm86IGFm c191dGlsLmMgYWZzX3V0aWwuaA0KISAJJHtDQ30gJHtDRkxBR1N9IC1EQUZT X0tFUkJFUk9TX0VOViAtYyBhZnNfdXRpbC5jIC1vIGFmc191dGlsX2tyYi5v DQohIA0KISBwYW1fYWZzLnNvLjE6ICQoU0hPQkpTKSBhZnNfc2V0Y3JlZC5v IGFmc19hdXRoLm8gYWZzX3V0aWwubw0KICAJc2V0IC14OyBcDQogIAljYXNl ICIkKFNZU19OQU1FKSIgaW4gXA0KICAJaHBfdXgqKSBcDQohIAkJJChMRCkg JChMREZMQUdTKSAtYyBtYXBmaWxlLmhwIC1vICRAIGFmc19zZXRjcmVkLm8g YWZzX2F1dGgubyBhZnNfdXRpbC5vXA0KICAJCQkkKFNIT0JKUykgJChMSUJT KSA7OyBcDQogIAlzdW4qXzUqKSBcDQohIAkJJChMRCkgJChMREZMQUdTKSAt TSBtYXBmaWxlIC1vICRAIGFmc19zZXRjcmVkLm8gYWZzX2F1dGgubyBhZnNf dXRpbC5vXA0KICAJCQkkKFNIT0JKUykgJChMSUJTKSA7OyBcDQogIAkqbGlu dXgqKSBcDQohIAkJJChDQykgJChMREZMQUdTKSAtbyAkQCBhZnNfc2V0Y3Jl ZC5vIGFmc19hdXRoLm8gYWZzX3V0aWwubyAkKFNIT0JKUykgJChMSUJTKSA7 O1wNCiAgCSpmYnNkKikgXA0KISAJCSQoQ0MpICQoTERGTEFHUykgLW8gJEAg YWZzX3NldGNyZWQubyBhZnNfYXV0aC5vIGFmc191dGlsLm8gJChTSE9CSlMp ICQoTElCUykgOztcDQogIAkqICkgXA0KICAJCWVjaG8gTm8gbGluayBsaW5l IGZvciBzeXN0ZW0gJChTWVNfTkFNRSkuIDs7IFwNCiAgCWVzYWMNCiAgDQoh IHBhbV9hZnMua3JiLnNvLjE6ICQoU0hPQkpTKSBhZnNfc2V0Y3JlZF9rcmIu byBhZnNfYXV0aF9rcmIubyBhZnNfdXRpbF9rcmIubw0KICAJc2V0IC14OyBc DQogIAljYXNlICIkKFNZU19OQU1FKSIgaW4gXA0KICAJaHBfdXgqKSBcDQog IAkJJChMRCkgJChMREZMQUdTKSAtYyBtYXBmaWxlLmhwIC1vICRAIFwNCiEg CQkJYWZzX3NldGNyZWRfa3JiLm8gYWZzX2F1dGhfa3JiLm8gYWZzX3V0aWxf a3JiLm8gJChTSE9CSlMpICQoTERGTEFHUykgJChLTElCUykgOzsgXA0KICAJ c3VuKl81KikgXA0KICAJCSQoTEQpICQoTERGTEFHUykgLU0gbWFwZmlsZSAt byAkQCBcDQohIAkJCWFmc19zZXRjcmVkX2tyYi5vIGFmc19hdXRoX2tyYi5v IGFmc191dGlsX2tyYi5vICQoU0hPQkpTKSAkKExERkxBR1MpICQoS0xJQlMp IDs7IFwNCiAgCSpsaW51eCopIFwNCiEgCQkkKENDKSAkKExERkxBR1MpIC1v ICRAIGFmc19zZXRjcmVkX2tyYi5vIGFmc19hdXRoX2tyYi5vIGFmc191dGls X2tyYi5vICQoU0hPQkpTKSAkKEtMSUJTKSA7O1wNCiAgCSpmYnNkKikgXA0K ISAJCSQoQ0MpICQoTERGTEFHUykgLW8gJEAgYWZzX3NldGNyZWRfa3JiLm8g YWZzX2F1dGhfa3JiLm8gYWZzX3V0aWxfa3JiLm8gJChTSE9CSlMpICQoS0xJ QlMpIDs7XA0KICAJKiApIFwNCiAgCQllY2hvIE5vIGxpbmsgbGluZSBmb3Ig c3lzdGVtICQoU1lTX05BTUUpLiA7OyBcDQogIAllc2FjDQogIA0KICB0ZXN0 X3BhbTogdGVzdF9wYW0ubw0KKioqKioqKioqKioqKioqDQoqKiogMTEwLDEy MyAqKioqDQogIAkke0lOU1RBTEx9ICQ/ICRADQogIA0KICAke0RFU1R9L2xp Yi9wYW1fYWZzLmtyYi5zby4xOiBwYW1fYWZzLmtyYi5zby4xDQogIAkke0lO U1RBTEx9ICQ/ICRADQogIA0KLSBhZnNfYXV0aC5vOiBhZnNfYXV0aC5jIGFm c19wYW1fbXNnLmggYWZzX21lc3NhZ2UuaCBhZnNfdXRpbC5oDQogIGFmc19w YW1fbXNnLm86IGFmc19wYW1fbXNnLmMgYWZzX3BhbV9tc2cuaCBhZnNfbWVz c2FnZS5oDQogIGFmc19tZXNzYWdlLm86IGFmc19tZXNzYWdlLmMgYWZzX21l c3NhZ2UuaA0KLSBhZnNfdXRpbC5vOiBhZnNfdXRpbC5jIGFmc191dGlsLmgN CiAgDQogICMNCiAgIyBNaXNjLiB0YXJnZXRzDQogICMNCiAgY2xlYW46DQot LS0gMTIyLDEzMyAtLS0tDQo= ---1970719967-205159589-1014039350=:1421-- From openafs-devel@openafs.org Tue Feb 19 15:31:09 2002 From: openafs-devel@openafs.org (Derek Atkins) Date: 19 Feb 2002 10:31:09 -0500 Subject: [OpenAFS-devel] pam_afs.krb.so.1 ticket file naming problem (from OpenAFS 1.2.1 on) In-Reply-To: <43490000.1014131709@a4.blue.cert.org> References: <43490000.1014131709@a4.blue.cert.org> Message-ID: This implies that either KRBTKFILE is not being set properly, or the 'KRBTKFILE autocreation' is running in root's context instead of the user's context. I don't know enough about the PAM implementation to tell you which is happening. -derek Rudolph T Maceyko writes: > I *still* see this problem with OpenAFS-1.2.3 (locally built from the > SRPM for Red Hat 7.2 but w/o any source changes). > > auth sufficient /lib/security/pam_afs.krb.so try_first_pass > ignore_root setenv_password_expires > > Now what? :-) > > Red Hat 7.2 +all errata > > Thanks, > -Rudy > > --On Friday, November 02, 2001 02:50:13 -0500 Derrick J Brashear > wrote: > > > On Thu, 1 Nov 2001, Jaroslaw Polok wrote: > > > >> I recently saw a problem with kerberos ticket file > >> naming: > >> > >> all users logging (telnet) on a (linux) system get same > >> ticket file name: > >> > >> /tmp/tkt0 > >> > . > . > . > > Previously the code in afs_auth.c which called ka_VerifyUserPassword > > set KA_USERAUTH_DOSETPAG in addition to KA_USERAUTH_VERSION whereas > > now setpag() is called explicitly. I believe if after the calls to > > setpag() in afs_auth.c and afs_setcred.c you add: > > > > #ifdef AFS_KERBEROS_ENV > > ktc_newpag(); > > #endif > > > > and compile, it will fix your problem. > > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From rtm@cert.org Tue Feb 19 15:37:29 2002 From: rtm@cert.org (Rudolph T Maceyko) Date: Tue, 19 Feb 2002 10:37:29 -0500 Subject: [OpenAFS-devel] pam_afs.krb.so.1 ticket file naming problem (from OpenAFS 1.2.1 on) In-Reply-To: References: <43490000.1014131709@a4.blue.cert.org> Message-ID: <72620000.1014133049@a4.blue.cert.org> I'm trying the patch Jaroslaw Polok just sent. I'll report back with the results... Thanks, -Rudy --On Tuesday, February 19, 2002 10:31:09 -0500 Derek Atkins wrote: > This implies that either KRBTKFILE is not being set properly, or the > 'KRBTKFILE autocreation' is running in root's context instead of the > user's context. I don't know enough about the PAM implementation to > tell you which is happening. > > -derek > > Rudolph T Maceyko writes: > >> I *still* see this problem with OpenAFS-1.2.3 (locally built from the >> SRPM for Red Hat 7.2 but w/o any source changes). From rtm@cert.org Tue Feb 19 19:17:28 2002 From: rtm@cert.org (Rudolph T Maceyko) Date: Tue, 19 Feb 2002 14:17:28 -0500 Subject: [OpenAFS-devel] OpenAFS 1.2.3 - build of pam_afs.krb.so (krb4) is broken In-Reply-To: References: Message-ID: <1650000.1014146248@a4.blue.cert.org> Jaroslaw, thanks for the patch. It seems to have fixed the problem. -Rudy --On Tuesday, February 19, 2002 15:22:22 +0100 Jaroslaw.Polok@cern.ch wrote: > Despite the comment in the RELEASE NOTES for 1.2.3: > - the krb version of the module again correctly manages ticket files. > > Well , almost: > still users may get tickets like /tmp/tkt0 ... > > Please find attached patch to src/pam/Makefile.in > which fixes the build. From luan@almaden.ibm.com Tue Feb 26 08:00:01 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Tue, 26 Feb 2002 00:00:01 -0800 Subject: [OpenAFS-devel] Re: [OpenAFS] Problem with large data transfer (WinNT AFS, please HELP!) Message-ID: Is it possible that your AFS server is overloaded? The 1009 event id indicates an RX timeout, i.e., the server did not respond to the client in time. If you have a 2 gig volume being read by a large number of users (how big was your pilot) simultaneously. The server might be slowed down significantly. You may want to replicate the volume and somehow scatter the installation time of users. I am testing a large copy here to see if I can reproduce the error. Shyh-Wei Luan Lubos Kejzlar @openafs.org on 02/25/2002 11:59:10 AM Sent by: openafs-info-admin@openafs.org To: OpenAFS Info Mailing List , OpenAFS Developers Mailing List , AFS mail list cc: Subject: [OpenAFS] Problem with large data transfer (WinNT AFS, please HELP!) Hi all, we are trying to extend our (long lived) campus-wide Unix-based AFS infrastructure (Transarc AFS 3.6 DB servers, mix of Transarc/OpenAFS clients) to end-user workstations running Win 98/NT/W2k as a main distributed storage solution. Unfortunately, our users experienced _significant_ problems during pilot phase: - all significant tests are running on Win NT SP5 workstations. Similar problems are reported by Win98 users (smaller amount of data, not proved yet by support people) - as an part of automated SW installation, there is need to copy large subtree from AFS to local file system (there is no possibility to run SW directly from AFS space, unfortunately): - all data are readable to system:anyuser - both client & server are using 100baseT-FD network connections and there are no communication problem during tests - total amount of data copied is about 2+ GB - there is large number (70+ k) of small files to copy - all data are located in single volume - unfortunately, we are _UNABLE_ to copy such data using (any) different methods (MS Explorer, Perl-based command line tools, etc.): - the copy process breaks at random (AFAIK) point with following error events (occurred roughly at same time in system/application event log): EventID: 3013 The redirector has timed out request to xxxxxx-afs ... EventID: 1009 cm_Analyze: HardDeadTime exceeded .... and/or (?) EventID: 1005 Pkt straddled session startup, took xxxxxx ms, ncb length xxx. - there are no active CM RX connections (from rxdebux) and system seems to be 'frozen' for a while, during error event (AFAIK). Does someone ever seen similar problems?? Currently it's really _HIGH_PRIORITY_ISSUE_ for us to provide and support single distributed FS infrastructure for all our users (10000+), so we are looking for _ANY_HELP_OR_SUGGESTION_ (I'm not very familiar with M$ Windows, but I'm able (glad) to provide any further info for someone could help us)! So again thank you VERY MUCH in advance for _ANY_HELP_OR SUGGESTION_ !! Best regards, Lubos -------------------------------------------------------------------------- Lubos Kejzlar System and Network Specialist Laboratory for Computer Science Tel.: ++420-19-7491536 University of West Bohemia ++420-19-7421414 Univerzitni 8, 30614 Pilsen Fax: ++420-19-7421419 Czech Republic E-mail: kejzlar@civ.zcu.cz PGP Key fingerprint = 5621 06DA 3EDE 5D15 F287 5408 9B8E C766 CD64 3A3F -------------------------------------------------------------------------- _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info From kejzlar@civ.zcu.cz Mon Feb 25 19:59:10 2002 From: kejzlar@civ.zcu.cz (Lubos Kejzlar) Date: Mon, 25 Feb 2002 20:59:10 +0100 (CET) Subject: [OpenAFS-devel] Problem with large data transfer (WinNT AFS, please HELP!) Message-ID: Hi all, we are trying to extend our (long lived) campus-wide Unix-based AFS infrastructure (Transarc AFS 3.6 DB servers, mix of Transarc/OpenAFS clients) to end-user workstations running Win 98/NT/W2k as a main distributed storage solution. Unfortunately, our users experienced _significant_ problems during pilot phase: - all significant tests are running on Win NT SP5 workstations. Similar problems are reported by Win98 users (smaller amount of data, not proved yet by support people) - as an part of automated SW installation, there is need to copy large subtree from AFS to local file system (there is no possibility to run SW directly from AFS space, unfortunately): - all data are readable to system:anyuser - both client & server are using 100baseT-FD network connections and there are no communication problem during tests - total amount of data copied is about 2+ GB - there is large number (70+ k) of small files to copy - all data are located in single volume - unfortunately, we are _UNABLE_ to copy such data using (any) different methods (MS Explorer, Perl-based command line tools, etc.): - the copy process breaks at random (AFAIK) point with following error events (occurred roughly at same time in system/application event log): EventID: 3013 The redirector has timed out request to xxxxxx-afs ... EventID: 1009 cm_Analyze: HardDeadTime exceeded .... and/or (?) EventID: 1005 Pkt straddled session startup, took xxxxxx ms, ncb length xxx. - there are no active CM RX connections (from rxdebux) and system seems to be 'frozen' for a while, during error event (AFAIK). Does someone ever seen similar problems?? Currently it's really _HIGH_PRIORITY_ISSUE_ for us to provide and support single distributed FS infrastructure for all our users (10000+), so we are looking for _ANY_HELP_OR_SUGGESTION_ (I'm not very familiar with M$ Windows, but I'm able (glad) to provide any further info for someone could help us)! So again thank you VERY MUCH in advance for _ANY_HELP_OR SUGGESTION_ !! Best regards, Lubos -------------------------------------------------------------------------- Lubos Kejzlar System and Network Specialist Laboratory for Computer Science Tel.: ++420-19-7491536 University of West Bohemia ++420-19-7421414 Univerzitni 8, 30614 Pilsen Fax: ++420-19-7421419 Czech Republic E-mail: kejzlar@civ.zcu.cz PGP Key fingerprint = 5621 06DA 3EDE 5D15 F287 5408 9B8E C766 CD64 3A3F -------------------------------------------------------------------------- From dlapine@ncsa.uiuc.edu Tue Feb 26 15:52:19 2002 From: dlapine@ncsa.uiuc.edu (Dan Lapine) Date: Tue, 26 Feb 2002 09:52:19 -0600 (CST) Subject: [OpenAFS-devel] Problem with large data transfer (WinNT AFS, please HELP!) In-Reply-To: Message-ID: Any possiblity of using ssh to move the data that one time? Don't use afs to copy that much out, but rather use a more traditional method to get the data on the computers. There are very nice windows programs that will do scp from a central server. On the other hand, 2.0GB of data over 100baseT is going to take a while (10 megs/sec for 2000 megs is 200 secs, absolute best speed- that's 200 seconds for each of 10 thousand machines. ouch) On Mon, 25 Feb 2002, Lubos Kejzlar wrote: > Hi all, > > we are trying to extend our (long lived) campus-wide Unix-based AFS > infrastructure (Transarc AFS 3.6 DB servers, mix of Transarc/OpenAFS clients) > to end-user workstations running Win 98/NT/W2k as a main distributed > storage solution. > > Unfortunately, our users experienced _significant_ problems during pilot > phase: > > - all significant tests are running on Win NT SP5 workstations. Similar > problems are reported by Win98 users (smaller amount of data, not proved > yet by support people) > > - as an part of automated SW installation, there is need to copy large > subtree from AFS to local file system (there is no possibility to run SW > directly from AFS space, unfortunately): > > - all data are readable to system:anyuser > - both client & server are using 100baseT-FD network connections and > there are no communication problem during tests > - total amount of data copied is about 2+ GB > - there is large number (70+ k) of small files to copy > - all data are located in single volume > > - unfortunately, we are _UNABLE_ to copy such data using (any) different > methods (MS Explorer, Perl-based command line tools, etc.): > > - the copy process breaks at random (AFAIK) point with following error > events (occurred roughly at same time in system/application event log): > > EventID: 3013 > The redirector has timed out request to xxxxxx-afs ... > > EventID: 1009 > cm_Analyze: HardDeadTime exceeded .... > > and/or (?) > > EventID: 1005 > Pkt straddled session startup, took xxxxxx ms, ncb length xxx. > > - there are no active CM RX connections (from rxdebux) and system seems > to be 'frozen' for a while, during error event (AFAIK). > > > Does someone ever seen similar problems?? > > Currently it's really _HIGH_PRIORITY_ISSUE_ for us to provide and support > single distributed FS infrastructure for all our users (10000+), so we are > looking for _ANY_HELP_OR_SUGGESTION_ (I'm not very familiar with M$ > Windows, but I'm able (glad) to provide any further info for someone could > help us)! > > So again thank you VERY MUCH in advance for _ANY_HELP_OR SUGGESTION_ !! > > Best regards, > Lubos > > -------------------------------------------------------------------------- > Lubos Kejzlar > System and Network Specialist > > Laboratory for Computer Science Tel.: ++420-19-7491536 > University of West Bohemia ++420-19-7421414 > Univerzitni 8, 30614 Pilsen Fax: ++420-19-7421419 > Czech Republic E-mail: kejzlar@civ.zcu.cz > > PGP Key fingerprint = 5621 06DA 3EDE 5D15 F287 5408 9B8E C766 CD64 3A3F > -------------------------------------------------------------------------- > > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel > -- --- Daniel LaPine, System Engineer National Center for Supercomputing Applications (NCSA) email: dlapine@ncsa.uiuc.edu phone: 217-244-9294 From nneul@umr.edu Tue Feb 26 16:35:03 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 26 Feb 2002 10:35:03 -0600 Subject: [OpenAFS-devel] problems with rxgen changes... ubik_tid, ubik_version doubly defined... Message-ID: <415FFB77FC9411448DF6014DF8A5C2C11AC245@umr-mail3.umr.edu> They are getting defined in both ubik.h and ubik_int.h: gcc -I. -I/umr/s/openafs/openafs/src/ubik -O2 -I/umr/s/openafs/build/i386_linux24/src/config -I. -I/umr/s/openafs/build/i386_linux24/include -O2 -D_LARGEFILE64_SOURCE -c -o disk.o /umr/s/openafs/openafs/src/ubik/disk.c In file included from /umr/s/openafs/openafs/src/ubik/disk.c:36: ubik.h:105: redefinition of `struct ubik_tid' ubik.h:111: redefinition of `struct ubik_version' gmake: *** [disk.o] Error 1 ubik.h includes ubik_int.h, which appears to be why this is happening.=20 I can brute force a fix with ifdef's to only define them once, but that seems tacky. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From kolya@MIT.EDU Tue Feb 26 16:40:44 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Tue, 26 Feb 2002 11:40:44 -0500 Subject: [OpenAFS-devel] problems with rxgen changes... ubik_tid, ubik_version doubly defined... Message-ID: <200202261640.LAA00547@geo-prism.mit.edu> > They are getting defined in both ubik.h and ubik_int.h: > [...] If you cvs update, you should notice this particular problem (and a few others having to do with rxgen prototypes) have been fixed in the mainline. There's still a more annoying problem in afsfileprocs.c where CallPreamble magically turns an rx_call into rx_connection, and the arguments to the SRXAFS functions aren't what the prototypes say they should be. In particular, most SRXAFS functions type their first arg as "struct rx_connection *" when the prototypes consider them to be "struct rx_call *". I haven't fixed this one yet. -- kolya From nneul@umr.edu Tue Feb 26 16:41:51 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 26 Feb 2002 10:41:51 -0600 Subject: [OpenAFS-devel] problems with rxgen changes... ubik_tid, ubik_version doubly defined... Message-ID: <415FFB77FC9411448DF6014DF8A5C2C11AC246@umr-mail3.umr.edu> Really? I just did an update a couple minutes ago... I'll try again...=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Nickolai Zeldovich [mailto:kolya@MIT.EDU]=20 > Sent: Tuesday, February 26, 2002 10:41 AM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] problems with rxgen changes...=20 > ubik_tid, ubik_version doubly defined... >=20 >=20 > > They are getting defined in both ubik.h and ubik_int.h: > > [...] >=20 > If you cvs update, you should notice this particular problem > (and a few others having to do with rxgen prototypes) have > been fixed in the mainline. >=20 > There's still a more annoying problem in afsfileprocs.c where > CallPreamble magically turns an rx_call into rx_connection, > and the arguments to the SRXAFS functions aren't what the > prototypes say they should be. In particular, most SRXAFS > functions type their first arg as "struct rx_connection *" > when the prototypes consider them to be "struct rx_call *". > I haven't fixed this one yet. >=20 > -- kolya > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Tue Feb 26 16:41:39 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 26 Feb 2002 11:41:39 -0500 (EST) Subject: [OpenAFS-devel] problems with rxgen changes... ubik_tid, ubik_version doubly defined... In-Reply-To: <200202261640.LAA00547@geo-prism.mit.edu> Message-ID: On Tue, 26 Feb 2002, Nickolai Zeldovich wrote: > > They are getting defined in both ubik.h and ubik_int.h: > > [...] > > If you cvs update, you should notice this particular problem > (and a few others having to do with rxgen prototypes) have > been fixed in the mainline. You fixed all the ones I had patches laying around for, but... > There's still a more annoying problem in afsfileprocs.c where > CallPreamble magically turns an rx_call into rx_connection, > and the arguments to the SRXAFS functions aren't what the > prototypes say they should be. In particular, most SRXAFS > functions type their first arg as "struct rx_connection *" > when the prototypes consider them to be "struct rx_call *". > I haven't fixed this one yet. Indeed, I haven't figured out the right course of action on this one yet either. From nneul@umr.edu Tue Feb 26 16:44:34 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 26 Feb 2002 10:44:34 -0600 Subject: [OpenAFS-devel] problems with rxgen changes... ubik_tid, ubik_version doubly defined... Message-ID: <415FFB77FC9411448DF6014DF8A5C2C11AC247@umr-mail3.umr.edu> Nope... your patch took it from net_version to ubik_version, ubik_tid, but I'm getting double defines of ubik_version and ubik_tid cause of it being in ubik.p.h. Simply commenting the defs out of ubik.p.h seems to fix build in the ubik dir, but haven't checkout outside yet.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Neulinger, Nathan=20 > Sent: Tuesday, February 26, 2002 10:42 AM > To: Nickolai Zeldovich; openafs-devel@openafs.org > Subject: RE: [OpenAFS-devel] problems with rxgen changes...=20 > ubik_tid, ubik_version doubly defined... >=20 >=20 > Really? I just did an update a couple minutes ago... I'll try=20 > again...=20 >=20 > -- Nathan >=20 > ------------------------------------------------------------ > Nathan Neulinger EMail: nneul@umr.edu > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 >=20 >=20 > > -----Original Message----- > > From: Nickolai Zeldovich [mailto:kolya@MIT.EDU]=20 > > Sent: Tuesday, February 26, 2002 10:41 AM > > To: openafs-devel@openafs.org > > Subject: Re: [OpenAFS-devel] problems with rxgen changes...=20 > > ubik_tid, ubik_version doubly defined... > >=20 > >=20 > > > They are getting defined in both ubik.h and ubik_int.h: > > > [...] > >=20 > > If you cvs update, you should notice this particular problem > > (and a few others having to do with rxgen prototypes) have > > been fixed in the mainline. > >=20 > > There's still a more annoying problem in afsfileprocs.c where > > CallPreamble magically turns an rx_call into rx_connection, > > and the arguments to the SRXAFS functions aren't what the > > prototypes say they should be. In particular, most SRXAFS > > functions type their first arg as "struct rx_connection *" > > when the prototypes consider them to be "struct rx_call *". > > I haven't fixed this one yet. > >=20 > > -- kolya > > _______________________________________________ > > OpenAFS-devel mailing list > > OpenAFS-devel@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-devel > >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From kolya@MIT.EDU Tue Feb 26 16:45:48 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Tue, 26 Feb 2002 11:45:48 -0500 Subject: [OpenAFS-devel] problems with rxgen changes... ubik_tid, ubik_version doubly defined... Message-ID: <200202261645.LAA00591@geo-prism.mit.edu> > If you cvs update, you should notice this particular problem > (and a few others having to do with rxgen prototypes) have > been fixed in the mainline. .. and if I'd read your message more carefully, I would have realized you were already using those sources and I forgot to commit a change to ubik.p.h :-) Try now? -- kolya From nneul@umr.edu Tue Feb 26 16:47:01 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 26 Feb 2002 10:47:01 -0600 Subject: [OpenAFS-devel] problems with rxgen changes... ubik_tid, ubik_version doubly defined... Message-ID: <415FFB77FC9411448DF6014DF8A5C2C11AC248@umr-mail3.umr.edu> Yep. That fixed it. Thanks! -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Nickolai Zeldovich [mailto:kolya@MIT.EDU]=20 > Sent: Tuesday, February 26, 2002 10:46 AM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] problems with rxgen changes...=20 > ubik_tid, ubik_version doubly defined... >=20 >=20 > > If you cvs update, you should notice this particular problem > > (and a few others having to do with rxgen prototypes) have > > been fixed in the mainline. >=20 > .. and if I'd read your message more carefully, I would have > realized you were already using those sources and I forgot to > commit a change to ubik.p.h :-) Try now? >=20 > -- kolya > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From Frank Batschulat Wed Feb 27 10:12:56 2002 From: Frank Batschulat (Frank Batschulat) Date: Wed, 27 Feb 2002 11:12:56 +0100 (MET) Subject: [OpenAFS-devel] How to know filesystems managed by AFS Message-ID: <200202271014.LAA21434@hs-eber02-01.Germany.Sun.COM> Hi All, I often get the problem to find out AFS managed UFS filesystems, there is no info about the filesystems AFS sits on top of in neither the crash dumps itself, nor the /etc/mnttab or /etc/vfstab. All that appears is the following entry in /etc/mnttab: AFS /afs afs dev=100000 1011729826 df gives you: /afs (AFS ):18000000 blocks 9000000 files I'd really appreciate pointers to look at to find out a AFS configuration in terms of which AFS mountpoint/filesystem has which underlying real FS mountpoint/filesystem. thx frankB From luan@almaden.ibm.com Wed Feb 27 10:23:32 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Wed, 27 Feb 2002 02:23:32 -0800 Subject: [OpenAFS-devel] Re: [OpenAFS] Problem with large data transfer (WinNT AFS, please HELP!) Message-ID: Have you tried xcopy? It may work better for your need. Explorer seems to stubbornly want to scan the whole source sub-tree before starting to copy the first file. My experiment with using it to copy a super large tree never went beyond the "prepare copy" stage. Your AFS directory is not really publicly readable. I was only able to get your cell root directory and got access denied at the platform directory. Shyh-Wei Luan Lubos Kejzlar on 02/26/2002 12:45:00 AM To: Shyh-Wei Luan/Almaden/IBM@IBMUS cc: Subject: Re: [OpenAFS] Problem with large data transfer (WinNT AFS, please HELP!) Hi, On Tue, 26 Feb 2002, Shyh-Wei Luan wrote: > Is it possible that your AFS server is overloaded? The 1009 event id > indicates an RX timeout, i.e., the server did not respond to the client in > time. If you have a 2 gig volume being read by a large number of users > (how big was your pilot) simultaneously. The server might be slowed down > significantly. You may want to replicate the volume and somehow scatter > the installation time of users. I don't think so. There is only one such copy-test at time (but FS serves simultaneously other request). As I mentioned before, timeout occurs during small (typically <256k) file transfer and there are no active connections (reader_wait) on affected client (from rxdebug listing). FS seems to have enough network, disk and memory resources available AFAIK. > I am testing a large copy here to see if I can reproduce the error. You can look at (and try to copy) our actual (publicly readable) files (see attachment) if you can. I would be happy to provide any further info to help you give us any help or suggestions! Thanks again! Best regards, Lubos -------------------------------------------------------------------------- Lubos Kejzlar System and Network Specialist Laboratory for Computer Science Tel.: ++420-19-7491536 University of West Bohemia ++420-19-7421414 Univerzitni 8, 30614 Pilsen Fax: ++420-19-7421419 Czech Republic E-mail: kejzlar@civ.zcu.cz PGP Key fingerprint = 5621 06DA 3EDE 5D15 F287 5408 9B8E C766 CD64 3A3F -------------------------------------------------------------------------- From haba@pdc.kth.se Wed Feb 27 11:03:16 2002 From: haba@pdc.kth.se (Harald Barth) Date: Wed, 27 Feb 2002 12:03:16 +0100 (CET) Subject: [OpenAFS-devel] How to know filesystems managed by AFS In-Reply-To: <200202271014.LAA21434@hs-eber02-01.Germany.Sun.COM> References: <200202271014.LAA21434@hs-eber02-01.Germany.Sun.COM> Message-ID: <20020227.120316.01023597.haba@pdc.kth.se> > I often get the problem to find out AFS managed > UFS filesystems, Common misinterpretation: It's not an UFS filesystem. It's AFS. > there is no info about the filesystems > AFS sits on top of in neither the crash dumps itself, > nor the /etc/mnttab or /etc/vfstab. Are you talking about kernel panic dumps? The afs kernel module keeps trace of the servers it's talking to. I guess that a crash dump from a crashed afs client is only useful in combination with the matching kernel module source. The information in the mnttab and vfstab are just to make programs happy who like to look at those files. The only valid information in there is the mountpoint (/afs) and the filesystem type (afs). > I'd really appreciate pointers to look at to > find out a AFS configuration in terms of > which AFS mountpoint/filesystem has which > underlying real FS mountpoint/filesystem. There is no direct relation between the /afs mountpoint and a underlying filesystem. Where to find its volumes and files is figured out by afs dynamically depending on the configuration in /usr/vice/{CellServDB,ThisCell} and the data afs requests from the fileservers and the volumeservers. The AFS filesystem is worldwide and replicated. To give you just a glimpse from my laptop: (fs is an AFS utility) $ fs where /afs/cs.cmu.edu File /afs/cs.cmu.edu is on hosts BLUEBERRY.SRV.CS.CMU.EDU PEACH.SRV.CS.CMU.EDU MANGO.SRV.CS.CMU.EDU BANANA.SRV.CS.CMU.EDU $ fs where /afs/e.kth.se File /afs/e.kth.se is on hosts elektrien.e.kth.se basalt.e.kth.se pyrit.e.kth.se $ fs where /afs/athena.mit.edu File /afs/athena.mit.edu is on hosts HYDRA.MIT.EDU SCYLLA.MIT.EDU CHARYBDIS.MIT.EDU AJAX.MIT.EDU A good starting point is http://www.openafs.org/. In the left lower corner you will find the AFSLore Wiki which is part of the effors to document things better than that they are now. Harald. From kejzlar@civ.zcu.cz Wed Feb 27 13:23:02 2002 From: kejzlar@civ.zcu.cz (Lubos Kejzlar) Date: Wed, 27 Feb 2002 14:23:02 +0100 (CET) Subject: [OpenAFS-devel] Re: [OpenAFS] Problem with large data transfer (WinNT AFS, please HELP!) In-Reply-To: Message-ID: Hi, On Wed, 27 Feb 2002, Shyh-Wei Luan wrote: > Have you tried xcopy? It may work better for your need. Explorer seems to > stubbornly want to scan the whole source sub-tree before starting to copy > the first file. My experiment with using it to copy a super large tree > never went beyond the "prepare copy" stage. We tried several methods to copy files (not sure about xcopy), including perl scripts and home-made executable (with copyfile() calls). Anyway, even with explorer we don't have troubles in 'prepare' phase (except some (significant) delay). We are able to start copying and transfer significant amount of data (>1GB) at every attempt. Than everything goes wrong during copy of small file (typically gif image) :-(( At this point (during timeout) there is high CPU usage (at client side) and AFS seems to be unavailable ('fs checks' from 'cmd' returns message like '... AFS service not running ...'). > Your AFS directory is not really publicly readable. I was only able to get > your cell root directory and got access denied at the platform directory. Sorry, my mistake :-( Should be fixed now (please try again, if you are able). Best regards, Lubos -------------------------------------------------------------------------- Lubos Kejzlar System and Network Specialist Laboratory for Computer Science Tel.: ++420-19-7491536 University of West Bohemia ++420-19-7421414 Univerzitni 8, 30614 Pilsen Fax: ++420-19-7421419 Czech Republic E-mail: kejzlar@civ.zcu.cz PGP Key fingerprint = 5621 06DA 3EDE 5D15 F287 5408 9B8E C766 CD64 3A3F -------------------------------------------------------------------------- From shadow@dementia.org Wed Feb 27 20:12:30 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 27 Feb 2002 15:12:30 -0500 (EST) Subject: [OpenAFS-devel] How to know filesystems managed by AFS In-Reply-To: <200202271014.LAA21434@hs-eber02-01.Germany.Sun.COM> Message-ID: On Wed, 27 Feb 2002, Frank Batschulat wrote: > Hi All, > > I often get the problem to find out AFS managed > UFS filesystems, there is no info about the filesystems > AFS sits on top of in neither the crash dumps itself, > nor the /etc/mnttab or /etc/vfstab. > > All that appears is the following entry in /etc/mnttab: > AFS /afs afs dev=100000 1011729826 > > df gives you: > /afs (AFS ):18000000 blocks 9000000 files > > I'd really appreciate pointers to look at to > find out a AFS configuration in terms of > which AFS mountpoint/filesystem has which > underlying real FS mountpoint/filesystem. Do you mean on what filesystem the disk cache lives, or something else? AFS is a network filesystem, generally, so just like NFS mounted filesystems, the actual data lives elsewhere; Unless you mean "where is the disk cache stored" I don't think this question makes sense. If you mean that, then I have no real suggestions. From eichin-oa@boxedpenguin.com Thu Feb 28 02:26:32 2002 From: eichin-oa@boxedpenguin.com (eichin-oa@boxedpenguin.com) Date: Wed, 27 Feb 2002 21:26:32 -0500 (EST) Subject: [OpenAFS-devel] [spelling] Thershold.LocalConstants Message-ID: <20020228022632.661D31429F@kuroneko> I just happened to see this typo go by while running ltrace on a server. Since this is a filename I can understand some reluctance to change it; however, the misspelling doesn't appear *anywhere* in the cvs tree, it is probably not documented, and a google search for Thershold LocalConstants finds a variety of web accessible AFS binaries, but no further instruction. Also, the AFSDIR_SERVER_THRESHOLD_CONSTANTS_FILEPATH macro doesn't appear to ever be referenced anyway. So, I'd suggest just fixing the typo (or putting in a comment explaining why it is even still present.) Index: dirpath.hin =================================================================== RCS file: /cvs/openafs/src/util/dirpath.hin,v retrieving revision 1.4 diff -u -w -r1.4 dirpath.hin --- dirpath.hin 2001/11/01 05:24:38 1.4 +++ dirpath.hin 2002/02/28 02:10:16 @@ -161,7 +161,7 @@ #define AFSDIR_LOCALRESIDENCY_FILE "LocalResidency" #define AFSDIR_WEIGHTINGCONST_FILE "Weight.LocalConstants" -#define AFSDIR_THRESHOLDCONST_FILE "Thershold.LocalConstants" +#define AFSDIR_THRESHOLDCONST_FILE "Threshold.LocalConstants" /* -------------- Canonical (wire-format) path macros -------------- */ From haba@pdc.kth.se Thu Feb 28 07:29:39 2002 From: haba@pdc.kth.se (Harald Barth) Date: Thu, 28 Feb 2002 08:29:39 +0100 (CET) Subject: [OpenAFS-devel] [spelling] Thershold.LocalConstants In-Reply-To: <20020228022632.661D31429F@kuroneko> References: <20020228022632.661D31429F@kuroneko> Message-ID: <20020228.082939.46310828.haba@pdc.kth.se> > Also, the > AFSDIR_SERVER_THRESHOLD_CONSTANTS_FILEPATH macro doesn't appear to > ever be referenced anyway. If noone is showing up and wants to use it, just delete the macro and the filename and all misspelling with it. Harald. From haba@pdc.kth.se Thu Feb 28 14:28:21 2002 From: haba@pdc.kth.se (Harald Barth) Date: Thu, 28 Feb 2002 15:28:21 +0100 (CET) Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 Message-ID: <20020228.152821.20908465.haba@pdc.kth.se> Ok, openafs 1.2.3 finally compiled on my AIX 4.3.3. My resulting volserver binary is however not able to create volumes and the fileserver can not attach old volumes either. The volserver/fileserver combination from the binary distribution seems to work. So something must be wrong with my build process. To find the error in my build, I'd like to know the build parameters of the distributed binary. Got a build tree in AFS? ;-) My configure is CC=xlc ./configure --with-afs-sysname=rs_aix42 --enable-transarc-paths with compiler/OS combination ibmcxx.cmp 3.6.6.4 COMMITTED IBM C and C++ Compilers bos.up 4.3.3.79 COMMITTED Base Operating System Any help appreciated Harald. From shadow@dementia.org Thu Feb 28 18:12:57 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 28 Feb 2002 13:12:57 -0500 (EST) Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 In-Reply-To: <20020228.152821.20908465.haba@pdc.kth.se> Message-ID: On Thu, 28 Feb 2002, Harald Barth wrote: > > Ok, openafs 1.2.3 finally compiled on my AIX 4.3.3. My resulting > volserver binary is however not able to create volumes and the > fileserver can not attach old volumes either. > > The volserver/fileserver combination from the binary distribution seems > to work. So something must be wrong with my build process. To find the > error in my build, I'd like to know the build parameters of the > distributed binary. Got a build tree in AFS? ;-) > > My configure is > > CC=xlc ./configure --with-afs-sysname=rs_aix42 --enable-transarc-paths > > with compiler/OS combination > > ibmcxx.cmp 3.6.6.4 COMMITTED IBM C and C++ Compilers > bos.up 4.3.3.79 COMMITTED Base Operating System > > Any help appreciated The binary builds didn't use xlc as a (non-kernel) compiler. I don't actually know how to find out what versions of those packages I have installed. I also don't specify the sysname myself, but let configure figure it out. (I use /usr/vac/bin/cc as a compiler) -D From thomas.mueller@hrz.tu-chemnitz.de Fri Feb 1 06:12:17 2002 From: thomas.mueller@hrz.tu-chemnitz.de (Thomas Mueller) Date: Fri, 1 Feb 2002 07:12:17 +0100 (MET) Subject: [OpenAFS-devel] callback handling problem In-Reply-To: <3C597D5E.352A8E5E@rzg.mpg.de> Message-ID: On Thu, 31 Jan 2002, Hartmut Reuter wrote: > > In older versions of callback.c was no "if ( !" around the call to > ClearHostCallbacks_r. Therefore the loop was left. I suppose we need a > line > > hp1 = hp; > Yes, I agree, this should break the loop. Thank you. I've installed the changed code on our fileservers. Thomas. -- ------------------------------------------------------------------------- Thomas Mueller, TU Chemnitz, Universitaetsrechenzentrum, D-09107 Chemnitz e-mail: Thomas.Mueller@hrz.tu-chemnitz.de ----------------------------------------------------------------------- From u85021@ice.ntnu.edu.tw Fri Feb 1 08:12:29 2002 From: u85021@ice.ntnu.edu.tw (=?big5?B?s6+kubh0?=) Date: Fri, 1 Feb 2002 16:12:29 +0800 Subject: [OpenAFS-devel] Can I fetch some appointed files whenerver I log in? Message-ID: <016201c1aaf8$31ad0b00$803e7a8c@yschengwin2k> This is a multi-part message in MIME format. ------=_NextPart_000_015F_01C1AB3B.3F6246F0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, falks: Can I fetch some appointed files whenever I log in AFS client? That is = when I log in some AFS client, I can fetch some appointed files to save = file transfer time. Just because the appointed files usually are used, = so I want to prefetch them when I log in to AFS client. When I want to = use these files, I can access them immediately without waiting. ------=_NextPart_000_015F_01C1AB3B.3F6246F0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable

Hi, falks:

------=_NextPart_000_015F_01C1AB3B.3F6246F0-- From balsa@vectra.startv.hu Fri Feb 1 09:42:36 2002 From: balsa@vectra.startv.hu (Balazs GAL) Date: 01 Feb 2002 10:42:36 +0100 Subject: [OpenAFS-devel] Re: [OpenAFS] pagsh and big uid with linux In-Reply-To: References: <1011104898.3697.0.camel@vpn65.ece.cmu.edu> <1012515929.28874.0.camel@balcsi> <1012518274.28930.2.camel@balcsi> <1012520304.28906.6.camel@balcsi> Message-ID: <1012556559.28930.10.camel@balcsi> 2002-02-01, F Derek Atkins wrote: Hi ! > In all my years of using AFS I have NEVER seen these be 'real' groups. The groups are in the /etc/group file before i call setpag(). I can read and write files. Only I can't unlink files. > Sure, you can shoot yourself in the foot by trying to force the issue, > but why? > > There is a saying in the US: A patient goes to the Doctor and says, > "Doctor, Doctor, it hurts when I do this." The Doctor responds, "Don't > do that." This was not only an ugly demo. I really have group id-s in this range. But this is only test: www:/etc# grep test8 /etc/group test8:x:44302: www:/etc# echo "This IS the big secret" > /etc/big_secret www:/etc# chown root:test8 /etc/big_secret www:/etc# chmod 660 /etc/big_secret www:/etc# ls -al /etc/big_secret -rw-rw---- 1 root test8 23 Feb 1 10:26 /etc/big_secret www:/etc# su balsa balsa@www:/etc$ id uid=60004(balsa) gid=100(users) ,100(users),102(doksi),1015(ftpssl),1022(tanszek) balsa@www:/etc$ pagsh balsa@www:/etc$ id uid=60004(balsa) gid=100(users) groups=33892,44302(test8),100(users),102(doksi),1015(ftpssl),1022(tanszek) balsa@www:/etc$ cat /etc/big_secret This IS the big secret balsa@www:/etc$ cat >> /etc/big_secret This WAS the big secret ^D balsa@www:/etc$ cat /etc/big_secret This IS the big secret This WAS the big secret balsa@www:/etc$ exit balsa@www:/etc$ exit www:/etc# ls -al /etc/big_secret -rw-rw---- 1 root test8 47 Feb 1 10:28 /etc/big_secret www:/etc# ls -al / total 100 drwxr-xr-x 20 root root 4096 Dec 4 19:09 . drwxr-xr-x 20 root root 4096 Dec 4 19:09 .. [...] drwxr-xr-x 57 root root 4096 Feb 1 10:26 etc [...] www:/etc# This is not a joke. I don't belive it that this is normal. balsa From openafs-info@openafs.org Fri Feb 1 15:18:41 2002 From: openafs-info@openafs.org (Derek Atkins) Date: 01 Feb 2002 10:18:41 -0500 Subject: [OpenAFS-devel] Re: [OpenAFS] pagsh and big uid with linux In-Reply-To: <1012556559.28930.10.camel@balcsi> References: <1011104898.3697.0.camel@vpn65.ece.cmu.edu> <1012515929.28874.0.camel@balcsi> <1012518274.28930.2.camel@balcsi> <1012520304.28906.6.camel@balcsi> <1012556559.28930.10.camel@balcsi> Message-ID: This is normal behavior for AFS. It has always done this. -derek PS: Why do you have so many groups? Perhaps if you move to AFS then you can move all your "groups" into AFS groups and then you can remove them from /etc/group? -derek Balazs GAL writes: > 2002-02-01, F Derek Atkins wrote: > > Hi ! > > > In all my years of using AFS I have NEVER seen these be 'real' groups. > > The groups are in the /etc/group file before i call > setpag(). > > I can read and write files. Only I can't unlink files. > > > Sure, you can shoot yourself in the foot by trying to force the issue, > > but why? > > > > There is a saying in the US: A patient goes to the Doctor and says, > > "Doctor, Doctor, it hurts when I do this." The Doctor responds, "Don't > > do that." > > This was not only an ugly demo. I really have group id-s in this range. > > But this is only test: > > www:/etc# grep test8 /etc/group > test8:x:44302: > www:/etc# echo "This IS the big secret" > /etc/big_secret > www:/etc# chown root:test8 /etc/big_secret > www:/etc# chmod 660 /etc/big_secret > www:/etc# ls -al /etc/big_secret > -rw-rw---- 1 root test8 23 Feb 1 10:26 /etc/big_secret > www:/etc# su balsa > balsa@www:/etc$ id > uid=60004(balsa) gid=100(users) > ,100(users),102(doksi),1015(ftpssl),1022(tanszek) > balsa@www:/etc$ pagsh > balsa@www:/etc$ id > uid=60004(balsa) gid=100(users) > groups=33892,44302(test8),100(users),102(doksi),1015(ftpssl),1022(tanszek) > balsa@www:/etc$ cat /etc/big_secret > This IS the big secret > balsa@www:/etc$ cat >> /etc/big_secret > This WAS the big secret > ^D > balsa@www:/etc$ cat /etc/big_secret > This IS the big secret > This WAS the big secret > balsa@www:/etc$ exit > balsa@www:/etc$ exit > www:/etc# ls -al /etc/big_secret > -rw-rw---- 1 root test8 47 Feb 1 10:28 /etc/big_secret > www:/etc# ls -al / > total 100 > drwxr-xr-x 20 root root 4096 Dec 4 19:09 . > drwxr-xr-x 20 root root 4096 Dec 4 19:09 .. > [...] > drwxr-xr-x 57 root root 4096 Feb 1 10:26 etc > [...] > www:/etc# > > > This is not a joke. > I don't belive it that this is normal. > > balsa > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From openafs-devel" References: <016201c1aaf8$31ad0b00$803e7a8c@yschengwin2k> Message-ID: AFS will not do this on its own. However, you can write your login scripts to try to pre-fetch the files. For example, cat /afs/cell/file/to/cache/1 > /dev/null & cat /afs/cell/file/to/cache/2 > /dev/null & cat /afs/cell/file/to/cache/3 > /dev/null & This will pull the file into the cache "in the background". I'm not sure why you want to do this, unless the connection between your client and server is REALLY SLOW (like 56k) or very high latency (like a satellite). I find that my login time (with my home directory in AFS) is based more on processor speed and machine memory than on AFS delays, until my network gets really slow. -derek =B3=AF=A4=B9=B8t writes: > Hi, falks: > Can I fetch some appointed files whenever I log in AFS client? That is wh= en I log in some AFS client, I can fetch some appointed files to save file = transfer time. Just because the appointed files usually are used, so I want= to prefetch them when I log in to AFS client. When I want to use these fil= es, I can access them immediately without waiting. >=20 --=20 Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nneul@umr.edu Fri Feb 1 15:58:24 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 09:58:24 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: (I've been doing alot of diagnosis attempting to improve our AFS cell, = that's why the stream of lots of these notes.) We just had a client start to experience continual 'waiting for busy = volume' messages against two volumes on a server that is not very = loaded. I've got a network trace of communications w/ that = client+server, and what's going on is the client is sending two = FetchStatus requests (one against each volume), and the server is = sending back a RX abort packet. Nothing but that over and over again. Any idea what could be causing this? In the fileserver logs, I'm not seeing anything specific to that client. We're going to be upgrading file servers to more recent code very = shortly, if there is any instrumentation y'all think it would be worth = adding before I do that, please speak up, cause now is the time I can = add it reasonably. (We're clearing servers then upgrading os and afs = install.) -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From kenh@cmf.nrl.navy.mil Fri Feb 1 16:08:29 2002 From: kenh@cmf.nrl.navy.mil (Ken Hornstein) Date: Fri, 01 Feb 2002 11:08:29 -0500 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state In-Reply-To: Your message of "Fri, 01 Feb 2002 09:58:24 CST." Message-ID: <200202011608.g11G8VG03414@ginger.cmf.nrl.navy.mil> >(I've been doing alot of diagnosis attempting to improve our AFS cell, that's >why the stream of lots of these notes.) > >We just had a client start to experience continual 'waiting for busy volume' >messages against two volumes on a server that is not very loaded. I've got >a network trace of communications w/ that client+server, and what's going on >is the client is sending two FetchStatus requests (one against each volume), >and the server is sending back a RX abort packet. Nothing but that over >and over again. What's the error code from the abort packet? That should tell you _something_. --Ken From nneul@umr.edu Fri Feb 1 16:15:14 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 10:15:14 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: Hmm... I must not be decoding the abort type packet completely. If the = error code is the 4-byte integer after the Service ID, then it is = 0x0000006E, or 110. I didn't see any mention of that in the rx_packet = structure though.=20 The trace is tiny if you want it.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 > Sent: Friday, February 01, 2002 10:08 AM > To: Neulinger, Nathan > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] RX abort packets, and client=20 > sitting in "waiting for busy volume" state=20 >=20 >=20 > >(I've been doing alot of diagnosis attempting to improve our=20 > AFS cell, that's > >why the stream of lots of these notes.) > > > >We just had a client start to experience continual 'waiting=20 > for busy volume' > >messages against two volumes on a server that is not very=20 > loaded. I've got > >a network trace of communications w/ that client+server, and=20 > what's going on > >is the client is sending two FetchStatus requests (one=20 > against each volume), > >and the server is sending back a RX abort packet. Nothing=20 > but that over > >and over again. >=20 > What's the error code from the abort packet? That should=20 > tell you _something_. >=20 > --Ken >=20 From nneul@umr.edu Fri Feb 1 16:38:34 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 10:38:34 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 > Sent: Friday, February 01, 2002 10:20 AM > To: Neulinger, Nathan > Subject: Re: [OpenAFS-devel] RX abort packets, and client=20 > sitting in "waiting for busy volume" state=20 >=20 >=20 > >Hmm... I must not be decoding the abort type packet completely. >=20 > That's what you get from using an "inferior" packet decoder :-) Change has been committed to CVS to correct that problem. > >If the error code is the 4-byte integer after the Service=20 > ID, then it is > >0x0000006E, or 110. I didn't see any mention of that in the rx_packet > >structure though.=20 >=20 > I think I figured that out from examining the code and/or the=20 > packet trace > (because I knew there was an error code in there somewhere). Yeah, looks to be in SendSpecial where the data is appended. For abort = packets, the data is the abort code. > I'm not sure what error code 110 on your system ... I think=20 > you're going > to have to grovel through your system's sys/errno.h, figure out what > that is, and what would make the fileserver ever return that. It's linux on a 2.2.x kernel on redhat62: infinity(50)>grep 110 /usr/include/asm/errno.h #define ETIMEDOUT 110 /* Connection timed out */ I'm not sure why fileserver would return that, but I'll take a look. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Fri Feb 1 18:13:11 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 12:13:11 -0600 Subject: [OpenAFS-devel] Changing RXDEADTIME... MUCH better failover for RO vols... Message-ID: Further testing with the killall -STOP fileserver/volserver stuff. = Changing RXDEADTIME to 10 seconds instead of 50 seconds made a huge = improvement in the failover time. I'm not sure what negative effects = this will have. It looks to take 2 * RXDEADTIME for it to detect server = failure, but that's just from rough looking at it. Anyone with history know the logic behind the current timing choices? I'd prefer to adjust for just RO volume access, but that will involve a = bit more than just a parameter change. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From kolya@MIT.EDU Fri Feb 1 20:49:42 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Fri, 01 Feb 2002 15:49:42 -0500 Subject: [OpenAFS-devel] Same problem in a different place. Message-ID: <200202012049.PAA29007@pepsi-one.mit.edu> > Actually, since afs_osi_Sleep() and CV_WAIT() are used so frequently, it > might be easier to make just make two new calls: > > int afs_osi_SleepHonorSig(char *event, int aintrok); > int CV_WAIT_HONORSIG(afs_kcondvar_t *cv, afs_kmutex_t *l, int aintrok) I've just commited code to CVS which does basically that. The two new sleep functions are: int afs_osi_SleepSig(char *event); int CV_WAIT_SIG(afs_kcondvar_t *cv, afs_kmutex_t *l); They return EINTR if interrupted by a signal, and 0 otherwise. They're actually implemented for Linux and Solaris, and are wrappers around the existing non-interruptable functions on all other platforms. I've also made afs_UFSRead() interruptible, at least in the case when the work is being done by a background daemon, just to make sure all this works. My one concern at this point is signal handlers with SA_RESTART: some limited testing on my 2.4.17 Linux box indicates that the system call isn't being restarted, and returns when the signal is delivered, rather than restarting. Do you happen to know how SA_RESTART is supposed to work inside the kernel? -- kolya From shadow@dementia.org Fri Feb 1 21:59:12 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 1 Feb 2002 16:59:12 -0500 (EST) Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state In-Reply-To: Message-ID: On Fri, 1 Feb 2002, Neulinger, Nathan wrote: > We just had a client start to experience continual 'waiting for busy volume' messages against two volumes on a server that is not very loaded. I've got a network trace of communications w/ that client+server, and what's going on is the client is sending two FetchStatus requests (one against each volume), and the server is sending back a RX abort packet. Nothing but that over and over again. > > Any idea what could be causing this? Depends; What version are you running on them? A bug which could cause that was fixed in (I think) 1.2.2 after Jimmy Engelbrecht complained about his Arla clients suffering from it; Clients were not being properly reaped by the fileserver. > We're going to be upgrading file servers to more recent code very > shortly, if there is any instrumentation y'all think it would be worth > adding before I do that, please speak up, cause now is the time I can > add it reasonably. (We're clearing servers then upgrading os and afs > install.) Why not try the upgrade first, then worry about instrumentation if you still have a problem? -D From nneul@umr.edu Fri Feb 1 22:07:13 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Fri, 1 Feb 2002 16:07:13 -0600 Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state Message-ID: Primarily cause I can't easily add the instrumentation afterwards = without a major hassle. Right now, it's convenient for me to take the server = down,=20 later it won't be. They should all be running relatively current code (within 3-5 months of = today) for the clients, but June'ish for the servers.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derrick J Brashear [mailto:shadow@dementia.org]=20 > Sent: Friday, February 01, 2002 3:59 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] RX abort packets, and client=20 > sitting in "waiting for busy volume" state >=20 >=20 > On Fri, 1 Feb 2002, Neulinger, Nathan wrote: >=20 > > We just had a client start to experience continual 'waiting=20 > for busy volume' messages against two volumes on a server=20 > that is not very loaded. I've got a network trace of=20 > communications w/ that client+server, and what's going on is=20 > the client is sending two FetchStatus requests (one against=20 > each volume), and the server is sending back a RX abort=20 > packet. Nothing but that over and over again. > >=20 > > Any idea what could be causing this? >=20 > Depends; What version are you running on them? A bug which could cause > that was fixed in (I think) 1.2.2 after Jimmy Engelbrecht=20 > complained about > his Arla clients suffering from it; Clients were not being=20 > properly reaped > by the fileserver. >=20 > > We're going to be upgrading file servers to more recent code very > > shortly, if there is any instrumentation y'all think it=20 > would be worth > > adding before I do that, please speak up, cause now is the=20 > time I can > > add it reasonably. (We're clearing servers then upgrading os and afs > > install.) >=20 > Why not try the upgrade first, then worry about instrumentation if you > still have a problem? >=20 > -D >=20 >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Fri Feb 1 22:13:25 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Fri, 1 Feb 2002 17:13:25 -0500 (EST) Subject: [OpenAFS-devel] RX abort packets, and client sitting in "waiting for busy volume" state In-Reply-To: Message-ID: On Fri, 1 Feb 2002, Neulinger, Nathan wrote: > Primarily cause I can't easily add the instrumentation afterwards without > a major hassle. Right now, it's convenient for me to take the server down, > later it won't be. > > They should all be running relatively current code (within 3-5 months of today) > for the clients, but June'ish for the servers. Well, this is a server-side fix, and since I remember working on it at the Arla hackathon I know it wasn't done in June:-) -D From nneul@umr.edu Tue Feb 5 16:54:53 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 5 Feb 2002 10:54:53 -0600 Subject: [OpenAFS-devel] What is BUGFIX_1165 Message-ID: There are a bunch of instances of code ifdef'd with ENABLE_BUGFIX_1165 = in volser/vsprocs.c. What is that about? If it isn't something that was decided to be = enabled, would it make sense to remove that code?=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Tue Feb 5 17:06:14 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 5 Feb 2002 11:06:14 -0600 Subject: [OpenAFS-devel] re-indenting code... Message-ID: At times, digging through some of the older code (ie. vsprocs.c), it is = very hard to read due to the veyr inconsistent (and sometimes completely = absent) indentation. I'd like to re-indent some of it, however I hate to make my local = checkout that different from the repository, cause it makes any = potential diffs that much less likely to be accepted. (i.e. it would be = easier to work on locally if it were re-indented, but I don't want to do = that if it means I have to hand-rewrite the diff to be suitable for = application.) Would developers be willing to come up with a indent config file that = would be an accepted re-indentation of the code? I don't think we'd = necessarily want to do that to everything, just to specific files as = they are worked on. I personally would like to see this: -cli4 -di0 -nbc -nlp -bad -sob -bap -bl0 -bli0 -cs -npcs -ncdb -nsc -ci0 -i4 -ip0 -npsl -ts4 but I'm sure others have different preferences. It doesn't really matter = much to me, but SOME sort of indentation would make things alot easier = to read than the current code. Derrick, would you accept a diff that did nothing other than reformat = certain files? Ideally, if there were a indent config file preference, it would be = checked into cvs somewhere, or as a helper script that passed all the = desired options.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Tue Feb 5 19:57:16 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 5 Feb 2002 13:57:16 -0600 Subject: [OpenAFS-devel] problems with vos move... Message-ID: I started digging into a problem we've had with vos move for a long = time... Occasionally on large (sometimes not) volumes, we get a failure = in the dump. I added a bunch more debugging to the verbose vos move, and = here is what I get: infinity(16)>/tmp/vos move res.kumar.students afs4 a afs8 a -verbose Locking VLDB entry for volume 536925133 ... done Starting transaction on source volume 536925133 ... done Allocating new volume id for clone of volume 536925133 ... done Cloning source volume 536925133 ... done Ending the transaction on the source volume 536925133 ... done Starting transaction on the cloned volume 537065258 ... done Setting flags on cloned volume 537065258 ... done Getting status of cloned volume 537065258 ... done Creating the destination volume 536925133 ... done Setting volume flags on destination volume 536925133 ... done Dumping from clone 537065258 on source to volume 536925133 on = destination ...Failed to move data for the volume 536925133 Possible communication failure vos move: operation interrupted, cleanup in progress... clear transaction contexts Recovery: Releasing VLDB lock on volume 536925133 ... done Recovery: Ending transaction on clone volume ... Note - There are two problems, first, the failure in the dump (Forward), = and second, that it is hanging when ending transaction on the cloned = volume.=20 Unfortunately, it looks like I will have to start watching the volserver = itself to see if I can determine the reason for the dump failure. Is it = possible that some sort of timeout is being exceeded some how?=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Wed Feb 6 15:30:41 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 6 Feb 2002 09:30:41 -0600 Subject: [OpenAFS-devel] scary vos remove message... Message-ID: This definately needs reworked: infinity(1)>vos remove afs8 c res.kumar.students -verbose res.kumar.students=20 RWrite: 536925133 Backup: 536925135=20 number of sites -> 1 server afs8.cc.umr.edu partition /vicepa RW Site=20 Trying to delete the volume 536925133 ... That is always scary even when you know it isn't saying what it looks = like it's saying.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Wed Feb 6 14:27:31 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Wed, 6 Feb 2002 08:27:31 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose Message-ID: <20020206142729.GA6654@umr.edu> --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Also removes the "WARNING" from "WARNING : removing backup volume on source", which really doesn't need to be a warning since it's completely expected, and you can't back out at that point any way. A vos move -verbose looks like this now: ------ infinity(3)>/tmp/vos move sw.tnsnames afs2 a afs2 b -verbose Locking VLDB entry for volume 536977586 ... done Starting transaction on source volume 536977586 ... done Allocating new volume id for clone of volume 536977586 ... done Cloning source volume 536977586 ... done Ending the transaction on the source volume 536977586 ... done Starting transaction on the cloned volume 537067336 ... done Setting flags on cloned volume 537067336 ... done Getting status of cloned volume 537067336 ... done Creating the destination volume 536977586 ... done Setting volume flags on destination volume 536977586 ... done Dumping from clone 537067336 on source to volume 536977586 on destination ... done Ending transaction on cloned volume 537067336 ... done Starting transaction on source volume 536977586 ... done Doing the incremental dump from source to destination for volume 536977586 ... done Setting volume flags on old source volume 536977586 ... done Setting volume flags on new source volume 536977586 ... done Ending transaction on destination volume 536977586 ... done Releasing lock on VLDB entry for volume 536977586 ... done Deleting old volume 536977586 on source ... done Ending transaction on old volume 536977586 on the source ... done Creating transaction for backup volume 536977588 on source ... done No backup volume exists on source. Ignoring. Starting transaction on the cloned volume 537067336 ... done Deleting the clone 537067336 ... done Ending transaction on clone volume 537067336 ... done WARNING : readOnly copies still exist Volume 536977586 moved from afs2 /vicepa to afs2 /vicepb ------ There are also more "what's happening" diagnostics during recovery and cleanup operations. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vos-move-more-diag.diff" Index: vsprocs.c =================================================================== RCS file: /cvs/openafs/src/volser/vsprocs.c,v retrieving revision 1.10 diff -u -r1.10 vsprocs.c --- vsprocs.c 2001/10/08 22:55:41 1.10 +++ vsprocs.c 2002/02/06 14:24:01 @@ -567,7 +567,7 @@ /* create the vldb entry */ vcode = VLDB_CreateEntry(&storeEntry); if(vcode) { - fprintf(STDERR,"Could not create a VLDB entry for the volume %s %u\n", aname,aid); + fprintf(STDERR,"Could not create a VLDB entry for the volume %s %u\n", aname,aid); error = vcode; goto cfail; } @@ -836,34 +836,38 @@ } #define ONERR(ec, es, ep) if (ec) { fprintf(STDERR, (es), (ep)); PrintError(" ",ec); error = (ec); goto mfail; } +#define VPRINT(es) if (verbose) { fprintf(STDOUT, (es)); fflush(STDOUT); } +#define VPRINT1(es, vol) if (verbose) { fprintf(STDOUT, (es), (vol)); fflush(STDOUT); } +#define VPRINT2(es, vol1, vol2) if (verbose) { fprintf(STDOUT, (es), (vol1), (vol2)); fflush(STDOUT); } +#define VDONE if (verbose) { fprintf(STDOUT, " done\n"); fflush(STDOUT); } /* Move volume on to * . The operation is almost idempotent */ UV_MoveVolume(afromvol, afromserver, afrompart, atoserver, atopart) - afs_int32 afromvol; - afs_int32 afromserver, atoserver; - afs_int32 afrompart, atopart; +afs_int32 afromvol; +afs_int32 afromserver, atoserver; +afs_int32 afrompart, atopart; { - struct rx_connection *toconn, *fromconn ; - afs_int32 fromtid, totid, clonetid; - char vname[64]; - char *volName = 0; - char tmpName[VOLSER_MAXVOLNAME +1]; - afs_int32 rcode; - afs_int32 fromDate; + struct rx_connection *toconn, *fromconn; + afs_int32 fromtid, totid, clonetid; + char vname[64]; + char *volName = 0; + char tmpName[VOLSER_MAXVOLNAME + 1]; + afs_int32 rcode; + afs_int32 fromDate; struct restoreCookie cookie; - register afs_int32 vcode, code; - afs_int32 newVol, volid, backupId; + register afs_int32 vcode, code; + afs_int32 newVol, volid, backupId; struct volser_status tstatus; - struct destServer destination; + struct destServer destination; - struct nvldbentry entry, storeEntry; - int i, islocked, pntg; - afs_int32 error; - char in,lf; /* for test code */ - int same; + struct nvldbentry entry, storeEntry; + int i, islocked, pntg; + afs_int32 error; + char in, lf; /* for test code */ + int same; #ifdef ENABLE_BUGFIX_1165 volEntries volumeInfo; @@ -871,211 +875,273 @@ #endif islocked = 0; - fromconn = (struct rx_connection *)0; - toconn = (struct rx_connection *)0; - fromtid = 0; - totid = 0; + fromconn = (struct rx_connection *) 0; + toconn = (struct rx_connection *) 0; + fromtid = 0; + totid = 0; clonetid = 0; - error = 0; - volid = 0; - pntg = 0; + error = 0; + volid = 0; + pntg = 0; backupId = 0; - newVol = 0; + newVol = 0; /* support control-c processing */ - if (setjmp(env)) goto mfail; - (void) signal(SIGINT,sigint_handler); - + if (setjmp(env)) + goto mfail; + (void) signal(SIGINT, sigint_handler); + if (TESTC) { fprintf(STDOUT, - "\nThere are three tests points - verifies all code paths through recovery.\n"); - fprintf(STDOUT,"First test point - operation not started.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ + "\nThere are three tests points - verifies all code paths through recovery.\n"); + fprintf(STDOUT, "First test point - operation not started.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ } vcode = VLDB_GetEntryByID(afromvol, -1, &entry); - ONERR (vcode, "Could not fetch the entry for the volume %u from the VLDB \n", afromvol); + ONERR(vcode, + "Could not fetch the entry for the volume %u from the VLDB \n", + afromvol); if (entry.volumeId[RWVOL] != afromvol) { - fprintf(STDERR,"Only RW volume can be moved\n"); - exit(1); + fprintf(STDERR, "Only RW volume can be moved\n"); + exit(1); } - vcode = ubik_Call(VL_SetLock, cstruct, 0,afromvol, RWVOL, VLOP_MOVE); - ONERR (vcode, "Could not lock entry for volume %u \n", afromvol); + VPRINT1("Locking VLDB entry for volume %u ...", afromvol); + vcode = ubik_Call(VL_SetLock, cstruct, 0, afromvol, RWVOL, VLOP_MOVE); + ONERR(vcode, "Could not lock entry for volume %u\n", afromvol); + VDONE; islocked = 1; - vcode = VLDB_GetEntryByID (afromvol, RWVOL, &entry); - ONERR (vcode, "Could not fetch the entry for the volume %u from the VLDB \n", afromvol); + vcode = VLDB_GetEntryByID(afromvol, RWVOL, &entry); + ONERR(vcode, + "Could not fetch the entry for the volume %u from the VLDB\n", + afromvol); backupId = entry.volumeId[BACKVOL]; MapHostToNetwork(&entry); - if ( !Lp_Match(afromserver, afrompart, &entry) ) + if (!Lp_Match(afromserver, afrompart, &entry)) { - /* the from server and partition do not exist in the vldb entry corresponding to volid */ - if ( !Lp_Match(atoserver, atopart, &entry) ) - { - /* the to server and partition do not exist in the vldb entry corresponding to volid */ - fprintf(STDERR,"The volume %u is not on the specified site. \n", afromvol); - fprintf(STDERR,"The current site is :"); - for (i=0; i - * we have already done the move, but the volume - * may still be existing physically on from fileserver - */ - fromconn = UV_Bind(afromserver, AFSCONF_VOLUMEPORT); - fromtid = 0; - pntg = 1; - - code = AFSVolTransCreate(fromconn, afromvol, afrompart, ITOffline, &fromtid); - if (!code) - { /* volume exists - delete it */ - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); - ONERR (code, "Failed to set flags on the volume %u\n", afromvol); - - code = AFSVolDeleteVolume(fromconn,fromtid); - ONERR (code, "Failed to delete the volume %u\n", afromvol); - - code = AFSVolEndTrans(fromconn, fromtid, &rcode); - fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Could not end the transaction for the volume %u \n", afromvol); - } - - /*delete the backup volume now */ - fromtid = 0; - code = AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, &fromtid); - if (!code) - { /* backup volume exists - delete it */ - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); - ONERR (code, "Failed to set flags on the backup volume %u\n", backupId); - - code = AFSVolDeleteVolume(fromconn,fromtid); - ONERR (code, "Could not delete the backup volume %u\n", backupId); - - code = AFSVolEndTrans(fromconn, fromtid, &rcode); - fromtid = 0; - if (!code) code = rcode; - ONERR (code,"Could not end the transaction for the backup volume %u \n",backupId); - } - - fromtid = 0; - error = 0; - goto mfail; + /* the from server and partition do not exist in the vldb entry corresponding to volid */ + if (!Lp_Match(atoserver, atopart, &entry)) + { + /* the to server and partition do not exist in the vldb entry corresponding to volid */ + fprintf(STDERR, "The volume %u is not on the specified site. \n", + afromvol); + fprintf(STDERR, "The current site is :"); + for (i = 0; i < entry.nServers; i++) + { + if (entry.serverFlags[i] == ITSRWVOL) + { + char pname[10]; + + MapPartIdIntoName(entry.serverPartition[i], pname); + fprintf(STDERR, " server %s partition %s \n", + hostutil_GetNameByINet(entry.serverNumber[i]), pname); + } + } + VPRINT1("Releasing lock on VLDB entry for volume %u ...", + afromvol); + vcode = + ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + ONERR(vcode, + " Could not release lock on the VLDB entry for the volume %u \n", + afromvol); + VDONE; + + return VOLSERVOLMOVED; + } + + /* delete the volume afromvol on src_server */ + /* from-info does not exist but to-info does => + * we have already done the move, but the volume + * may still be existing physically on from fileserver + */ + fromconn = UV_Bind(afromserver, AFSCONF_VOLUMEPORT); + fromtid = 0; + pntg = 1; + + code = + AFSVolTransCreate(fromconn, afromvol, afrompart, ITOffline, + &fromtid); + if (!code) + { /* volume already moved - delete from source */ + VPRINT1("Setting flags on leftover source volume %u ...", + afromvol); + code = + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + ONERR(code, + "Failed to set flags on the leftover source volume %u\n", + afromvol); + VDONE; + + VPRINT1("Deleting leftover source volume %u ...", afromvol); + code = AFSVolDeleteVolume(fromconn, fromtid); + ONERR(code, "Failed to delete the leftover source volume %u\n", + afromvol); + VDONE; + + VPRINT1("Ending transaction on leftover source volume %u ...", + afromvol); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + fromtid = 0; + if (!code) + code = rcode; + ONERR(code, + "Could not end the transaction for the leftover source volume %u \n", + afromvol); + VDONE; + } + + /*delete the backup volume now */ + fromtid = 0; + code = + AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, + &fromtid); + if (!code) + { /* backup volume exists - delete it */ + VPRINT1("Setting flags on leftover backup volume %u ...", + backupId); + code = + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + ONERR(code, + "Failed to set flags on the leftover backup volume %u\n", + backupId); + VDONE; + + VPRINT1("Deleting backup volume %u ...", backupId); + code = AFSVolDeleteVolume(fromconn, fromtid); + ONERR(code, "Could not delete the leftover backup volume %u\n", + backupId); + VDONE; + + VPRINT1("Ending transaction on leftover backup volume %u ...", + backupId); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + fromtid = 0; + if (!code) + code = rcode; + ONERR(code, + "Could not end the transaction for the leftover backup volume %u \n", + backupId); + VDONE; + } + + fromtid = 0; + error = 0; + goto mfail; } /* From-info matches the vldb info about volid, * its ok start the move operation, the backup volume * on the old site is deleted in the process */ - if (afrompart == atopart) + if (afrompart == atopart) { - same = VLDB_IsSameAddrs (afromserver, atoserver, &error); - if (error) - { - fprintf(STDERR, "Failed to get info about server's %d address(es) from vlserver (err=%d); aborting call!\n", - afromserver, error); - goto mfail; - } - if (same) ONERR (VOLSERVOLMOVED, - "Warning: Moving volume %u to its home partition ignored!\n", afromvol); + same = VLDB_IsSameAddrs(afromserver, atoserver, &error); + if (error) + { + fprintf(STDERR, + "Failed to get info about server's %d address(es) from vlserver (err=%d); aborting call!\n", + afromserver, error); + goto mfail; + } + if (same) + ONERR(VOLSERVOLMOVED, + "Warning: Moving volume %u to its home partition ignored!\n", + afromvol); } pntg = 1; - toconn = UV_Bind(atoserver, AFSCONF_VOLUMEPORT); /* get connections to the servers */ + toconn = UV_Bind(atoserver, AFSCONF_VOLUMEPORT); /* get connections to the servers */ fromconn = UV_Bind(afromserver, AFSCONF_VOLUMEPORT); - fromtid = totid = 0; /* initialize to uncreated */ + fromtid = totid = 0; /* initialize to uncreated */ /* *** * clone the read/write volume locally. * ***/ - if (verbose) fprintf(STDOUT,"Starting transaction on source volume %u ...",afromvol); + VPRINT1("Starting transaction on source volume %u ...", afromvol); fflush(STDOUT); code = AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, &fromtid); - ONERR (code, "Failed to create transaction on the volume %u\n", afromvol); - if (verbose) fprintf(STDOUT," done\n"); + ONERR(code, "Failed to create transaction on the volume %u\n", afromvol); + VDONE; /* Get a clone id */ + VPRINT1("Allocating new volume id for clone of volume %u ...", afromvol); newVol = 0; - vcode = ubik_Call (VL_GetNewVolumeId, cstruct, 0, 1, &newVol); - ONERR (vcode, "Could not get an ID for the clone of volume %u from the VLDB\n", afromvol); + vcode = ubik_Call(VL_GetNewVolumeId, cstruct, 0, 1, &newVol); + ONERR(vcode, + "Could not get an ID for the clone of volume %u from the VLDB\n", + afromvol); + VDONE; /* Do the clone. Default flags on clone are set to delete on salvage and out of service */ - if (verbose) fprintf (STDOUT,"Cloning source volume %u ...", afromvol); - fflush(STDOUT); - strcpy(vname, "move-clone-temp"); - code = AFSVolClone(fromconn, fromtid, 0,readonlyVolume, vname, &newVol); - ONERR (code, "Failed to clone the source volume %u\n", afromvol); - if (verbose) fprintf(STDOUT," done\n"); + VPRINT1("Cloning source volume %u ...", afromvol); + strcpy(vname, "move-clone-temp"); /* why the strcpy? is that name special cased on server? */ + code = AFSVolClone(fromconn, fromtid, 0, readonlyVolume, vname, &newVol); + ONERR(code, "Failed to clone the source volume %u\n", afromvol); + VDONE; /* lookup the name of the volume we just cloned */ volid = afromvol; code = AFSVolGetName(fromconn, fromtid, &volName); - ONERR (code, "Failed to get the name of the volume %u\n", newVol); + ONERR(code, "Failed to get the name of the volume %u\n", newVol); - if (verbose) fprintf (STDOUT,"Ending the transaction on the source volume %u ...", afromvol); - fflush(STDOUT); + VPRINT1("Ending the transaction on the source volume %u ...", afromvol); rcode = 0; code = AFSVolEndTrans(fromconn, fromtid, &rcode); fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the source volume %u\n", afromvol); - if (verbose) fprintf (STDOUT," done\n"); + if (!code) + code = rcode; + ONERR(code, "Failed to end the transaction on the source volume %u\n", + afromvol); + VDONE; /* *** * Create the destination volume * ***/ - - if (verbose) fprintf(STDOUT, "Starting transaction on the cloned volume %u ...", newVol); - fflush(STDOUT); - code = AFSVolTransCreate (fromconn, newVol, afrompart, ITOffline, &clonetid); - ONERR (code, "Failed to start a transaction on the cloned volume%u\n", newVol); - if (verbose) fprintf(STDOUT," done\n"); - code = AFSVolSetFlags (fromconn, clonetid, VTDeleteOnSalvage|VTOutOfService); /*redundant */ - ONERR (code, "Could not set falgs on the cloned volume %u\n", newVol); + VPRINT1("Starting transaction on the cloned volume %u ...", newVol); + code = + AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, &clonetid); + ONERR(code, "Failed to start a transaction on the cloned volume%u\n", + newVol); + VDONE; + + VPRINT1("Setting flags on cloned volume %u ...", newVol); + code = AFSVolSetFlags(fromconn, clonetid, VTDeleteOnSalvage | VTOutOfService); /*redundant */ + ONERR(code, "Could not set flags on the cloned volume %u\n", newVol); + VDONE; /* remember time from which we've dumped the volume */ - code = AFSVolGetStatus (fromconn, clonetid, &tstatus); - ONERR (code, "Failed to get the status of the cloned volume %u\n", newVol); + VPRINT1("Getting status of cloned volume %u ...", newVol); + code = AFSVolGetStatus(fromconn, clonetid, &tstatus); + ONERR(code, "Failed to get the status of the cloned volume %u\n", newVol); + VDONE; - fromDate = tstatus.creationDate-CLOCKSKEW; + fromDate = tstatus.creationDate - CLOCKSKEW; #ifdef ENABLE_BUGFIX_1165 /* @@ -1083,54 +1149,65 @@ * to copy it to the new volume (via AFSSetInfo later on) so that when we move volumes we * don't use this information... */ - volumeInfo.volEntries_val = (volintInfo *)0;/*this hints the stub to allocate space*/ + volumeInfo.volEntries_val = (volintInfo *) 0; /*this hints the stub to allocate space */ volumeInfo.volEntries_len = 0; code = AFSVolListOneVolume(fromconn, afrompart, afromvol, &volumeInfo); - ONERR (code, "Failed to get the volint Info of the cloned volume %u\n", afromvol); + ONERR(code, "Failed to get the volint Info of the cloned volume %u\n", + afromvol); infop = (volintInfo *) volumeInfo.volEntries_val; - infop->maxquota = -1; /* Else it will replace the default quota */ + infop->maxquota = -1; /* Else it will replace the default quota */ #endif /* create a volume on the target machine */ volid = afromvol; - code = AFSVolTransCreate (toconn, volid, atopart, ITOffline, &totid); - if (!code) - { - /* Delete the existing volume. - * While we are deleting the volume in these steps, the transaction - * we started against the cloned volume (clonetid above) will be - * sitting idle. It will get cleaned up after 600 seconds - */ - if (verbose) fprintf(STDOUT,"Deleting pre-existing volume %u on destination ...",volid); - fflush(STDOUT); - - code = AFSVolDeleteVolume(toconn, totid); - ONERR (code, "Could not delete the pre-existing volume %u on destination\n", volid); - - code = AFSVolEndTrans(toconn, totid, &rcode); - totid = 0; - if (!code) code = rcode; - ONERR (code, "Could not end the transaction on pre-existing volume %u on destination\n", - volid); - - if (verbose) fprintf(STDOUT," done\n"); - } - - if (verbose) fprintf(STDOUT,"Creating the destination volume %u ...",volid); - fflush(STDOUT); - code = AFSVolCreateVolume (toconn, atopart, volName, volser_RW, volid, &volid, &totid); - ONERR (code, "Failed to create the destination volume %u\n", volid); - if (verbose) fprintf(STDOUT," done\n"); + code = AFSVolTransCreate(toconn, volid, atopart, ITOffline, &totid); + if (!code) + { + /* Delete the existing volume. + * While we are deleting the volume in these steps, the transaction + * we started against the cloned volume (clonetid above) will be + * sitting idle. It will get cleaned up after 600 seconds + */ + VPRINT1("Deleting pre-existing volume %u on destination ...", volid); + code = AFSVolDeleteVolume(toconn, totid); + ONERR(code, + "Could not delete the pre-existing volume %u on destination\n", + volid); + VDONE; + + VPRINT1 + ("Ending transaction on pre-existing volume %u on destination ...", + volid); + code = AFSVolEndTrans(toconn, totid, &rcode); + totid = 0; + if (!code) + code = rcode; + ONERR(code, + "Could not end the transaction on pre-existing volume %u on destination\n", + volid); + VDONE; + } + + VPRINT1("Creating the destination volume %u ...", volid); + code = + AFSVolCreateVolume(toconn, atopart, volName, volser_RW, volid, &volid, + &totid); + ONERR(code, "Failed to create the destination volume %u\n", volid); + VDONE; strncpy(tmpName, volName, VOLSER_OLDMAXVOLNAME); free(volName); volName = (char *) 0; - code = AFSVolSetFlags (toconn, totid, (VTDeleteOnSalvage | VTOutOfService)); - ONERR(code, "Failed to set the flags on the destination volume %u\n", volid); + VPRINT1("Setting volume flags on destination volume %u ...", volid); + code = + AFSVolSetFlags(toconn, totid, (VTDeleteOnSalvage | VTOutOfService)); + ONERR(code, "Failed to set the flags on the destination volume %u\n", + volid); + VDONE; - /*** + /*** * Now dump the clone to the new volume ***/ @@ -1139,110 +1216,135 @@ destination.destSSID = 1; /* Copy the clone to the new volume */ - if (verbose) fprintf(STDOUT, "Dumping from clone %u on source to volume %u on destination ...", - newVol, afromvol); - fflush(STDOUT); - strncpy(cookie.name,tmpName,VOLSER_OLDMAXVOLNAME); - cookie.type = RWVOL; + VPRINT2("Dumping from clone %u on source to volume %u on destination ...", + newVol, afromvol); + strncpy(cookie.name, tmpName, VOLSER_OLDMAXVOLNAME); + cookie.type = RWVOL; cookie.parent = entry.volumeId[RWVOL]; - cookie.clone = 0; + cookie.clone = 0; code = AFSVolForward(fromconn, clonetid, 0, &destination, totid, &cookie); - ONERR (code, "Failed to move data for the volume %u\n", volid); - if (verbose) fprintf(STDOUT," done\n"); + ONERR(code, "Failed to move data for the volume %u\n", volid); + VDONE; + VPRINT1("Ending transaction on cloned volume %u ...", newVol); code = AFSVolEndTrans(fromconn, clonetid, &rcode); - if (!code) code = rcode; + if (!code) + code = rcode; clonetid = 0; - ONERR (code, "Failed to end the transaction on the cloned volume %u\n", newVol); + ONERR(code, "Failed to end the transaction on the cloned volume %u\n", + newVol); + VDONE; /* *** * reattach to the main-line volume, and incrementally dump it. * ***/ - if (verbose) - fprintf(STDOUT,"Doing the incremental dump from source to destination for volume %u ... ", - afromvol); - fflush(STDOUT); - + VPRINT1("Starting transaction on source volume %u ...", afromvol); code = AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, &fromtid); - ONERR (code, "Failed to create a transaction on the source volume %u\n", afromvol); + ONERR(code, "Failed to create a transaction on the source volume %u\n", + afromvol); + VDONE; /* now do the incremental */ - code = AFSVolForward(fromconn, fromtid, fromDate, &destination, totid,&cookie); - ONERR (code, "Failed to do the incremental dump from rw volume on old site to rw volume on newsite\n", 0); - if (verbose)fprintf(STDOUT," done\n"); + VPRINT1 + ("Doing the incremental dump from source to destination for volume %u ... ", + afromvol); + code = + AFSVolForward(fromconn, fromtid, fromDate, &destination, totid, + &cookie); + ONERR(code, + "Failed to do the incremental dump from rw volume on old site to rw volume on newsite\n", + 0); + VDONE; /* now adjust the flags so that the new volume becomes official */ + VPRINT1("Setting volume flags on old source volume %u ...", afromvol); code = AFSVolSetFlags(fromconn, fromtid, VTOutOfService); - ONERR (code, "Failed to set the flags to make old source volume offline\n", 0); + ONERR(code, "Failed to set the flags to make old source volume offline\n", + 0); + VDONE; + VPRINT1("Setting volume flags on new source volume %u ...", afromvol); code = AFSVolSetFlags(toconn, totid, 0); - ONERR (code, "Failed to set the flags to make new source volume online\n", 0); + ONERR(code, "Failed to set the flags to make new source volume online\n", + 0); + VDONE; #ifdef ENABLE_BUGFIX_1165 code = AFSVolSetInfo(toconn, totid, infop); - ONERR (code, "Failed to set volume status on the destination volume %u\n", volid); + ONERR(code, "Failed to set volume status on the destination volume %u\n", + volid); #endif /* put new volume online */ + VPRINT1("Ending transaction on destination volume %u ...", afromvol); code = AFSVolEndTrans(toconn, totid, &rcode); totid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the volume %u on the new site\n", afromvol); + if (!code) + code = rcode; + ONERR(code, + "Failed to end the transaction on the volume %u on the new site\n", + afromvol); + VDONE; Lp_SetRWValue(&entry, afromserver, afrompart, atoserver, atopart); - MapNetworkToHost(&entry,&storeEntry); + MapNetworkToHost(&entry, &storeEntry); storeEntry.flags &= ~BACK_EXISTS; if (TESTC) { - fprintf(STDOUT, "Second test point - operation in progress but not complete.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ - } - - vcode = VLDB_ReplaceEntry (afromvol, -1, &storeEntry, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); - if (vcode) + fprintf(STDOUT, + "Second test point - operation in progress but not complete.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ + } + + VPRINT1("Releasing lock on VLDB entry for volume %u ...", afromvol); + vcode = VLDB_ReplaceEntry(afromvol, -1, &storeEntry, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + if (vcode) { - fprintf(STDERR," Could not release the lock on the VLDB entry for the volume %s %u \n", - storeEntry.name,afromvol); - error = vcode; - goto mfail; + fprintf(STDERR, + " Could not release the lock on the VLDB entry for the volume %s %u \n", + storeEntry.name, afromvol); + error = vcode; + goto mfail; } - islocked=0; + VDONE; + islocked = 0; if (TESTC) { - fprintf(STDOUT, "Third test point - operation complete but no cleanup.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ + fprintf(STDOUT, + "Third test point - operation complete but no cleanup.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ } #ifdef notdef @@ -1252,189 +1354,257 @@ * we're cleaning this code up in DEcorum, we're just going to kludge around * it for now by removing this call. */ /* already out of service, just zap it now */ - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); + code = + AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); if (code) { - fprintf(STDERR,"Failed to set the flags to make the old source volume offline\n"); - goto mfail; + fprintf(STDERR, + "Failed to set the flags to make the old source volume offline\n"); + goto mfail; } #endif - if (atoserver != afromserver) + if (atoserver != afromserver) { /* set forwarding pointer for moved volumes */ + VPRINT1("Setting forwarding pointer for volume %u ...", afromvol); code = AFSVolSetForwarding(fromconn, fromtid, atoserver); - ONERR (code, "Failed to set the forwarding pointer for the volume %u\n", afromvol); + ONERR(code, + "Failed to set the forwarding pointer for the volume %u\n", + afromvol); + VDONE; } - if (verbose) fprintf(STDOUT,"Deleting old volume %u on source ...", afromvol); - fflush(STDOUT); + VPRINT1("Deleting old volume %u on source ...", afromvol); + code = AFSVolDeleteVolume(fromconn, fromtid); /* zap original volume */ + ONERR(code, "Failed to delete the old volume %u on source\n", afromvol); + VDONE; - code = AFSVolDeleteVolume(fromconn,fromtid); /* zap original volume */ - ONERR (code, "Failed to delete the old volume %u on source\n", afromvol); - + VPRINT1("Ending transaction on old volume %u on the source ...", + afromvol); code = AFSVolEndTrans(fromconn, fromtid, &rcode); fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the old volume %u on the source\n", afromvol); - - if (verbose) fprintf(STDOUT," done\n"); + if (!code) + code = rcode; + ONERR(code, + "Failed to end the transaction on the old volume %u on the source\n", + afromvol); + VDONE; /* Delete the backup volume on the original site */ - code = AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, &fromtid); - if (!code) - { - fprintf(STDOUT, "WARNING : Deleting the backup volume %u on the source ...",backupId); - fflush(STDOUT); - - code = AFSVolSetFlags(fromconn, fromtid, VTDeleteOnSalvage | VTOutOfService); - ONERR (code, "Failed to set the flags on the backup volume on source\n", 0); - - code = AFSVolDeleteVolume(fromconn,fromtid); - ONERR (code, "Failed to delete the backup volume on source\n", 0); - - code = AFSVolEndTrans(fromconn,fromtid, &rcode); - fromtid = 0; - if (!code) code = rcode; - ONERR (code, "Failed to end the transaction on the backup volume %u on source\n", 0); + VPRINT1("Creating transaction for backup volume %u on source ...", + backupId); + code = + AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, &fromtid); + VDONE; - fprintf(STDOUT," done\n"); + if (!code) /* if backup volume exists, otherwise code will be zero */ + { + VPRINT1("Setting flags on backup volume %u on source ...", backupId); + code = + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + ONERR(code, + "Failed to set the flags on the backup volume on source\n", 0); + VDONE; + + VPRINT1("Deleting the backup volume %u on the source ...", backupId); + fflush(STDOUT); + code = AFSVolDeleteVolume(fromconn, fromtid); + ONERR(code, "Failed to delete the backup volume on source\n", 0); + VDONE; + + VPRINT1("Ending transaction on backup volume %u on source ...", + backupId); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + fromtid = 0; + if (!code) + code = rcode; + ONERR(code, + "Failed to end the transaction on the backup volume %u on source\n", + 0); + VDONE; + } + else + { + VPRINT("No backup volume exists on source. Ignoring.\n"); } - else code = 0; /* no backup volume? that's okay */ + VPRINT1("Starting transaction on the cloned volume %u ...", newVol); fromtid = 0; - if (verbose) fprintf(STDOUT,"Starting transaction on the cloned volume %u ...",newVol); - fflush(STDOUT); - - code = AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, &clonetid); - ONERR (code, "Failed to start a transaction on the cloned volume%u\n", newVol); + code = + AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, &clonetid); + ONERR(code, "Failed to start a transaction on the cloned volume%u\n", + newVol); + VDONE; - if (verbose) fprintf(STDOUT," done\n"); - /* now delete the clone */ - if (verbose) fprintf(STDOUT,"Deleting the clone %u ...", newVol); - fflush(STDOUT); - + VPRINT1("Deleting the clone %u ...", newVol); code = AFSVolDeleteVolume(fromconn, clonetid); - ONERR (code, "Failed to delete the cloned volume %u\n", newVol); - - if (verbose) fprintf(STDOUT," done\n"); + ONERR(code, "Failed to delete the cloned volume %u\n", newVol); + VDONE; + VPRINT1("Ending transaction on clone volume %u ...", newVol); code = AFSVolEndTrans(fromconn, clonetid, &rcode); - if (!code) code = rcode; + if (!code) + code = rcode; clonetid = 0; - ONERR (code, "Failed to end the transaction on the cloned volume %u\n", newVol); + ONERR(code, "Failed to end the transaction on the cloned volume %u\n", + newVol); + VDONE; /* fall through */ /* END OF MOVE */ if (TESTC) { - fprintf(STDOUT,"Fourth test point - operation complete.\n"); - fprintf(STDOUT,"...test here (y, n)? "); - fflush(STDOUT); - fscanf(stdin,"%c",&in); - fscanf(stdin,"%c",&lf); /* toss away */ - if (in=='y') - { - fprintf(STDOUT,"type control-c\n"); - while(1) - { - fprintf(stdout,"."); - fflush(stdout); - sleep(1); - } - } - /* or drop through */ + fprintf(STDOUT, "Fourth test point - operation complete.\n"); + fprintf(STDOUT, "...test here (y, n)? "); + fflush(STDOUT); + fscanf(stdin, "%c", &in); + fscanf(stdin, "%c", &lf); /* toss away */ + if (in == 'y') + { + fprintf(STDOUT, "type control-c\n"); + while (1) + { + fprintf(stdout, "."); + fflush(stdout); + sleep(1); + } + } + /* or drop through */ } /* normal cleanup code */ - if (entry.flags & RO_EXISTS) fprintf(STDERR,"WARNING : readOnly copies still exist \n"); + if (entry.flags & RO_EXISTS) + fprintf(STDERR, "WARNING : readOnly copies still exist \n"); if (islocked) { - vcode = ubik_Call(VL_ReleaseLock,cstruct, 0, afromvol, -1, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); - if (vcode) - { - fprintf(STDERR," Could not release the lock on the VLDB entry for the volume %u \n", - afromvol); - if (!error) error = vcode; - } + VPRINT1("Cleanup: Releasing VLDB lock on volume %u ...", afromvol); + vcode = ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + if (vcode) + { + fprintf(STDERR, + " Could not release the lock on the VLDB entry for the volume %u \n", + afromvol); + if (!error) + error = vcode; + } + VDONE; } - - if (fromtid) + + if (fromtid) { - code = AFSVolEndTrans(fromconn, fromtid, &rcode); - if (code || rcode) - { - fprintf(STDERR,"Could not end transaction on the source's clone volume %u\n", newVol); - if (!error) error = (code ? code : rcode); - } + VPRINT1("Cleanup: Ending transaction on source volume %u ...", + afromvol); + code = AFSVolEndTrans(fromconn, fromtid, &rcode); + if (code || rcode) + { + fprintf(STDERR, + "Could not end transaction on source volume %u\n", afromvol); + if (!error) + error = (code ? code : rcode); + } + VDONE; } - if (clonetid) + if (clonetid) { - code = AFSVolEndTrans(fromconn, clonetid, &rcode); - if (code || rcode) - { - fprintf(STDERR,"Could not end transaction on the source's clone volume %u\n",newVol); - if (!error) error = (code ? code : rcode); - } + VPRINT1("Cleanup: Ending transaction on clone volume %u ...", newVol); + code = AFSVolEndTrans(fromconn, clonetid, &rcode); + if (code || rcode) + { + fprintf(STDERR, + "Could not end transaction on clone volume %u\n", newVol); + if (!error) + error = (code ? code : rcode); + } + VDONE; } - if (totid) + if (totid) { - code = AFSVolEndTrans(toconn, totid, &rcode); - if (code) - { - fprintf(STDERR,"Could not end transaction on destination volume %u\n",afromvol); - if (!error) error = (code ? code : rcode); - } + VPRINT1("Cleanup: Ending transaction on destination volume %u ...", + afromvol); + code = AFSVolEndTrans(toconn, totid, &rcode); + if (code) + { + fprintf(STDERR, + "Could not end transaction on destination volume %u\n", + afromvol); + if (!error) + error = (code ? code : rcode); + } + VDONE; } - if (volName) free(volName); + if (volName) + free(volName); #ifdef ENABLE_BUGFIX_1165 - if (infop) free(infop); + if (infop) + free(infop); #endif - if (fromconn) rx_DestroyConnection(fromconn); - if (toconn) rx_DestroyConnection(toconn); - PrintError("",error); + if (fromconn) + rx_DestroyConnection(fromconn); + if (toconn) + rx_DestroyConnection(toconn); + PrintError("", error); return error; /* come here only when the sky falls */ -mfail: + mfail: - if (pntg) + if (pntg) { - fprintf(STDOUT,"vos move: operation interrupted, cleanup in progress...\n"); - fprintf(STDOUT,"clear transaction contexts\n"); - fflush(STDOUT); + fprintf(STDOUT, + "vos move: operation interrupted, cleanup in progress...\n"); + fprintf(STDOUT, "clear transaction contexts\n"); + fflush(STDOUT); } /* unlock VLDB entry */ if (islocked) + { + VPRINT1("Recovery: Releasing VLDB lock on volume %u ...", afromvol); ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + VDONE; + } - if (clonetid) AFSVolEndTrans(fromconn, clonetid, &rcode); - if (totid) AFSVolEndTrans(toconn, totid, &rcode); - if (fromtid) - { /* put it on-line */ - AFSVolSetFlags(fromconn,fromtid,0); - AFSVolEndTrans(fromconn, fromtid, &rcode); + if (clonetid) + { + VPRINT("Recovery: Ending transaction on clone volume ..."); + AFSVolEndTrans(fromconn, clonetid, &rcode); + VDONE; } - if (verbose) - { /* get current VLDB entry */ - fprintf(STDOUT,"access VLDB\n"); - fflush(STDOUT); + if (totid) + { + VPRINT("Recovery: Ending transaction on destination volume ..."); + AFSVolEndTrans(toconn, totid, &rcode); + VDONE; } - vcode= VLDB_GetEntryByID (afromvol, -1, &entry); + + if (fromtid) + { /* put it on-line */ + VPRINT("Recovery: Setting volume flags on source volume ..."); + AFSVolSetFlags(fromconn, fromtid, 0); + VDONE; + + VPRINT("Recovery: Ending transaction on source volume ..."); + AFSVolEndTrans(fromconn, fromtid, &rcode); + VDONE; + } + + VPRINT("Recovery: Accessing VLDB.\n"); + vcode = VLDB_GetEntryByID(afromvol, -1, &entry); if (vcode) { - fprintf(STDOUT,"FATAL: VLDB access error: abort cleanup\n"); - fflush(STDOUT); - goto done; + fprintf(STDOUT, "FATAL: VLDB access error: abort cleanup\n"); + fflush(STDOUT); + goto done; } MapHostToNetwork(&entry); @@ -1443,86 +1613,201 @@ * volume move didn't finish so we remove the volume from the target * location. Otherwise, we remove the volume from the source location. */ - if (Lp_Match(afromserver,afrompart,&entry)) { /* didn't move - delete target volume */ - if (pntg) { - fprintf(STDOUT, - "move incomplete - attempt cleanup of target partition - no guarantee\n"); - fflush(STDOUT); - } - - if (volid && toconn) { - code=AFSVolTransCreate(toconn,volid,atopart, ITOffline,&totid); - if (!code) { - AFSVolSetFlags(toconn,totid, VTDeleteOnSalvage | VTOutOfService); - AFSVolDeleteVolume(toconn,totid); - AFSVolEndTrans(toconn,totid,&rcode); - } - } - - /* put source volume on-line */ - if (fromconn) { - code=AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, &fromtid); - if (!code) { - AFSVolSetFlags(fromconn,fromtid,0); - AFSVolEndTrans(fromconn,fromtid,&rcode); - } - } + if (Lp_Match(afromserver, afrompart, &entry)) + { /* didn't move - delete target volume */ + if (pntg) + { + fprintf(STDOUT, + "move incomplete - attempt cleanup of target partition - no guarantee\n"); + fflush(STDOUT); + } + + if (volid && toconn) + { + VPRINT1 + ("Recovery: Creating transaction for destination volume %u ...", + volid); + code = + AFSVolTransCreate(toconn, volid, atopart, ITOffline, &totid); + VDONE; + if (!code) + { + VPRINT1 + ("Recovery: Setting flags on destination volume %u ...", + volid); + AFSVolSetFlags(toconn, totid, + VTDeleteOnSalvage | VTOutOfService); + VDONE; + + VPRINT1("Recovery: Deleting destination volume %u ...", + volid); + AFSVolDeleteVolume(toconn, totid); + VDONE; + + VPRINT1 + ("Recovery: Ending transaction on destination volume %u ...", + volid); + AFSVolEndTrans(toconn, totid, &rcode); + VDONE; + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + volid); + } + } + + /* put source volume on-line */ + if (fromconn) + { + VPRINT1("Recovery: Creating transaction on source volume %u ...", + afromvol); + code = + AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, + &fromtid); + VDONE; + + if (!code) + { + VPRINT1("Recovery: Setting flags on source volume %u ...", + afromvol); + AFSVolSetFlags(fromconn, fromtid, 0); + VDONE; + + VPRINT1 + ("Recovery: Ending transaction on source volume %u ...", + afromvol); + AFSVolEndTrans(fromconn, fromtid, &rcode); + VDONE; + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + afromvol); + } + } + } + else + { /* yep, move complete */ + if (pntg) + { + fprintf(STDOUT, + "move complete - attempt cleanup of source partition - no guarantee\n"); + fflush(STDOUT); + } + + /* delete backup volume */ + if (fromconn) + { + VPRINT1("Recovery: Creating transaction on backup volume %u ...", + backupId); + code = + AFSVolTransCreate(fromconn, backupId, afrompart, ITOffline, + &fromtid); + VDONE; + if (!code) + { + VPRINT1("Recovery: Setting flags on backup volume %u ...", backupId); + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + VDONE; + + VPRINT1("Recovery: Deleting backup volume %u ...", backupId); + AFSVolDeleteVolume(fromconn, fromtid); + VDONE; + + VPRINT1("Recovery: Ending transaction on backup volume %u ...", backupId); + AFSVolEndTrans(fromconn, fromtid, &rcode); + VDONE; + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + backupId); + } + + /* delete source volume */ + VPRINT1("Recovery: Creating transaction on source volume %u ...", + afromvol); + code = + AFSVolTransCreate(fromconn, afromvol, afrompart, ITBusy, + &fromtid); + VDONE; + if (!code) + { + AFSVolSetFlags(fromconn, fromtid, + VTDeleteOnSalvage | VTOutOfService); + if (atoserver != afromserver) + AFSVolSetForwarding(fromconn, fromtid, atoserver); + AFSVolDeleteVolume(fromconn, fromtid); + AFSVolEndTrans(fromconn, fromtid, &rcode); + } + else + { + VPRINT1 + ("Recovery: Unable to start transaction on volume %u.\n", + afromvol); + } + } } - else { /* yep, move complete */ - if (pntg) { - fprintf(STDOUT, - "move complete - attempt cleanup of source partition - no guarantee\n"); - fflush(STDOUT); - } - - /* delete backup volume */ - if (fromconn) { - code=AFSVolTransCreate (fromconn,backupId,afrompart, ITOffline,&fromtid); - if (!code) { - AFSVolSetFlags(fromconn,fromtid, VTDeleteOnSalvage | VTOutOfService); - AFSVolDeleteVolume(fromconn,fromtid); - AFSVolEndTrans(fromconn,fromtid,&rcode); - } - - /* delete source volume */ - code=AFSVolTransCreate (fromconn, afromvol, afrompart, ITBusy, &fromtid); - if (!code) { - AFSVolSetFlags(fromconn,fromtid, VTDeleteOnSalvage | VTOutOfService); - if (atoserver != afromserver) - AFSVolSetForwarding(fromconn,fromtid,atoserver); - AFSVolDeleteVolume(fromconn,fromtid); - AFSVolEndTrans(fromconn,fromtid,&rcode); - } - } - } /* common cleanup - delete local clone */ - if (newVol) { - code = AFSVolTransCreate (fromconn, newVol, afrompart, ITOffline, &clonetid); - if (!code) { - AFSVolDeleteVolume(fromconn,clonetid); - AFSVolEndTrans(fromconn,clonetid,&rcode); - } + if (newVol) + { + VPRINT1("Recovery: Creating transaction on clone volume %u ...", + newVol); + code = + AFSVolTransCreate(fromconn, newVol, afrompart, ITOffline, + &clonetid); + VDONE; + if (!code) + { + VPRINT1("Recovery: Deleting clone volume %u ...", newVol); + AFSVolDeleteVolume(fromconn, clonetid); + VDONE; + + VPRINT1("Recovery: Ending transaction on clone volume %u ...", + newVol); + AFSVolEndTrans(fromconn, clonetid, &rcode); + VDONE; + } + else + { + VPRINT1("Recovery: Unable to start transaction on volume %u.\n", + newVol); + } } /* unlock VLDB entry */ - ubik_Call (VL_ReleaseLock, cstruct, 0, afromvol, -1, - (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); - -done: /* routine cleanup */ - if (volName) free(volName); + VPRINT1("Recovery: Releasing lock on VLDB entry for volume %u ...", + afromvol); + ubik_Call(VL_ReleaseLock, cstruct, 0, afromvol, -1, + (LOCKREL_OPCODE | LOCKREL_AFSID | LOCKREL_TIMESTAMP)); + VDONE; + + done: /* routine cleanup */ + if (volName) + free(volName); #ifdef ENABLE_BUGFIX_1165 - if (infop) free(infop); + if (infop) + free(infop); #endif - if (fromconn) rx_DestroyConnection(fromconn); - if (toconn) rx_DestroyConnection(toconn); + if (fromconn) + rx_DestroyConnection(fromconn); + if (toconn) + rx_DestroyConnection(toconn); - if (pntg) { - fprintf(STDOUT,"cleanup complete - user verify desired result\n"); - fflush(STDOUT); + if (pntg) + { + fprintf(STDOUT, "cleanup complete - user verify desired result\n"); + fflush(STDOUT); } exit(1); } + /* Make a new backup of volume on and * if one already exists, update it --ikeVEW9yuYc//A+q-- From jhutz@cmu.edu Wed Feb 6 17:12:10 2002 From: jhutz@cmu.edu (Jeffrey Hutzelman) Date: Wed, 6 Feb 2002 12:12:10 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: <20020206142729.GA6654@umr.edu> Message-ID: On Wed, 6 Feb 2002, Nathan Neulinger wrote: > Also removes the "WARNING" from "WARNING : removing backup volume on > source", which really doesn't need to be a warning since it's > completely expected, and you can't back out at that point any way. Please don't go around making gratuitous changes to messages. There are people and programs which depend on the output format of various AFS commands, and changing that format can break them. So make sure you have a _good_ reason before you change something like that. From rra@stanford.edu Wed Feb 6 18:26:17 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed, 06 Feb 2002 10:26:17 -0800 Subject: [OpenAFS-devel] scary vos remove message... In-Reply-To: ("Neulinger, Nathan"'s message of "Wed, 6 Feb 2002 09:30:41 -0600") References: Message-ID: Neulinger, Nathan writes: > This definately needs reworked: > infinity(1)>vos remove afs8 c res.kumar.students -verbose > res.kumar.students > RWrite: 536925133 Backup: 536925135 > number of sites -> 1 > server afs8.cc.umr.edu partition /vicepa RW Site > Trying to delete the volume 536925133 ... > That is always scary even when you know it isn't saying what it looks > like it's saying. I don't understand. You told it to remove a volume and it says that it's trying to remove the volume. What's scary about that? It's going to fail in a second since you gave it the wrong partition.... -- Russ Allbery (rra@stanford.edu) From rra@stanford.edu Wed Feb 6 18:28:25 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed, 06 Feb 2002 10:28:25 -0800 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 6 Feb 2002 12:12:10 -0500 (EST)") References: Message-ID: Jeffrey Hutzelman writes: > On Wed, 6 Feb 2002, Nathan Neulinger wrote: >> Also removes the "WARNING" from "WARNING : removing backup volume on >> source", which really doesn't need to be a warning since it's >> completely expected, and you can't back out at that point any way. > Please don't go around making gratuitous changes to messages. There are > people and programs which depend on the output format of various AFS > commands, and changing that format can break them. So make sure you > have a _good_ reason before you change something like that. With all due respect to the people concerned with that sort of thing, I think it's pretty unreasonable to never change the output of any command to make it more user-friendly because people are doing things that they should never have had to do in the first place. We badly need a programmatic interface to AFS operations, and then at that point I (even being one of the people with scripts with that issue) think people should feel free to change the output of the commands all they want. Some of the output badly needs to be fixed, and I don't want to see the user interface and user-friendliness be stalled by old, evil hacks that we all wrote back in the days when there was no better alternative. -- Russ Allbery (rra@stanford.edu) From nneul@umr.edu Wed Feb 6 18:35:39 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 6 Feb 2002 12:35:39 -0600 Subject: [OpenAFS-devel] scary vos remove message... Message-ID: No... actually, it's not... I was cleaning up after a failed volume move, so there was a stray copy of that volume in the other location.=20 The scary part is that it looks from the message like it is going to delete the volume listed - even though I told it to delete something else. (It actually is deleting the other one, it just looks like it's going to delete the volume on a, not c) -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Russ Allbery [mailto:rra@stanford.edu]=20 > Sent: Wednesday, February 06, 2002 12:26 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] scary vos remove message... >=20 >=20 > Neulinger, Nathan writes: >=20 > > This definately needs reworked: >=20 > > infinity(1)>vos remove afs8 c res.kumar.students -verbose >=20 > > res.kumar.students=20 > > RWrite: 536925133 Backup: 536925135=20 > > number of sites -> 1 > > server afs8.cc.umr.edu partition /vicepa RW Site=20 > > Trying to delete the volume 536925133 ... >=20 > > That is always scary even when you know it isn't saying=20 > what it looks > > like it's saying. >=20 > I don't understand. You told it to remove a volume and it=20 > says that it's > trying to remove the volume. What's scary about that? It's=20 > going to fail > in a second since you gave it the wrong partition.... >=20 > --=20 > Russ Allbery (rra@stanford.edu) =20 > >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Wed Feb 6 20:14:27 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 6 Feb 2002 15:14:27 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: Message-ID: On Wed, 6 Feb 2002, Russ Allbery wrote: > > Please don't go around making gratuitous changes to messages. There are > > people and programs which depend on the output format of various AFS > > commands, and changing that format can break them. So make sure you > > have a _good_ reason before you change something like that. > > With all due respect to the people concerned with that sort of thing, I > think it's pretty unreasonable to never change the output of any command > to make it more user-friendly because people are doing things that they > should never have had to do in the first place. At minimum, though, not in a minor version update to the code. 1.2.3->1.2.4 should not be expected to break your scripts. From shadow@dementia.org Wed Feb 6 20:18:40 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 6 Feb 2002 15:18:40 -0500 (EST) Subject: meta Re: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: Message-ID: if you reply, please prune openafs-bugs from your reply; a new ticket is opened for every reply which doesn't contain e.g. [grand.central.org #817] in the subject. -D From Craig_Everhart@transarc.com Wed Feb 6 18:37:11 2002 From: Craig_Everhart@transarc.com (Craig_Everhart@transarc.com) Date: Wed, 6 Feb 2002 13:37:11 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: References: Message-ID: <8wMLTLU99g8801KfA0@transarc.com> Actually, what worries me about the patch is how many gratuitous diffs it contains, presumably "cleaning up" indentation, spacing, and the like. While the short-term results may look OK, it means that all kinds of patches down the line will keep seeing these gratuitous differences. Worse, if someone "cleans up" in some other way, still more gratuitous differences will abound, obfuscating real (functional) changes. The OpenAFS code may not be beautiful, but efforts to re-indent and so forth need to be coordinated a lot better than this to circumvent merge grief in the future. Regards, Craig From nneul@umr.edu Wed Feb 6 21:16:08 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 6 Feb 2002 15:16:08 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose Message-ID: Actually, since the diagnostic msg output touches about every other line in the routine, it's kindof pointless not to reindent at the same time. (Not re-indenting that subroutine when I did the changes would shrink the size of the diff by maybe 10-15% at most.)=20 Yes, I'd prefer that the reindenting be done projectwide independently, but if a patch is going to be submitted that changed so much of a subroutine, it really is pointless to delay unless someone objects to the different formatting.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Craig_Everhart@transarc.com=20 > [mailto:Craig_Everhart@transarc.com]=20 > Sent: Wednesday, February 06, 2002 12:37 PM > To: openafs-bugs@openafs.org; openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Patch to add much more=20 > diagnostics to vos move when run with -verbose >=20 >=20 > Actually, what worries me about the patch is how many gratuitous diffs > it contains, presumably "cleaning up" indentation, spacing, and the > like. While the short-term results may look OK, it means=20 > that all kinds > of patches down the line will keep seeing these gratuitous=20 > differences.=20 > Worse, if someone "cleans up" in some other way, still more gratuitous > differences will abound, obfuscating real (functional) changes. >=20 > The OpenAFS code may not be beautiful, but efforts to re-indent and so > forth need to be coordinated a lot better than this to=20 > circumvent merge > grief in the future. >=20 > Regards, > Craig >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From rra@stanford.edu Thu Feb 7 01:48:12 2002 From: rra@stanford.edu (Russ Allbery) Date: Wed, 06 Feb 2002 17:48:12 -0800 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos move when run with -verbose In-Reply-To: (Derrick J Brashear's message of "Wed, 6 Feb 2002 15:14:27 -0500 (EST)") References: Message-ID: Derrick J Brashear writes: > On Wed, 6 Feb 2002, Russ Allbery wrote: >> With all due respect to the people concerned with that sort of thing, I >> think it's pretty unreasonable to never change the output of any >> command to make it more user-friendly because people are doing things >> that they should never have had to do in the first place. > At minimum, though, not in a minor version update to the code. > 1.2.3->1.2.4 should not be expected to break your scripts. Oh, definitely agreed. Those are the kind of patches to save up and do all at once during a major version change. -- Russ Allbery (rra@stanford.edu) From nneul@umr.edu Thu Feb 7 13:54:08 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 7 Feb 2002 07:54:08 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose Message-ID: Seems reasonable to me... It would be nice though to get some re-indentation/re-formatting patches applies, if for no other reason than to ease maintaining of the other patches until they can be applied. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Russ Allbery [mailto:rra@stanford.edu]=20 > Sent: Wednesday, February 06, 2002 7:48 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Patch to add much more=20 > diagnostics to vos movewhen run with -verbose >=20 >=20 > Derrick J Brashear writes: > > On Wed, 6 Feb 2002, Russ Allbery wrote: >=20 > >> With all due respect to the people concerned with that=20 > sort of thing, I > >> think it's pretty unreasonable to never change the output of any > >> command to make it more user-friendly because people are=20 > doing things > >> that they should never have had to do in the first place. >=20 > > At minimum, though, not in a minor version update to the code. > > 1.2.3->1.2.4 should not be expected to break your scripts. >=20 > Oh, definitely agreed. Those are the kind of patches to save=20 > up and do > all at once during a major version change. >=20 > --=20 > Russ Allbery (rra@stanford.edu) =20 > >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From nneul@umr.edu Thu Feb 7 13:59:21 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 7 Feb 2002 07:59:21 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose Message-ID: On a side note... it would be really nice if there was an easy way to keep track of all the various patches out there, even if they have no intention of being applied to the mainline project. This is in regards to Craig's comment about patches impacting other patches. I'm not sure that we should _not_ apply something if it impacts someone else's patch, but having a central repository would be an easy way to at least see if it is likely to impact someone else. Even if the repository only held information on what files a particular patch touched in the case of patches that can't be released, such as the MR-AFS stuff.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Neulinger, Nathan=20 > Sent: Thursday, February 07, 2002 7:54 AM > To: Russ Allbery; openafs-devel@openafs.org > Subject: RE: [OpenAFS-devel] Patch to add much more=20 > diagnostics to vos movewhen run with -verbose >=20 >=20 > Seems reasonable to me... It would be nice though to get some > re-indentation/re-formatting patches applies, if for no other reason > than to ease maintaining of the other patches until they can=20 > be applied. >=20 >=20 > -- Nathan >=20 > ------------------------------------------------------------ > Nathan Neulinger EMail: nneul@umr.edu > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 >=20 >=20 > > -----Original Message----- > > From: Russ Allbery [mailto:rra@stanford.edu]=20 > > Sent: Wednesday, February 06, 2002 7:48 PM > > To: openafs-devel@openafs.org > > Subject: Re: [OpenAFS-devel] Patch to add much more=20 > > diagnostics to vos movewhen run with -verbose > >=20 > >=20 > > Derrick J Brashear writes: > > > On Wed, 6 Feb 2002, Russ Allbery wrote: > >=20 > > >> With all due respect to the people concerned with that=20 > > sort of thing, I > > >> think it's pretty unreasonable to never change the output of any > > >> command to make it more user-friendly because people are=20 > > doing things > > >> that they should never have had to do in the first place. > >=20 > > > At minimum, though, not in a minor version update to the code. > > > 1.2.3->1.2.4 should not be expected to break your scripts. > >=20 > > Oh, definitely agreed. Those are the kind of patches to save=20 > > up and do > > all at once during a major version change. > >=20 > > --=20 > > Russ Allbery (rra@stanford.edu) =20 > > > >=20 > > _______________________________________________ > > OpenAFS-devel mailing list > > OpenAFS-devel@openafs.org > > https://lists.openafs.org/mailman/listinfo/openafs-devel > >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Thu Feb 7 15:59:44 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 7 Feb 2002 10:59:44 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: Message-ID: On Thu, 7 Feb 2002, Neulinger, Nathan wrote: > Seems reasonable to me... It would be nice though to get some > re-indentation/re-formatting patches applies, if for no other reason > than to ease maintaining of the other patches until they can be applied. It's another thing that belongs in a major version, and it should be done by script, not by submission of patches to the whole source, anyhow. From ota@transarc.com Thu Feb 7 16:22:21 2002 From: ota@transarc.com (Ted Anderson) Date: Thu, 7 Feb 2002 11:22:21 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: References: Message-ID: While it may not be the perfect solution, the TWiki does allow uploading/attaching files. (I haven't tried this yet though). So that might be a reasonable place to lodge patches that aren't going into the main branch for whatever reason (like maybe they are Transarc AFS patches (i.e. afs-contrib like stuff). Ted Anderson From adam@fsf.net Thu Feb 7 22:33:47 2002 From: adam@fsf.net (Adam Thornton) Date: Thu, 7 Feb 2002 16:33:47 -0600 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... Message-ID: <20020207163347.X314@dev-linux.fsf.net> Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) system. I've built and installed K5 (I'm using it as a client). After much futzing around I can make it compile. But then when I try to run aklog, I get: ./aklog: error while loading shared libraries: /usr/local/lib/libkrb5.so.3: undefined symbol: stat Which, as far as it goes, is reasonable. libkrb5 certainly doesn't provide stat. But, uh, who does? What do I need to link against to get stat to resolve? I don't remember seeing anything like this when building on S/390. Adam From warlord@MIT.EDU Thu Feb 7 22:50:05 2002 From: warlord@MIT.EDU (Derek Atkins) Date: 07 Feb 2002 17:50:05 -0500 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207163347.X314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> Message-ID: Did you try just building it from the SRPM? There is a patch to the afs-krb5-1.3 system, but the results worked fine in all my tests. Um, wait, why is it linking against /usr/local/lib/libkrb5.so.3? Don't you have the krb5 that comes with SuSE? -derek Adam Thornton writes: > Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) system. I've > built and installed K5 (I'm using it as a client). > > After much futzing around I can make it compile. But then when I try to > run aklog, I get: > > ./aklog: error while loading shared libraries: > /usr/local/lib/libkrb5.so.3: undefined symbol: stat > > Which, as far as it goes, is reasonable. libkrb5 certainly doesn't > provide stat. But, uh, who does? What do I need to link against to get > stat to resolve? I don't remember seeing anything like this when > building on S/390. > > Adam > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From adam@fsf.net Thu Feb 7 23:12:02 2002 From: adam@fsf.net (Adam Thornton) Date: Thu, 7 Feb 2002 17:12:02 -0600 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207163347.X314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> Message-ID: <20020207171202.A314@dev-linux.fsf.net> On Thu, Feb 07, 2002 at 04:33:47PM -0600, Adam Thornton wrote: > Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) system. I've > built and installed K5 (I'm using it as a client). > > After much futzing around I can make it compile. But then when I try to > run aklog, I get: > > ./aklog: error while loading shared libraries: > /usr/local/lib/libkrb5.so.3: undefined symbol: stat Hmmm. Actually it looks like it can't find stat in afsd because afsd died. That makes some sense. Now I need to figure out why afsd segfaulted. Adam From warlord@MIT.EDU Thu Feb 7 23:17:54 2002 From: warlord@MIT.EDU (Derek Atkins) Date: 07 Feb 2002 18:17:54 -0500 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207171202.A314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> <20020207171202.A314@dev-linux.fsf.net> Message-ID: Adam Thornton writes: > > ./aklog: error while loading shared libraries: > > /usr/local/lib/libkrb5.so.3: undefined symbol: stat > > Hmmm. Actually it looks like it can't find stat in afsd because afsd > died. Huh? Doesn't make sense to me. WHat does afsd have to do with stat? Note that 'stat' should be in libc. > That makes some sense. Now I need to figure out why afsd segfaulted. What version of AFS and what Linux Kernel are you using? > Adam -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From shadow@dementia.org Thu Feb 7 23:56:30 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 7 Feb 2002 18:56:30 -0500 (EST) Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: Message-ID: On 7 Feb 2002, Derek Atkins wrote: > Adam Thornton writes: > > > > ./aklog: error while loading shared libraries: > > > /usr/local/lib/libkrb5.so.3: undefined symbol: stat > > > > Hmmm. Actually it looks like it can't find stat in afsd because afsd > > died. > > Huh? Doesn't make sense to me. WHat does afsd have to do with > stat? Note that 'stat' should be in libc. I'm with Derek, and I had this problem a while ago (RH 5.2/sparc, I think) stat was versioned and i think /lib/libc.so was a loader script, and somehow i was trying to link against one of the underlying objects. Which libc do you have? From hartmans@mekinok.com Fri Feb 8 02:05:05 2002 From: hartmans@mekinok.com (Sam Hartman) Date: 07 Feb 2002 21:05:05 -0500 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: References: Message-ID: >>>>> "Ted" == Ted Anderson writes: Ted> While it may not be the perfect solution, the TWiki does Ted> allow uploading/attaching files. (I haven't tried this yet Ted> though). So that might be a reasonable place to lodge Ted> patches that aren't going into the main branch for whatever Ted> reason (like maybe they are Transarc AFS patches Ted> (i.e. afs-contrib like stuff). Why can't patches like this go onto the mainline and just not get pulled to the release branch? From hartmans@mekinok.com Fri Feb 8 02:08:07 2002 From: hartmans@mekinok.com (Sam Hartman) Date: 07 Feb 2002 21:08:07 -0500 Subject: [OpenAFS-devel] Bizarre linker error with afs-krb5 1.3.... In-Reply-To: <20020207163347.X314@dev-linux.fsf.net> References: <20020207163347.X314@dev-linux.fsf.net> Message-ID: >>>>> "Adam" == Adam Thornton writes: Adam> Now I'm trying to build afs-krb5 on a SuSE 7.3 Pro (x86) Adam> system. I've built and installed K5 (I'm using it as a Adam> client). Adam> After much futzing around I can make it compile. But then Adam> when I try to run aklog, I get: Adam> ./aklog: error while loading shared libraries: Adam> /usr/local/lib/libkrb5.so.3: undefined symbol: stat Adam> Which, as far as it goes, is reasonable. libkrb5 certainly Adam> doesn't provide stat. But, uh, who does? What do I need to Adam> link against to get stat to resolve? I don't remember Adam> seeing anything like this when building on S/390. You built krb5 incorrectly. I think the quick fix is to build both with -D_REENTRANT and to build with optimization. I believe 1.2.3 fixes this. From nneul@umr.edu Fri Feb 8 04:36:28 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Thu, 07 Feb 2002 22:36:28 -0600 Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose References: Message-ID: <3C6355CC.E0E010F@umr.edu> Sam Hartman wrote: > > >>>>> "Ted" == Ted Anderson writes: > > Ted> While it may not be the perfect solution, the TWiki does > Ted> allow uploading/attaching files. (I haven't tried this yet > Ted> though). So that might be a reasonable place to lodge > Ted> patches that aren't going into the main branch for whatever > Ted> reason (like maybe they are Transarc AFS patches > Ted> (i.e. afs-contrib like stuff). > > Why can't patches like this go onto the mainline and just not get pulled to the release branch? There may be some that people want to publish, but aren't appropriate for the mainline either. MR-AFS is the one that always pops into mind... It's not widely released, yet it's still actively used. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From ota@transarc.com Fri Feb 8 13:23:10 2002 From: ota@transarc.com (Ted Anderson) Date: Fri, 8 Feb 2002 08:23:10 -0500 (EST) Subject: [OpenAFS-devel] Patch to add much more diagnostics to vos movewhen run with -verbose In-Reply-To: References: Message-ID: <8wMx4yg99g1Q0QzU40@transarc.com> On 07 Feb 2002 21:05:05 -0500 Sam Hartman wrote: > Ted> ... TWiki does allow uploading/attaching files. So that > Ted> might be a reasonable place to lodge patches that aren't > Ted> going into the main branch for whatever reason > > Why can't patches like this go onto the mainline and just not get > pulled to the release branch? I don't really know much about CVS. But is it really suitable for managing patches or deltas that just linger on the sidelines for an exteneded period of time? Generally patches are a problem to maintain and keep up to date. But on the otherhand it is also painful to haul a whole bunch of stuff into the main code base that is enabled only with special compilation options. There clearly isn't an ideal solution. It makes sense for possibly peripheral features to start life as a patch used and maintained by a few advocates. As the feature matures and gains adherents adding it to the mainline makes more sense. A repository where patches can live during this maturation phase seems like it might help this process. Ted From reuter@rzg.mpg.de Fri Feb 8 15:21:15 2002 From: reuter@rzg.mpg.de (Hartmut Reuter) Date: Fri, 08 Feb 2002 16:21:15 +0100 Subject: [OpenAFS-devel] patch for afs_vnop_remove.c Message-ID: <3C63ECEB.C6EB66B0@rzg.mpg.de> Hi, this caused some oopses: obviously tdc can here be zero! --- /opt/openafs/src/afs/VNOPS/afs_vnop_remove.c Wed Nov 21 17:01:31 2001+++ ./afs_vnop_remove.c Fri Feb 8 14:29:09 2002 @@ -417,7 +417,7 @@ if (adp) { tdc = afs_FindDCache(adp, 0); ObtainWriteLock(&adp->lock, 159); - ObtainSharedLock(&tdc->lock, 639); + if (tdc) ObtainSharedLock(&tdc->lock, 639); /* afsremove releases the adp & tdc locks, and does vn_rele(avc) */ code = afsremove(adp, tdc, avc, unlname, cred, &treq); ----------------------------------------------------------------- Hartmut Reuter e-mail reuter@rzg.mpg.de phone +49-89-3299-1328 RZG (Rechenzentrum Garching) fax +49-89-3299-1301 Computing Center of the Max-Planck-Gesellschaft (MPG) and the Institut fuer Plasmaphysik (IPP) ----------------------------------------------------------------- From haba@pdc.kth.se Fri Feb 8 15:23:39 2002 From: haba@pdc.kth.se (Harald Barth) Date: Fri, 08 Feb 2002 16:23:39 +0100 (CET) Subject: [OpenAFS-devel] 1.2.3 compile barfs on AIX 4.3.3 In-Reply-To: <8wMx4yg99g1Q0QzU40@transarc.com> References: <8wMx4yg99g1Q0QzU40@transarc.com> Message-ID: <20020208.162339.103611991.haba@stacken.kth.se> On AIX 4.3.3.0 OpenAFS includes /usr/include/net/proto_net.h which wants to include . Seems that IBM has forgotten that file. Anyone with a ready workaround? Details: /* @(#)18 1.21 src/bos/kernel/net/proto_net.h, sysnet, bos43R, r1999_45B0 11/8/99 18:14:31 */ bos.adt.include 4.3.3.75 COMMITTED Base Application Development Include Files Harald. From kolya@MIT.EDU Fri Feb 8 17:30:10 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Fri, 08 Feb 2002 12:30:10 -0500 Subject: [OpenAFS-devel] patch for afs_vnop_remove.c Message-ID: <200202081730.MAA29986@pepsi-one.mit.edu> > this caused some oopses: obviously tdc can here be zero! Oops; thanks for catching this. I've applied it. -- kolya From yeejiun@yahoo.com Sat Feb 9 01:29:21 2002 From: yeejiun@yahoo.com (Yee Jiun) Date: Fri, 8 Feb 2002 17:29:21 -0800 (PST) Subject: [OpenAFS-devel] win2k compilation problems Message-ID: <20020209012921.85056.qmail@web11507.mail.yahoo.com> Hi, I downloaded release 1.2.3 and tried to compile it in the win2k environment. I followed the instructions in the README-NT file but I'm still having problems. I'm getting the following error: ---- begin --- ***** pthread cd src\WINNT\pthread nmake /nologo /f ntmakefile install cd ..\..\.. echo ***** procmgmt ***** procmgmt cd src\procmgmt nmake /nologo /f ntmakefile install link /OUT:c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.dll -debug:full -debugtype:cv -debugtype:both /NODEFAULTLIB /INCREMENTAL:NO /PDB:NON E /RELEASE /NOLOGO -entry:_DllMainCRTStartup@12 -dll /FIXED:NO msvcrt.lib oldna mes.lib kernel32.lib wsock32.lib advapi32.lib binmode.obj procmgmt_nt.obj redir ect_nt.obj afsprocmgmt.res c:\openafs-1.2.3\DEST\lib\afspthread.lib c:\openafs-1 .2.3\DEST\lib\afs\afsutil.lib /DEF:afsprocmgmt.def Creating library c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.li b and object c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.exp procmgmt_nt.obj : error LNK2001: unresolved external symbol _SwitchToThread c:\openafs-1.2.3\DEST\root.server\usr\afs\bin\afsprocmgmt.dll : fatal error LNK1 120: 1 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. NMAKE : fatal error U1077: '"c:\program files\microsoft visual studio\vc98\bin\N MAKE.EXE"' : return code '0x2' Stop. C:\OPENAF~1.3> --- end Anyone has any ideas? Yee Jiun. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From saurav_lahiri@yahoo.com Sun Feb 10 10:56:43 2002 From: saurav_lahiri@yahoo.com (=?iso-8859-1?q?SAURAV=20LAHIRI?=) Date: Sun, 10 Feb 2002 10:56:43 +0000 (GMT) Subject: [OpenAFS-devel] afsUUID uuid Message-ID: <20020210105643.15552.qmail@web11304.mail.yahoo.com> Hi, I was going through the source code for afs_server.c . I do not understand the real significance of afsUUID uuid. for instance afs_FindServer if ( !uuid) { i=SHash(aserver) and then a search is done in afs_srvAddrs Hashtable } if (uuid) { i = afs_uuid_hash(uuidp) % NSERVERS; and then a search is done in afs_Servers Hashtable. } I dont understand since all the servers are already there in afs_Servers HashTable why do we need a seperate Hash Function. and a seperate hash Table. We could have easily have given each of the servers a uuid. And the possibility of certain servers not having uuid would not have arise. Can some one explain Thanks and Regards Saurav __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From shadow@dementia.org Mon Feb 11 06:15:13 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Mon, 11 Feb 2002 01:15:13 -0500 (EST) Subject: [OpenAFS-devel] afsUUID uuid In-Reply-To: <20020210105643.15552.qmail@web11304.mail.yahoo.com> Message-ID: On Sun, 10 Feb 2002, [iso-8859-1] SAURAV LAHIRI wrote: > Hi, > I was going through the source code for afs_server.c . I do not > understand the real significance of afsUUID uuid. > for instance afs_FindServer [] > I dont understand since all the servers are already there in > afs_Servers HashTable why do we need a seperate Hash Function. and a > seperate hash Table. We could have easily have given each of the > servers a uuid. And the possibility of certain servers not having uuid > would not have arise. > Can some one explain Not all AFS versions support UUIDs. You don't arbitrarily decide the server has a UUID. -D From saurav_lahiri@yahoo.com Mon Feb 11 06:48:26 2002 From: saurav_lahiri@yahoo.com (=?iso-8859-1?q?SAURAV=20LAHIRI?=) Date: Mon, 11 Feb 2002 06:48:26 +0000 (GMT) Subject: [OpenAFS-devel] afsUUID uuid In-Reply-To: Message-ID: <20020211064826.65728.qmail@web11303.mail.yahoo.com> --- Derrick J Brashear wrote: > On Sun, 10 Feb 2002, [iso-8859-1] SAURAV LAHIRI wrote: > > > Hi, > > I was going through the source code for afs_server.c . I do not > > understand the real significance of afsUUID uuid. > > for instance afs_FindServer > > [] > > > I dont understand since all the servers are already there in > > afs_Servers HashTable why do we need a seperate Hash Function. and > a > > seperate hash Table. We could have easily have given each of the > > servers a uuid. And the possibility of certain servers not having > uuid > > would not have arise. > > Can some one explain > Hi, Derrick reply : Not all AFS versions support UUIDs. You don't arbitrarily decide the server has a UUID. My query: How does one decide that a server has UUIDs . Is it that only file servers have a uuid. It seems that when trying to locate volume location servers one uses a ip and when trying to locate a file server one uses uuid. Is it right? Thanks and Regards Saurav Lahiri __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From nneul@umr.edu Mon Feb 11 18:28:42 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Mon, 11 Feb 2002 12:28:42 -0600 Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure Message-ID: Feb 8 09:48:04 afs8 fileserver[561]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 10:05:15 afs8 fileserver[562]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 10:15:50 afs8 fileserver[567]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 12:23:17 afs8 fileserver[555]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 12:40:19 afs8 fileserver[561]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read failed device 2 inode 80C1CC0 errno 5=20 Any way to determine what volume that's on? I completely cleared one file server to another, and the failure followed with the same exact inode number, device changed though. If that's a real inode - it's rather large, and disagrees with anything on disk, so I'm assuming that's an AFS inode. It's 135,011,520 or 3,223,063,560 if LE. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From shadow@dementia.org Tue Feb 12 05:30:30 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Tue, 12 Feb 2002 00:30:30 -0500 (EST) Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure In-Reply-To: Message-ID: On Mon, 11 Feb 2002, Neulinger, Nathan wrote: > > Feb 8 09:48:04 afs8 fileserver[561]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 10:05:15 afs8 fileserver[562]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 10:15:50 afs8 fileserver[567]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 12:23:17 afs8 fileserver[555]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 12:40:19 afs8 fileserver[561]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > > Any way to determine what volume that's on? I completely cleared one > file server to another, and the failure followed with the same exact > inode number, device changed though. > > If that's a real inode - it's rather large, and disagrees with anything > on disk, so I'm assuming that's an AFS inode. > > It's 135,011,520 or 3,223,063,560 if LE. http://www.mit.edu/afs/athena/contrib/watchmaker/src/afscalc/calcfid.c note that it guesses about the volumeid, and sometimes is wrong because there's isn't enough information to readily determine it. -D From nneul@umr.edu Tue Feb 12 14:23:16 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 12 Feb 2002 08:23:16 -0600 Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure Message-ID: Bummer... it isn't coming up with a valid volume id with either interpretation of the inode value. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derrick J Brashear [mailto:shadow@dementia.org]=20 > Sent: Monday, February 11, 2002 11:31 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Error diagnosis - ReallyRead failure >=20 >=20 > On Mon, 11 Feb 2002, Neulinger, Nathan wrote: >=20 > >=20 > > Feb 8 09:48:04 afs8 fileserver[561]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 10:05:15 afs8 fileserver[562]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 10:15:50 afs8 fileserver[567]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 12:23:17 afs8 fileserver[555]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 12:40:19 afs8 fileserver[561]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > > Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read=20 > failed device 2 > > inode 80C1CC0 errno 5=20 > >=20 > > Any way to determine what volume that's on? I completely cleared one > > file server to another, and the failure followed with the same exact > > inode number, device changed though. > >=20 > > If that's a real inode - it's rather large, and disagrees=20 > with anything > > on disk, so I'm assuming that's an AFS inode. > >=20 > > It's 135,011,520 or 3,223,063,560 if LE. >=20 http://www.mit.edu/afs/athena/contrib/watchmaker/src/afscalc/calcfid.c note that it guesses about the volumeid, and sometimes is wrong because there's isn't enough information to readily determine it. -D _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel From ota@transarc.com Tue Feb 12 15:13:27 2002 From: ota@transarc.com (Ted Anderson) Date: Tue, 12 Feb 2002 10:13:27 -0500 (EST) Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure In-Reply-To: References: Message-ID: The problem is that that these print statements are in error. They contain a %X but are passed a (pointer to) a string representation of the inode value. From viced/physio.c:82: ViceLog (0, ("ReallyRead(): read failed device %X inode %X errno %d\n", file->dirh_handle->ih_dev, PrintInode(NULL, file->dirh_handle->ih_ino), code)); Where PrintInode is defined in sys/afssyscalls.h as: extern char *PrintInode(afs_ino_str_t, Inode); So the (second) %X needs to be turned into a %s. A quick scan of src/viced turns up several more of these. Ted Anderson From nneul@umr.edu Tue Feb 12 18:30:39 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Tue, 12 Feb 2002 12:30:39 -0600 Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure Message-ID: just sent a patch for the ones in viced, have not checked over all the instances elsewhere in src yet. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Ted Anderson [mailto:ota@transarc.com]=20 > Sent: Tuesday, February 12, 2002 9:13 AM > To: openafs-devel@openafs.org; Neulinger, Nathan > Subject: Re: [OpenAFS-devel] Error diagnosis - ReallyRead failure >=20 >=20 > The problem is that that these print statements are in error. They > contain a %X but are passed a (pointer to) a string representation of > the inode value. >=20 > From viced/physio.c:82: > ViceLog (0, > ("ReallyRead(): read failed device %X inode %X=20 > errno %d\n", > file->dirh_handle->ih_dev, > PrintInode(NULL, file->dirh_handle->ih_ino), code)); > Where PrintInode is defined in sys/afssyscalls.h as: > extern char *PrintInode(afs_ino_str_t, Inode); >=20 > So the (second) %X needs to be turned into a %s. A quick scan of > src/viced turns up several more of these. >=20 > Ted Anderson >=20 From haba@pdc.kth.se Tue Feb 12 22:26:12 2002 From: haba@pdc.kth.se (Harald Barth) Date: Tue, 12 Feb 2002 23:26:12 +0100 (CET) Subject: [OpenAFS-devel] Error diagnosis - ReallyRead failure In-Reply-To: References: Message-ID: <20020212.232612.68034577.haba@pdc.kth.se> > Feb 8 12:46:43 afs8 fileserver[560]: ReallyRead(): read failed device 2 > inode 80C1CC0 errno 5 > > Any way to determine what volume that's on? I completely cleared one > file server to another, and the failure followed with the same exact > inode number, device changed though. I don't know what is going on eiher , but I _did_ post a very similar question 2001-01-30 18:41. It is archived at https://lists.openafs.org/pipermail/openafs-devel/2002-January/002475.html And yes, I am still curious if someone knows the answer to my question The error handling could be improved in this case. As it is now, the error message tells the admin incomplete or misleading information and does that in the wrong way. Harald. n From nneul@umr.edu Wed Feb 13 13:54:05 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Wed, 13 Feb 2002 07:54:05 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow References: <20020213040914.470119C3F@grand.central.org> Message-ID: <3C6A6FFD.5C011E11@umr.edu> cvs@GRAND.CENTRAL.ORG wrote: > > Update of /cvs/openafs/src/rxgen > In directory GRAND.CENTRAL.ORG:/data/sb/openafs/src/rxgen > > Modified Files: > rpc_hout.c rpc_parse.c rpc_parse.h > Log Message: > DELTA rxgen-generate-function-prototypes-20020212 > AUTHOR bartbanter@hotmail.com > > actually from David Howells of Red Hat. > generates function prototypes in rxgen-emitted headers > > --- DELTA config follows --- > rxgen-generate-function-prototypes-20020212 openafs/src/rxgen/rpc_hout.c 1.4 1.5 > rxgen-generate-function-prototypes-20020212 openafs/src/rxgen/rpc_parse.c 1.11 1.12 > rxgen-generate-function-prototypes-20020212 openafs/src/rxgen/rpc_parse.h 1.1 1.2 > _______________________________________________ > OpenAFS-cvs mailing list > OpenAFS-cvs@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-cvs Hey, wait a minute... I thought we weren't supposed to have prototypes in those headers cause they could be used with kernel compiles? -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From derek@ihtfp.com Wed Feb 13 14:12:17 2002 From: derek@ihtfp.com (Derek Atkins) Date: 13 Feb 2002 09:12:17 -0500 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: <3C6A6FFD.5C011E11@umr.edu> References: <20020213040914.470119C3F@grand.central.org> <3C6A6FFD.5C011E11@umr.edu> Message-ID: Nathan Neulinger writes: > Hey, wait a minute... I thought we weren't supposed to have prototypes > in those headers cause they could be used with kernel compiles? Um, what's wrong with prototypes for kernel compiles? The point of prototypes are to get compiler warnings when you use a function improperly. > -- Nathan -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From nneul@umr.edu Wed Feb 13 14:17:13 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 08:17:13 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: Well, there has always been a history of "don't use prototypes" in the AFS source cause of certain kernel-compilers not being able to handle it. Or at least, be very careful about where they are used... Dig back in archives about the _P() discussion.=20 I'm not disagreeing with their use (I've held back on a ton of cleanup that would have added LOTS more prototyping), I'm just wondering about what appears to be a sudden change in policy.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com]=20 > Sent: Wednesday, February 13, 2002 8:12 AM > To: Neulinger, Nathan > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] Re: OpenAFS CVS Commit:=20 > openafs/src/rxgen by shadow >=20 >=20 > Nathan Neulinger writes: >=20 > > Hey, wait a minute... I thought we weren't supposed to have=20 > prototypes > > in those headers cause they could be used with kernel compiles? >=20 > Um, what's wrong with prototypes for kernel compiles? The point of > prototypes are to get compiler warnings when you use a function > improperly. >=20 > > -- Nathan >=20 > -derek >=20 > --=20 > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com >=20 From mbacchi@btv.ibm.com Wed Feb 13 15:27:25 2002 From: mbacchi@btv.ibm.com (Matthew A. Bacchi) Date: Wed, 13 Feb 2002 10:27:25 -0500 Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 Message-ID: <200202131527.KAA40014@bilbo.btv.ibm.com> Did bos.adt.include 4.3.3.75 forget it? Or did you accidently remove it? # lslpp -l bos.adt.include Fileset Level State Description = -----------------------------------------------------------------------= ----- Path: /usr/lib/objrepos bos.adt.include 4.3.3.12 COMMITTED Base Application Develop= ment Include Files ------------------------ # ls -l /usr/include/net/proto_net.h -r--r--r-- 1 bin bin 18735 Nov 10 1999 /usr/include/net/pr= oto_net.h /** ** Matt Bacchi mbacchi@us.ibm.com ** IBM Global Services SDC Northeast ** F6TG; MD Filesystems/Internet (802) 769-4072 ** ADSM & AFS/DFS Backup (tie) 446-4072 **/ From haba@pdc.kth.se Wed Feb 13 16:33:09 2002 From: haba@pdc.kth.se (Harald Barth) Date: Wed, 13 Feb 2002 17:33:09 +0100 (CET) Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 In-Reply-To: <200202131527.KAA40014@bilbo.btv.ibm.com> References: <200202131527.KAA40014@bilbo.btv.ibm.com> Message-ID: <20020213.173309.79422363.haba@pdc.kth.se> This is AIX specific, so anyone not concerned with AIX can skip this. I am talking about that /usr/include/sys/call_ie.h is missing from bos.adt.include because /usr/include/net/proto_net.h version 1.21 needs it. I have got /usr/include/net/proto_net.h from bos.adt.include so /usr/include/sys/call_ie.h should be in bos.adt.include or in another set that is required by bos.adt.include. If I comment out the atm crap from proto_net.h I actually get all the way through make dest. I have not tested the result yet. I wonder if IBM has a "compile kernel module" regression test prior to shipping bos.adt.include 4.3.3.79? Harald. From shadow@dementia.org Wed Feb 13 17:50:13 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 12:50:13 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > Well, there has always been a history of "don't use prototypes" in the > AFS source cause of certain kernel-compilers not being able to handle > it. Or at least, be very careful about where they are used... Dig back > in archives about the _P() discussion. Yeah, and we may well need to do this. > > I'm not disagreeing with their use (I've held back on a ton of cleanup > that would have added LOTS more prototyping), I'm just wondering about > what appears to be a sudden change in policy. There was one serious issue remaining in the head which was making the client go south on Linux. It's fixed. You were going to see a proposal here shortly about prototypes, but instead I'll just give the short version. Please, by all means, let's discuss it. -all functions prototyped, starting with kernel. this patch provides an opporunity to explore what if any kernel compilers suck. -all functions in kernel not being used outside local file actually changed to "static" -all prototypes for use outside file actually in header and correct, not just () and then the rest of the code: -more or less same deal, but obviously not changing bits of the API to "static" even if nothing is obviously "using" them -new header for prototypes, or "abuse" the existing main header for each system? (leaning toward the latter) From nneul@umr.edu Wed Feb 13 18:01:57 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 12:01:57 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: > -all functions prototyped, starting with kernel. this patch=20 > provides an > opporunity to explore what if any kernel compilers suck. > -all functions in kernel not being used outside local file actually > changed to "static" > -all prototypes for use outside file actually in header and=20 > correct, not > just () Sounds great to me! Standard prototypes or using _P()? Worst case scenario can hardwire _P() to blank when doing kernel compiles on affected systems. > and then the rest of the code: > -more or less same deal, but obviously not changing bits of the API to > "static" even if nothing is obviously "using" them > -new header for prototypes, or "abuse" the existing main=20 > header for each > system? (leaning toward the latter) Well, having them in the main header for each system (I presume you mean vos/pts/etc. for the system) seems like a reasonable approach to me, however, I'd like to see them organized in the headers consistently. I.e. always in a block at the end of the header, or something like that. Right now, they are pretty badly scattered. Similarly in some of the source files, there are scattered places where a .c file will include a prototype for a function outside that file, I'd like to see that go away.=20 I personally like to autogenerate prototypes (cfunc) but I think that'd be a bit messy here, although it would make using separate .h files for prototypes really easy.=20 I might add to that list - get the data type usage of the routines (including APIs) consistent. I started to do some of this way back, and got that committed, but there's a ton left to do. Also use of 'const' where appropriate. What about ANSI v. K&R on the routines themselves? I'll definately dig in on this when you're ready to move on it, cause it's the type of cleanup/rework stuff I usually enjoy working on.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From mbacchi@btv.ibm.com Wed Feb 13 18:22:55 2002 From: mbacchi@btv.ibm.com (Matthew A. Bacchi) Date: Wed, 13 Feb 2002 13:22:55 -0500 Subject: [OpenAFS-devel] Re: 1.2.3 compile barfs on AIX 4.3.3 In-Reply-To: Your message of "Wed, 13 Feb 2002 17:33:09 +0100." <20020213.173309.79422363.haba@pdc.kth.se> Message-ID: <200202131822.NAA40666@bilbo.btv.ibm.com> > = > I wonder if IBM has a "compile kernel module" regression test = > prior to shipping bos.adt.include 4.3.3.79? Harald, I see your point. I looked into this a little on an internal website(I t= hink = it's internal, if you can go to "http://rshelp.austin.ibm.com" then it's = not = internal), and it appears that this will not be fixed at AIX 4.3.3. From= what = I gather, they can't just add it to bos.adt.include, because it's already= in = devices.common.IBM.atm.rte, and this conflict can't(won't?) be fixed unti= l a = more major release. Thier workaround seems to be to install the atm fileset. Or I guess you c= ould = stick with your workaround of removing the stuff which would be in the at= m = header file. -Matt From shadow@dementia.org Wed Feb 13 18:23:46 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 13:23:46 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > Sounds great to me! Standard prototypes or using _P()? > > Worst case scenario can hardwire _P() to blank when doing kernel > compiles on affected systems. If there are no systems which need _P() now there's not much point in using it; We're not likely to port to old crufty systems, we already have ports for all of them. The only port I can't check is HPUX 11. > What about ANSI v. K&R on the routines themselves? presumably ansi, if we can do it safely. K&R is dead. > I'll definately dig in on this when you're ready to move on it, cause > it's the type of cleanup/rework stuff I usually enjoy working on. no time like the present. let's figure out what we're doing and do it. From adam@fsf.net Wed Feb 13 18:46:27 2002 From: adam@fsf.net (Adam Thornton) Date: Wed, 13 Feb 2002 12:46:27 -0600 Subject: [OpenAFS-devel] Aaargh! Incompatible includes. Message-ID: <20020213124627.A6029@dev-linux.fsf.net> How hard would it be to make OpenAFS rely on the more-or-less-standard-by-now set of includes that OpenSSL and most (Linux, anyway) distributions provide? I ask, because I've been having the very devil of a time getting AFS to build on a SuSE 7.3 Pro system, or to get AFS to play nicely with Samba 2.2.3 built with the --with-afs configuration option. And let's not even go into SASL 2 and Cyrus IMAPD, which really ought to be able to use AFS ACLs since that's what its faking on a normal filesystem. I still haven't even gotten afsd to run on a SuSE 7.3 Pro (i386) system; it immediately segfaults; probably because it's picking up the wrong library somewhere, but I haven't had time to investigate. It mostly seems to be traceable to differing sets of header files and libraries; the XDR headers in rpc are one set whose different interpretations cause SuSE 7.0+patches on S/390 to refuse to build Samba with the --with-afs option; for another, AFS, OpenSSL, and MIT K5 all appear to use mutually incompatible DES headers. I just want to build OpenAFS to use MIT K5 as its authentication source, and integrate with Samba and Cyrus IMAPD. It really shouldn't be as hard as it is. Adam From nneul@umr.edu Wed Feb 13 18:56:46 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 12:56:46 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: > > Sounds great to me! Standard prototypes or using _P()? > >=20 > > Worst case scenario can hardwire _P() to blank when doing kernel > > compiles on affected systems. >=20 > If there are no systems which need _P() now there's not much point in > using it; We're not likely to port to old crufty systems, we=20 > already have > ports for all of them. The only port I can't check is HPUX 11. Have builds worked ok on all the systems since that rxgen change? Actually, I can test that one easily enough, just not a full kernel compile. As far as I know, on hpux 11, the compile that is used is fully ansi and prototype capable. It's using the -Ae option, and usually on HP-UX when -Ae or -Aa are used, they are a halfway reasonable compiler. > > What about ANSI v. K&R on the routines themselves? >=20 > presumably ansi, if we can do it safely. K&R is dead. >=20 > > I'll definately dig in on this when you're ready to move on=20 > it, cause > > it's the type of cleanup/rework stuff I usually enjoy working on.=20 >=20 > no time like the present. let's figure out what we're doing and do it. What about the: int x(void) vs. int x() issue? Should void be used, or should a blank parameter list be used? I'd say that your list, w/ a little editing and expansion, could just be added to README.DEVEL, and then we can start with the changes just in the afs/libafs dirs as you mention as a starting point. It might also be worth suggesting that each C file document where it's prototypes should be located somewhere near the top of the file. I'm not sure if the prototype list should indicate the file the prototype is for, but that might not be a bad idea. i.e. /* Prototypes */ /* afs_osi.c */ void osi_Init(); ... /* afs_util.c */ char *afs_cv2string(char *, afs_uint32); ... /* End of prototypes */ I need to look at cfunc again. If we segment out the block of prototypes with distinct marker strings, we might be able to leverage cfunc to do some of the initial work on generating the prototypes. Wouldn't be necessary initially, but might make auditting the whole source for completeness easier. Is there a gcc option to absolutely require prototypes? I guess -Wall -Werror might be a reasonable check, but liable to be more trouble than it's worth. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From shadow@dementia.org Wed Feb 13 18:55:24 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 13:55:24 -0500 (EST) Subject: [OpenAFS-devel] Aaargh! Incompatible includes. In-Reply-To: <20020213124627.A6029@dev-linux.fsf.net> Message-ID: On Wed, 13 Feb 2002, Adam Thornton wrote: > How hard would it be to make OpenAFS rely on the > more-or-less-standard-by-now set of includes that OpenSSL and most > (Linux, anyway) distributions provide? Relying on external packages violates a constraint we've been working under for a while, but: > It mostly seems to be traceable to differing sets of header files and > libraries; the XDR headers in rpc are one set whose different > interpretations cause SuSE 7.0+patches on S/390 to refuse to build Samba > with the --with-afs option this should be fixable; it's been fixed for all the other platforms which had similar problems > for another, AFS, OpenSSL, and MIT K5 all > appear to use mutually incompatible DES headers. I haven't looked in a while but last I did the types may have been different but the net result was the same. Has something changed? I have ADM building against AFS, Heimdal, OpenSSL, SASL and libcyrus, and yes, all being linked into one binary. I did need to explore this, and honestly I don't remember what the answer was. -D From nneul@umr.edu Wed Feb 13 19:02:08 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 13:02:08 -0600 Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow Message-ID: What do we want to do for cases like afs_osi.c and afs_osi.h. Some of the files in afs/ have their own .h files, others don't. Should the prototypes go in the afs_osi.h file, or afs.h, or somewhere else entirely? I tend to wonder if it might be cleaner to add a X_proto.h file for each dir X/ that would contain prototypes and externs only, and move all the prototypes to there, and just include that prototypes file in appropriate places. For some of the other subsystems it's not as confusing, they already have distinct header files, but it still may be easier for auditing to segregate. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From openafs-devel@openafs.org Wed Feb 13 18:56:24 2002 From: openafs-devel@openafs.org (Derek Atkins) Date: 13 Feb 2002 13:56:24 -0500 Subject: [OpenAFS-devel] Aaargh! Incompatible includes. In-Reply-To: <20020213124627.A6029@dev-linux.fsf.net> References: <20020213124627.A6029@dev-linux.fsf.net> Message-ID: Adam Thornton writes: > I just want to build OpenAFS to use MIT K5 as its authentication source, > and integrate with Samba and Cyrus IMAPD. It really shouldn't be as > hard as it is. I dont know what's so special about SuSE -- the Red Hat RPMS build OpenAFS and use MIT K5 as its authentication source. It works just fine. Yes, there are compiler warnings during the build process, but I've found that they can pretty much all be safely ignored. What errors, in partcular, are you seeing? > Adam -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From shadow@dementia.org Wed Feb 13 19:24:49 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 14:24:49 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > > already have > > ports for all of them. The only port I can't check is HPUX 11. > > Have builds worked ok on all the systems since that rxgen change? Can't tell you authoritatively, I'm unable to log into my AIX box, but that will be resolved shortly. > Actually, I can test that one easily enough, just not a full kernel > compile. As far as I know, on hpux 11, the compile that is used is fully > ansi and prototype capable. It's using the -Ae option, and usually on > HP-UX when -Ae or -Aa are used, they are a halfway reasonable compiler. > What about the: > > int x(void) > vs. > int x() > > issue? Should void be used, or should a blank parameter list be used? the former makes more sense, but i know recently i had an issue where a compile objected; i just wish i could remember what and where. (it might have been a c++ compiler, in which case i don't care; fingers in too many pies means i can't remember what's what) From nneul@umr.edu Wed Feb 13 19:51:22 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 13:51:22 -0600 Subject: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() Message-ID: Is it really necessary to have AFS_GLOCK()/GUNLOCK() wrapped with an #ifdef RX_ENABLE_LOCKS everywhere in the source? It appears that the definitions of those macros are #ifdef'd already. Seems like it would clean up the code quite a bit to get rid of all the spurious ifdef's.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From kolya@MIT.EDU Wed Feb 13 20:11:29 2002 From: kolya@MIT.EDU (Nickolai Zeldovich) Date: Wed, 13 Feb 2002 15:11:29 -0500 Subject: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() Message-ID: <200202132011.PAA14906@pepsi-one.mit.edu> > Is it really necessary to have AFS_GLOCK()/GUNLOCK() wrapped with an > #ifdef RX_ENABLE_LOCKS everywhere in the source? It appears that the > definitions of those macros are #ifdef'd already. Seems like it would > clean up the code quite a bit to get rid of all the spurious ifdef's. There's RX_AFS_GLOCK() and RX_AFS_GUNLOCK() in the mainline (which I snuck in with the dcache locking changes), which are defined to be AFS_GLOCK/AFS_GUNLOCK when RX_ENABLE_LOCKS is set, and blank otherwise. So, you can replace the #ifdef/AFS_GLOCK/#endif combo with RX_AFS_GLOCK, etc, if you want. -- kolya From nneul@umr.edu Wed Feb 13 20:22:33 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Wed, 13 Feb 2002 14:22:33 -0600 Subject: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() Message-ID: Cool. Yeah, that'll clean the code in afs/ up nicely.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Nickolai Zeldovich [mailto:kolya@MIT.EDU]=20 > Sent: Wednesday, February 13, 2002 2:11 PM > To: Neulinger, Nathan > Cc: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] RX_ENABLE_LOCKS and AFS_GLOCK() >=20 >=20 > > Is it really necessary to have AFS_GLOCK()/GUNLOCK() wrapped with an > > #ifdef RX_ENABLE_LOCKS everywhere in the source? It appears that the > > definitions of those macros are #ifdef'd already. Seems=20 > like it would > > clean up the code quite a bit to get rid of all the=20 > spurious ifdef's.=20 >=20 > There's RX_AFS_GLOCK() and RX_AFS_GUNLOCK() in the mainline (which > I snuck in with the dcache locking changes), which are defined to > be AFS_GLOCK/AFS_GUNLOCK when RX_ENABLE_LOCKS is set, and blank > otherwise. So, you can replace the #ifdef/AFS_GLOCK/#endif combo > with RX_AFS_GLOCK, etc, if you want. >=20 > -- kolya >=20 From shadow@dementia.org Wed Feb 13 22:54:47 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Wed, 13 Feb 2002 17:54:47 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: Message-ID: On Wed, 13 Feb 2002, Derrick J Brashear wrote: > On Wed, 13 Feb 2002, Neulinger, Nathan wrote: > > > > already have > > > ports for all of them. The only port I can't check is HPUX 11. > > > > Have builds worked ok on all the systems since that rxgen change? > > Can't tell you authoritatively, I'm unable to log into my AIX box, but > that will be resolved shortly. Of course, I built the wrong tree after the patch, there's work to be done to resolve it; I'm working on it now. -D From luan@almaden.ibm.com Thu Feb 14 02:35:35 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Wed, 13 Feb 2002 18:35:35 -0800 Subject: [OpenAFS-devel] Java API for AFS Admin Message-ID: We briefly discussed this topic earlier. A list of Javadoc HTML files defining a proposed Java API for AFS Admin are now available at http://grand.central.org/twiki/bin/edit/AFSLore/JavaAdminAPI for your review. We especially look forward to the feedback from experienced administrators as well as those who have written tools for managing AFS. Here is the rationale for having such an API: In large AFS environments, local tools are frequently developed to manage AFS more effectively. Today these tools are usually written in scripts. These scripts typically issue AFS commands and parse the command output. This is not a good practice as command output are not well defined. Their format or even contents can change in new releases. An AFS Admin API is needed. Today some internal C libraries exist and are used by the AFS command suite as well as the Windows Admin GUI. But they are not clearly defined for external use. Here a set of Java Admin API is proposed. The goal is to make the API suitable not only for administrators to write custom AFS automation tools but also for developers to write general and powerful tools for easy and efficient AFS management. Shyh-Wei Luan From luan@almaden.ibm.com Thu Feb 14 02:48:57 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Wed, 13 Feb 2002 18:48:57 -0800 Subject: [OpenAFS-devel] Java API for AFS Admin -- CORRECTION! Message-ID: Oops, I gave a wrong URL earlier that would send everyone to the editing window for the Wiki topic. The following is the correct URL for viewing. Please use this one instead. http://grand.central.org/twiki/bin/view/AFSLore/JavaAdminAPI Sorry for the mistake. Shyh-Wei Luan Shyh-Wei Luan/Almaden/IBM@IBMUS@openafs.org on 02/13/2002 06:35:35 PM Sent by: openafs-devel-admin@openafs.org To: openafs-devel@openafs.org cc: Subject: [OpenAFS-devel] Java API for AFS Admin We briefly discussed this topic earlier. A list of Javadoc HTML files defining a proposed Java API for AFS Admin are now available at http://grand.central.org/twiki/bin/edit/AFSLore/JavaAdminAPI for your review. We especially look forward to the feedback from experienced administrators as well as those who have written tools for managing AFS. Here is the rationale for having such an API: In large AFS environments, local tools are frequently developed to manage AFS more effectively. Today these tools are usually written in scripts. These scripts typically issue AFS commands and parse the command output. This is not a good practice as command output are not well defined. Their format or even contents can change in new releases. An AFS Admin API is needed. Today some internal C libraries exist and are used by the AFS command suite as well as the Windows Admin GUI. But they are not clearly defined for external use. Here a set of Java Admin API is proposed. The goal is to make the API suitable not only for administrators to write custom AFS automation tools but also for developers to write general and powerful tools for easy and efficient AFS management. Shyh-Wei Luan _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel From luan@almaden.ibm.com Thu Feb 14 07:07:59 2002 From: luan@almaden.ibm.com (Shyh-Wei Luan) Date: Wed, 13 Feb 2002 23:07:59 -0800 Subject: [OpenAFS-devel] Java API for AFS Admin Message-ID: We don't need to deal with the RPC. The implementation of the Java API could communicate with the native AFS administrative library (libadmin, which is already available in OpenAFS) through a JNI (Java Native Interface) layer. The libadmin library is currently used for the implementation of the AFS command suite and the Windows Admin GUI. But it is not a documented external API. The idea is to build a well-defined and easy-to-use Java API around this C library, so that powerful Java-based management tools can be easily developed. Shyh-Wei Luan Jimmy Engelbrecht @e.kth.se on 02/13/2002 09:25:10 PM Sent by: jimmy@e.kth.se To: Shyh-Wei Luan/Almaden/IBM@IBMUS cc: openafs-devel@openafs.org Subject: Re: [OpenAFS-devel] Java API for AFS Admin "Shyh-Wei Luan" writes: > Here a set of Java Admin API is proposed. The goal is to make the API > suitable not only for administrators to write custom AFS automation tools > but also for developers to write general and powerful tools for easy and > efficient AFS management. I have some questions. As you know the different servers allow you to do a few hundred different RPC-calls, is the idea that all of them should be accessible though the java-API ? How do you want to do RPC-calls from java ? Is there a usefull and working package that can do that for you ? You want to generate the RPC-stubs yourself ? Or you just steal the stubs from some exsisting AFS-implementation ? /Jimmy From nneul@umr.edu Thu Feb 14 20:26:33 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 14 Feb 2002 14:26:33 -0600 Subject: [OpenAFS-devel] cool, already found something from prototype work Message-ID: =09 in VNOPS/afs_vnop_lookup.c: if (tvcp && retry) { ReleaseWriteLock(&afs_xvcache); afs_PutVCache(tvcp); } } while (tvcp && retry); everywere else, afs_PutVCache() takes two arguments, the second is a lock type.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From nneul@umr.edu Thu Feb 14 20:38:56 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 14 Feb 2002 14:38:56 -0600 Subject: [OpenAFS-devel] cool, already found something from prototype work Message-ID: BTW, there are a whole pile of these mismatches in that file. In my local checkout I'm just making second arg 0, but would be good for someone more knowledgable to commit a more appropriate fix. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Neulinger, Nathan=20 > Sent: Thursday, February 14, 2002 2:27 PM > To: openafs-devel@openafs.org > Subject: [OpenAFS-devel] cool, already found something from=20 > prototype work >=20 >=20 > =09 >=20 > in VNOPS/afs_vnop_lookup.c: >=20 > if (tvcp && retry) { > ReleaseWriteLock(&afs_xvcache); > afs_PutVCache(tvcp); > } > } while (tvcp && retry); >=20 > everywere else, afs_PutVCache() takes two arguments, the second is a > lock type.=20 >=20 > -- Nathan >=20 > ------------------------------------------------------------ > Nathan Neulinger EMail: nneul@umr.edu > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From shadow@dementia.org Thu Feb 14 20:40:49 2002 From: shadow@dementia.org (Derrick J Brashear) Date: Thu, 14 Feb 2002 15:40:49 -0500 (EST) Subject: [OpenAFS-devel] cool, already found something from prototype work In-Reply-To: Message-ID: On Thu, 14 Feb 2002, Neulinger, Nathan wrote: > in VNOPS/afs_vnop_lookup.c: > > if (tvcp && retry) { > ReleaseWriteLock(&afs_xvcache); > afs_PutVCache(tvcp); > } > } while (tvcp && retry); > > everywere else, afs_PutVCache() takes two arguments, the second is a > lock type. Yabut PutVCache is: ObtainReadLock(&afs_xvcache); AFS_FAST_RELE(avc); ReleaseReadLock(&afs_xvcache); Useful to fix, but not a real problem -D From nneul@umr.edu Thu Feb 14 20:45:26 2002 From: nneul@umr.edu (Neulinger, Nathan) Date: Thu, 14 Feb 2002 14:45:26 -0600 Subject: [OpenAFS-devel] cool, already found something from prototypework Message-ID: That's rather scary... Cause there are cases where PutVCache is called with a parameter of WRITE_LOCK.=20 No matter. It won't compile without the argument if prototyped.=20 -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Derrick J Brashear [mailto:shadow@dementia.org]=20 > Sent: Thursday, February 14, 2002 2:41 PM > To: openafs-devel@openafs.org > Subject: Re: [OpenAFS-devel] cool, already found something=20 > from prototypework >=20 >=20 > On Thu, 14 Feb 2002, Neulinger, Nathan wrote: >=20 > > in VNOPS/afs_vnop_lookup.c: > > > > if (tvcp && retry) { > > ReleaseWriteLock(&afs_xvcache); > > afs_PutVCache(tvcp); > > } > > } while (tvcp && retry); > > > > everywere else, afs_PutVCache() takes two arguments, the second is a > > lock type. >=20 > Yabut PutVCache is: > ObtainReadLock(&afs_xvcache); > AFS_FAST_RELE(avc); > ReleaseReadLock(&afs_xvcache); >=20 > Useful to fix, but not a real problem > -D >=20 >=20 > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel >=20 From nneul@umr.edu Thu Feb 14 21:34:55 2002 From: nneul@umr.edu (Nathan Neulinger) Date: Thu, 14 Feb 2002 15:34:55 -0600 Subject: [OpenAFS-devel] starter patch for prototypes... Message-ID: <20020214213454.GA8370@umr.edu> --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (This includes three local patches marked UMR-ONLY, I just haven't edited them out for this.) Would appreciate hearing any comments on how this has been done... Documentation change for README.DEVEL is in afsdoc.diff. I'd also be interested in hearing if anyone has any trouble compiling with this patch applied. I've tested on sun4x_56, and i386_linux24. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="afsdoc.diff" Index: README.DEVEL =================================================================== RCS file: /cvs/openafs/README.DEVEL,v retrieving revision 1.2 diff -u -r1.2 README.DEVEL --- README.DEVEL 2002/01/02 04:12:20 1.2 +++ README.DEVEL 2002/02/14 17:52:42 @@ -16,3 +16,51 @@ Try to test builds using gmake -j # MAKE="gmake -j #", it seems like a good way to find missing or order-dependent dependency rules. (Is there a better way to do this?) + +-- Prototyping and Style -- +Prototypes for all source files in a given dir DDD should be placed +int the file DDD/DDD_prototypes.h. All externally used (either API +or used by other source files) routines and variables should be +prototyped in this file. + +The prototypes should be a full prototype, with argument and return +types. (Should not generate a warning with gcc -Wstrict-prototypes.) + +Format of the prototype files should look like: + + Standard Copyright Notice + + #ifdef AFS_SRC_DDD_PROTO_H + #define AFS_SRC_DDD_PROTO_H + + /* filename.c */ + prototypes + + /* filename.c */ + prototypes + + #endif /* AFS_SRC_DDD_PROTO_H */ + +The declaration of the routines should be done in ANSI style: (can we +do this safely on all platforms? might want to use ansi2knr if not) + + rettype routine(argtype arg) + { + + } + +All routines should have a return type specified, void if nothing returned, +and should have (void) if no arguments are taken. (still checking on this +to make sure it works everywhere) + +Header files should not contain macros or other definitions unless they +are used across multiple source files. + +All routines should be declared static if they are not used outside that +source file. + +Compiles on gcc-using machines should strive to handle using +-Wstrict-prototypes -Werror. (this may take a while) + +Routines shall be defined in source prior to use if possible, and +prototyped in block at top of file if static. --pf9I7BMVVzbSWLtt Content-Type: application/octet-stream Content-Disposition: attachment; filename="afs.diff.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWS0q3RcAUaj/gH/+hkd7/////+///7////9gZH999lo+tdC+9wF8hnuYAaCt d7vj32zQUnei7ust96vvl5097p973PuK+d9qve6PTuw7aQLHu5Z29bod282tDpiGjJx72R7x 5DAL3PdePb7Grd0vOfbvvju3RXK2AaB6drhyPQPXQ909ZDkW2IjZc3TnGOuS24Id1rbo3MM1 2aXbq3XVLqLYA0bNWZdrYXbX3t09pu3dN6HVXW6fACtc977289vabvtq+sT7DyYvtve+znqr TL3YfPC3UuNEIm7Vybu5O2tmRcqW2TVd8vLjwLmK0lbjw+2+982t7t3VPo95tG99xz293dO5 oidYxvtuvWvWeAlNEEAIAICZGTSZMk2kbQUT/RBqBlHtSYINPU0aekeo8oNNAEghCZDSTJ6m p5E9qNT1NGjTanlA0aGgDQ0AAAaAxpIiU0pkfpQbSepoz1T0gHqHqaPakNAAANAAGgYgGgk0 kRCTTQmJo0GgTBFNkjamnmhop6m1PIgeUBoDT1MgyMgiSIETU8UwGkZGQTBFT/I0GhpAp5pq mnqZPTRqG1NMTQyGjCJEggJppoIMTU0yaqfkk/NU2p6app5TaYUeoPSBoAAAA9R2vjuEohED 4QoiRgoyCiHlAQCiKKF4hQQkAFGSQFP4yRFaQIJD5HD758matkoNBkKUpSlA+U0uBwOBoiXm WwjdOGEaGoyKQYMLLLC1wQWQh9W+2whiOYxgxzGJEzMwyLAYiIIgsR1Ov9X9E/n/7QT+mBl7 YaSJrGJBi6xiQbLUflouXIx1MVBFRYiqKqRFiwRjBiKDFxXFcVEAWIKLMVxXFzMMgoM8ni+6 60dfovh/X04NaG/21tWGSQEkS/N+Pt78XpHb1/ONIwxeRTLNFgfX5S9Z/xbkTUYpFEVBYR8e jX7Ty+cnkrA9UYCTDI88qPkbaYodLFgxrC5KW2Uwb36yFii9iIPSRrOIWxgsFRRYcovK8zWC U1SEiRDQqggsfT9UQuqH9PqDxP/phxba/z9XWvfZRnR566zTt8uii6RYcuW5lgbcbTCOQy0n CvO9a0G2ZrnMcEL+e4/aycHnuknFo29K4Z13cQTfOY8CsKaOHA5jvCgnDrBs3rUw7Nhzpwch whI2YmseyF1Nmb8dExrytNRkYhsiusbqbVW7XPteW2LKSVDElShFqPjLlxydL63QW6yci10K sab7l2ukXG1di1DKIlzWq2qooKGmGapp0i6az236edHLdVHlALjeXHToCs6ZreYKQ8vEsXzO pMRrVez5jNSZYd18YMNTqDLbZ0EhdIuvJzp0IjulYqNyo4kRlgjbPEyaXLNSiSlYVG41JjGC M4bLa1VY2JR8uQwy0WS2wHUIXYzBwDDih2yS6LabYUad9CuJLUpF9vpQ6O7iZ5i+H0vPBDaV si82DXxt7VeSdY71HMsdeiRUUjm0oJSwk8KJbE0wkk6EM//bYOWo6/VqhSvpHxNdCI/dGdf9 u2V6kmvsKQO0t7+pH6ocaW0p5V3SrN5tZmSZYPwHxfV4fZm9nmLzcN4AfccmvQutoU7OLI9Y a8NvnaLZ2b8vS3rFUc9MtVXdpZGvF392dI4LiqugpTiZlDJFErRnNhJqLrolVZ+zO6otAlrD eCa0ClHZZZeCu1WXed4m+l48Vl3vPLdYM6ZmHaEqBpkxkUmMqDXDSYSVAPuMlSYoh5RKOxMC BIDEgSISvb76SS9vMKCa8r3QXFozM5a8TkFZ6QWlQbVy7+37315Ws2xZrnK/BSToSo0p9Nns 9vy/M/ueI+b8EkKkUVVFZUxx4hnDpMyTIVTPVpYsWLCtYqtbWFVVVrVa1Va1WsKxVkFnsaqu IVsZFgqIixgjBQiiwVURFZFFFiwKPwDNs0laaS48NdRd5UwxPKK6oSF49cfXz6ySiENoTmzj AxgcaMlW+mt6iKPShpS2KVLlxJVRTHLdZKcEk1mQk6pCLC7sAORg58OCm2TTalCAiwGPBZFK HNKADJI5ZJUhbLwJQYaCJAxgbGBvKFA2UJaYzzOgel9KG2SBMUU4+6lNY65Vf2UiXG4JHAtR WHCFQxG2c/fPvIoKpFFJ4GxGIptAUOlw9kEde/jqEqE2uZMCd6acthbRiKLlKdfLeWcO/2tF BBDLReHjKaalW6yFcaWnO/rydGbVBZOGnHGGorDTJeN5tm2cMqAcKiwl3nUbgHuIJcBhDPNu 6B8abJY1nld2DQN3hLbcMMiYLVzO88aKCqRRSeHOj5noG5/kjYv1IwUP6YLUSVysTHF+dfyR NvB3EhpuPbXM70vLe4diaPTTWm7c5tdJdcOHudKcIapZ3eRZpHPPGXKD8uLmJdyZLBeGHc4t AkdqQrfmluX3MzCslHl5rc+uRqRZZlxnpXA7LwzoseUDsvTE7YszxJzs+UZmtDLHvbwPHw6i kvTKhDdjkfI4f+0XWgAgfeAg8ZH+UBtAhAZFWEBhOO9HJYpLwCSQJFXkiJ6/L7srgc8OEPBB XWTVIa0KfBBvOEqBeDM3xb5AzvvEkDZbBN0goSskUIbyyBxgpgIMRQQKnjNkJFykIoIgXhRB IozzX9noiJREbKxSKwH2KwgyRh8qBjHLIWQlSScPz5QUTRQkqKq2SMCMkSoAVJBgyFYSSF4S kAkRcCyjFWAZ4Q556X87uyBtBSSZzYAVKCJGQqQLFSTgSVCCAyEUkFJFIpJEQAFggxZIgggy bZA5BnvfD7NBphFkUifieww6M0gZ/H34ukJrzPAbDZmx0aMIUKGUpkxId/uX6DW2HJqCI8Nj BTpW0rswIP1QT0+nGwxTUr4VUbhsPD7rskGdYJREaUPWnlgLA0/FZ7MgaDPPhcEsBrT+DnmY GpEBIiwOeOid2ybmZ/c/8d/3bvzmfnozfogSQnMVHuD4MuhnzsK3nlkfEHIjGEisIBsPzxAv nObzrHPnn+fLbP4+v69g/z22X64d76qM19ZUoqyIUzUTIYx2fwguraTEWMwUn/p30IFBwsry RexEQN4REEkB9SB3D/rj+YwIwZvFNxQBwTE1JF6fzbd85cqM/YwcJ88oCEoc70dR/aNNgi0+ vLNuu7/3d/36ZN/8/xpFnh/6fPe8hp7fo5xXCj44ynLW/+787v6PS5dI4dVvCWoQWBS+BZe7 /SxgZh7xAS96Ui8KJu6IggpLwfRx6z5vodH3ceQPYb320dX8+y43qhQVD5HwbnXDecRVk8eT vPz83eyTl3de2+6k7OykHpwPnF3+ldEpps1D0Ee8KJJBJroNBMwoRRqtAkEvFw8kebIoYEjY YZJTgHXfZapEiC7BZBhJJGQRUk5CE3iIcQgGJT5+CEDjIdjiXDvC8if2TtLAyQ69OuhB6No2 FTfDxo7Nxpy/1G6jXPeljXurc2bSrdmKeHUEExRsd8ySTJmIBsdxNjXbUkL4/d9n06+qZNQv phOffV3Fc4qy6tuUl36i3iXE0ZlN2ZzJxxVrjVxAKpZLExSsLt7NzENbfYvLVqiwtRYzJDTm ZMedOBroEyXk4m4ZabxTegmsulFQAhdzOS841M6hiCrs71KvBlplfEbH6T3enr4qO3n/5P2C IfUjBR4FUiJp/9RfAi9HuGp8klE2ysySjFh9uQgTM+xKJB/x4XLaUo8tBRy4mP2z4RU+N+2E nd+Du8Pye7Z+uWEqpJ2Pk7nu7cR7Ir0hBgJIwJFhA/D38mz6NuR9i53MM3gfDux1M0peRrJs x/psijDNPdu8uGy48PYa0v+f8nJUSWzefJt+rq/oas/NRAe+1xWr5frkM1hFhAr39jOguP/M enkE/bx2MB4+7u41n5KwuIA3LEf7Ebe9yuLjBkIQksxsEyzgsI99v/21fpvxRZbsRVkSTUhy y83W4T+5G1aJUpdXFk8vn4OznZ8PQ7pN37HVQlqOqLJM7M1dXVvhBIjW8yvUxzFMoW3jVU+4 w0pjaLlsgiCFoWZN9OAKgPEsCSIendlouRPxFThlolne1wrTMAu3rx1blnSlMU5T5vVIfHaH 8E+SPprRp94lx+9PplN6GKFLVdz9l5hAZt3X1D8vNNH3EZ9+v7suP0aX+r+Zv3Mjg403sKce 5HLIvsIm2Zi13PhR87wcLGQBYdZZ8/6vzXbjDK5lZi8WnkWB7I1vTXuE+BfHw6l4znXXvrth D5tsklhIoBILZSrWq+4ejMXStVG3p8QeLWtqqq9aVXOyZjWqNV451koeGzwkidCeEEHBEHI5 ii8wmvBTYZkCF3GUwqt/ru5kgZyW/fDW0YC6C0E0+B8Pg5YKfyFnYkunkJzZTZOXOHM+GD/N a7XPMhE3fSo5JDIQIBnRhOsuxGBhWgISENiG3b6sdKAe5OzLF8My/YlRVCTBOdSDdwKcb8Xv wzxCRqc+2tJCJnRz5VnxdqIhiBDUz3QQvmdnx2eNcZS9MpSlfLFwtnP1UqJpu9nS7y6Dv7nf j2gTO8y76fQd9PIkGI+1FIHf3PId5d3eHcdaS0qrqpRAelIyEXxmZmenlE7vagNjWGT8WiQR gsFFg5qAlukbwSGG0LP4TLKgYExXxh5ckbsTltYFHnntzOJ5+pRYfzYKmZ6s+H3vId5wXfpv QHjEeuIzmZ1z2ISO17jd0BkAkUkCRHXXz1u9l7zc7imyLgZe4hPJ9/EKm+/fvu7+bu79zuOe eB8qi787sQGgcftoHqgHdBSokgEgRQYCO8oEcYoMRHPx2w8U55+nTz+TS2H37TpsVc99q+Tq a7zFFqXflOim68KDMDX7GvauaHsowwGnUcsqVLXs/BxOpQgbVQQI3Zd9ZAevQ5DMlj8DvKAj fFQWCGYt9atgg4zomtWSAsuye71G+Bov/Y2LFUWdGEdFluvjrht6PAsGmmZlt0L8sjYud51C 3MhsmNTBRnB5okbhePRia9qxSUfRI2NjMB2NMgmRKbd0TgTUbFk7GiFXTfW5vj2t+5uAebnO c5u4MiLUyDhhabq2mFbhiojdeOin5NYhJyWG6IJ6EPumU4PPOxui+NCZALd1y94BPblVsVhg +19xGd5nhu5eW+zTgm6DIpIqa9WPOXNnE431Xfgi35xK9quw5PkVGP+Eexayjbd1hlljMOO5 W57mztY9tjtYVR/Wfv6KNqKFPPhxuJk6ogjfKJIIHJq01H7667H0h8WsV6cTo9JDM6QIEQ7o XcjpNp03h1uOka9a8/RhfHbi8K6K7Eg1nRhrp7b6zFhEzCfd95Igu5WahsQpkSPQwd9Hgo4M IEaQ21DSCjICizTDeFhbrcDUNFweJFmjXBSEIDhIZCY0M29Fsl9bE9hx5MPmfLX9bzm/reXw 1A7vydsGpaLrfqX0ys1FYMtptNkXl0kKtcvo0pJmvE3KHusbMRpBCFACQnrm/Uq1jV59/Wqf be5KbhugdfXCfKID5RjI30KQcS3AvY1QC7sG+uPevgQlaYMu8lPDbIkVuXba0Y0u9KbejKlU Yaf+Ixz1EpQ6HuF5CvrMN17ny69MqmIlW25nXpmXUvnYdAhSujaE3EwdqYwWDsqbMoU00TgJ yHN9Cmsplmh7Y/AlFcca5L4VxnI1X87v6pnVpOkrToewNzHWnBJoVHwxziVdxHaRa0N5Oqlx mwzTMFc79mNNoNmzZZPuRiqC83v+EMzaGOxZiJXAMJuG1NprJeJlH32UGJFo6pAw7ykL9HGG Pnz4r0Pwn6vyZb4w4AA0U4HsRO6inpqzwPfO2ves6MzsWWHPoBtiIMwN3I28Jo0VXAYCwsML IWDFQSbsDEuWUQ2MhcwwK4yNmkMkZVSaELS4GIBjCYSBI0hD3Z7N0Iee3WW+qb7H5F0Zt6Wj fmXTIHDsbCLsRFW36ss8TKmGdtr1cpKh6C20aaW1LfBnAO2eXlnfQObl91C8AdhQfqvy2AEF ta+t/gGwwba+R+K7Lv4ioQp4+ShHLibT0bblw48775yrKllhfmXBdJ9KbOI+e66Cxc7BxjHV 3Uk2Ahm6F4ec788y6ox9pjpNpnnqT1apIMzyUE7CtpdRJHs1qRh0xZ7C9oxgHQhCD1RIsILB RvOj7/IQ6p1EAh/L5Ne/u+9TXHiYurA650KSNh+VuK3WKrKdzFkweQu1khJgQlOEDjKhURZB zptDquBU467XrgtQCgdCYsmxNEAVQSQQIuX++/+GDEmKMaINEJCwRggeJK+TwPH7T7ZwoIjF gh+7jRbkIcuzAhiB3DD8KKQKgSA1GRKsSFKFZSpGCkUZIERVoiMbSMRpGSBKIi1ESLIfV+5P zHyBqKEQSHIgu3xMlGYLAVSMT/Z58Vcd2goVJYjED+s7/c8ovgAccHs7qEL6unP2KXWOr8bN nUZuc2bq7cH5Jbdl0Wb/tm08EY5muXldT1XWFnSraEI716vU7rhyeEuFfKV11kNi9nw53zvr TE/GEiiISaSChG92SVO9bYnJUoo9ytNEfQUynhymUgQBFiBCS4wj4mXg1KsR9xr08lGJfG7M uLBLfSo6EZ0nDkbYu6jnfdPd3rr4awgO1ZsxxR+wGEzQfrR8OlCQJMkyZIoKLCRZRJCiQEDQ dup5+PTvt+k9XDfU3lidXPCMGS8zjpbaUlTxGfuTR0vKU4MvRqbn41XonCnggcV5tyWr6jKh NBU8MVs4t/ab0ow2eip2UnRXbc9ju3jF5DoTb05iaF508JscAxyX4y7RXze7dkQPsc8UF6IL ykEIzUhedF7bOuki9TWIr7S6BwqIRu6JFixXQmxFhaz5Ue7zOHB//P+thPMdWDcCJfvWZ0yx 7TXxqE79IGHN0pNuyNyJeSOFjTs/mjo44Vgnl/Cew/eWooq5/yIZvXTRshphdsDJ0EEMxpCL 463iESeS16nD1+fBNp3d5T1dL/iiXKzrjNf0KBHX42dUtUS/tW86hS5p19nmg4qV78tc5zn0 OkYIazP5fivu0/1p8OhXz7BnHEa4x+jhesT1WEb7K8pa4uFkPhVy/TeIA+db3cDWFY8PByyh 1BQIUBKFCU7M2qVITwQd5p/vqnbv8oSwCCU9c57I8JWJCxwbmUraUm9lq/Z7QKXY2eU4sw8+ 3/gYldd338+7LM/Hx+qXHz8xvwy+3temrsrkSRIyjf9Qdk+JMxIHeHSjZWJzfcNTlLsnDZPd 0/TZZ1Z9T+GPd5g3sX3XQOauzqUdL5bfV+EUp5HVvykPWhdspaJu6zyjTLs12bhhj2LjkoxG tn7UBuRujRAdPRwsyIdBOzHHtwcEP1beovx4Jqg6MCTJvyddI70NgL/ZA1VzW9T65WHs6J+3 dbWX9250jVi3pyjdMeAomSotXZmq24vcuRZpndDSv61k0jR37kFavWTl1Xa2HQ3abY7JOHMz hx8msuEx43lYHLdrvobkMW6QR4FLIuvW2H0x13dSJXrpdtSec+F0V1Ek4rvwGfoOj+MqWWVZ jpuXLvzzgRECOO8e/6YL7DhA16wkRT2LhY80jZ5Qq4Ndk62ZjAGy3o3mW3ffo3K6vbNooj8Y 49Prn8nXu8A7ZM3oGSYQgQv0JmhX7VQqREEQiqLIsgSIwFWKCkIIiybtJ6kKwFjEUimmsigL AgoxE1aO6WfRe2UITsw4kEjzoa30H+GKtxUE/onwhnDHfJT7I7oiGUAtBDSI9cOEA8cEe74U G4gyQFB/NGHmGE9DGJBZFCHwoQ39qNEaWwtFhUZaUbQAD8SEJ/EhCZwBEyYokGJhE/Ig2iGk AC8AkAQ4ConvRaKRddhXrsi9TupFxx+zjsiI5hDAVRkBU6O7k6echDwdVFq9lmvrP8t5MYK/ QdZum+iOw3j74cy7iDqfdLaEEGpgn5JR8hJ8pJM+9PaxPK60o6dp4bhhh/4yjgfCZ43lcZaN b0fq+blQrQdnQ4ZiHTrXhEfW+GDyo/1NrZgPpKDXoNq1clumODfWmSZpfQ+HLP14hCnmuaHw bAxZfb2m7HVoa8tmmM5XaQmZtwoOqg3oCOiZaRQcKDbrALUGNzHK7b122mNkubDWnruHXRRG 96rc3U6RhOMZfOjbZKt+4zYRQiZo1Tqfjlxz04tjuswMDXpXK1K3UVd6W55yJ1dryo2EPPPX 88Tx8DXu4YcdmhmpLMvkWmwg7b6DqxF88aZfDVPpVa1aunH825ZUlncOi0yNDkamrhXXda3V zRyMeX28O5cYeX0ywUx8ElY/FLAy4Yn42Y4tE291CzTtNEut24m7vAssbzMCvFOq4t263i5Y qMdYg5LYs5itOG8d4aMqpouYdwtXFQ1SolxTStKVK3lOYlwXerdzVAlsMmTUurpLysq0PU4t SyipVzWU0LNwYEMrSWexIeqVyLDLgMRZzFgjJdnFTSm1mbqQssFGGHxSGdbUHDFzlBRAZntc dnosMp6E1KzLmRbXDAmQ9rTGHL59uBo0utOaq3rF0mOsqJubvMWYgSsHJ2Vto8wrFJ9XHV3H e3FpNvbj97c29PS0i/gx22Wsi5g5jFikU+uEhAPuxf1xRSEQ4cJILdEBaRfmUFCvvMCguTxN N/A5kDrMCH0CWdlr8CBIxIRM/Q9+Mxnwp35XlqbAdBMzOM16txuP0METlvSoj5CHfRYCw2t2 Ga+AYSYFhXU7l9vjL03fd6dnO6/jbJU+OUsbn01ZnFpxTB5NmrQz5dZhj8UCyB5lRO40MV7z DXtrpu1KvReXpVgclyGlVlVeWCqoaoZjVuzEK9ss21g3D0FdLIZrZblrBuHoK499VGCFycXV xhEjrpTsqrepjYjWr2kaI1q5fRMKzqF7Os7t3XWmdPi2aOp3NRa0alGp3p143kYmcaI463wa HqNcTxIApwgj9RQQ9dM/x/C/QUTWSAnNHk7LWoo1akj1squBqWJRsIE0LOKfZu7OG5wyzDSs W22liWrURtYrn78/ezg0cdJrE1VL+RKbp14zrrfcUq9EL3MqIP9FIBZl4cOtP3pk7FoHDxv0 EIqxhD3v1UyH0xKIB7yNsEW/YgU36fg+APiPoQFkFRjEGSgB9YEPo2otN+7ztvIRF/gGdTH4 a7qukO8UfXW7k+Cl8W+9MWpaSjSk1CtZE1575LfGqo16o0vYUX5VFNe33t2G/nwz+ycileh0 iHS1ysuDmK70MFOMzjezCigSIndP9f6J03x0ZIaMNkKLu6AAMiIjXctBJFGC4SQ76svMC0p3 w2jK0u21iQzwtBwF323t4Q0bO2RreKI0VKYc603MtyduKHewUiKDIKBBRUHimP8Xihbn5rKT Zx4gZh4RigSwaxmls3TKiDKj+vysh3O8Q5LKMvh269tB78YfDQjVThSyblZmiROpz06I446b hxvhmc713vK7oAxjEIQAAhCAAAAEIQxjGMYhCGMYHcb6lSSLPafsc4JV8OM8HTuOnbJJczup Cc6Kds3hSh4QjE5ebz0yLRmW27dkzNfgixOkyEIENLRHy9ZNiHHPOj6enTwpsyiLWrBFNY7d QAZwbOHLjqzpuSQlSpgGILkKxCjh9WKDAm3Vj1FgAbV4iZNqoIJCqFy66DEG52zw1p1AUm0T gUDtBg2pZStMtCmjfmR1j2S5wq6YOgTcbIfQO02thmxWDLgfogElURGmSOhOIZMCI6W1dFmk 5Q5iVRhIABEsXNWWPfRazcgHCRQIE71f1W/OnoZPf7dfTedpdl4WS7s7h4lQrqIXpzN25eve UAADB6T1S2WWvDEReTlbQqEnHl5N68+OUyKpqqKmQr0TuVJAkcdlq+CpYjNLIg7rRqFBoa6D Y1hyrQ4qhSqkrIrQV5FToekDGkrhXTseyh2uCVLKC+6UI12iqW1Ykbiy/dUjLUm1KqOlfT0H 7dld8o9HaZ97ikSEVcIaotpIZl2T6t9SX1dG9ezu0vt4WlTUOIUTuwVTch3LyLZbmCJTM8Eb a2M77rIi6e02iEpv1/wL2BryV9cL3kpI73eK96TAMwf8vrcY2ZGypZe6E7v0HUZ+QcK7iyx9 cy+ggyo6oEQo3kpHcrEEVb46QUx2YdNeJfwhRzMyEglqvwkSL05ejKlpbIoSCjMkMwqj9qOP VrMOE1URqmkCopmRQLWqibt3DPLhM5tDup7wsQ5benBjaa2Cg5lYJaAqoe+et1hluwhfg8ev IrAvQYWXFrw08BbPV6Zoe2yqmxYarLTMA8K4kkZEFuGVrhqchVysyBOAdUQKOYHVgApCEQoU 8Onam0Z42znVRUzcvYhosMsbdRx02I9A2e+F3PVRXBJcLDuWpYmoSYJPKtRVjToMiC0wSbDU CWWGDgTGRNUn76Dt4IxQjaSFBIIB3UBEUh04l46s9K+zq/bkmG4dgTdLeA5Vl+G9Cjo6RjhX 5qYdvxh8uNF5rP1zwXX/Ib7DpxLrbLnLB9LqGvF60nRQQzZMbHSQ+oGhAGxClEQIHU+P92++ uF32xRsXlXlu+aaqFrQtL9Bci3u86MRCt0DuztUVdRmsanWhbKGwRqlvBVWZlZh8eHK097ST qI/MCqw6BI6hAxAUhwCgQAsqB05vkaXmrhsKqGYDmpgQ22CWoQ0LKijFTEp6jduN9Do82Fg7 NsvTOI01HNcWsHtFxDcOxednyYlkhpcy8zkhXNlUx2DyoHTWiVxBLkiyI5RcRTFYo93Dj1am yaZcL3XtubdW4oiS2PLlmeFcmxODrOJ0m3alaFB6qsy27LtWqqd9uo+O9XsoXd2302nMidlX QWSPf+wn1fZJ+2yLzmZJASQZ9/ZexDTcPeZv2Juo3kazHpHt7sxLIKaXaLRWmNmVYrQvafz6 1OdP+A9lX3/Rjy/PbH8siUKGNy5F+aAW71Wr6Sw+WCXh1CALhQiEDGir0u1ya/xTt92xwvj5 pywb3wQWycaup7V1oD6Uwy97usVbvti/cnE713u1d29m04GENRjUwKqn/k8LHbvg/qF+tWzc 0f9EUTEatuezwm9lf68p5qTFwmbCQ6Ez5wf077C69PjSWBzB795hSEG5RIzzv8DP6/vTv3bb 66K3ksMeFHfvLVUaFhe4gWKicDg+8Vds6R93bmwfSz+MTo7jH7fXj8aHxPmQUnw9W3ChVDGZ PTZXNJqKzrL5ShWw0l1pic9ijhHQ8F7vs5PcmZ0Xonm9xzxg3yz51U71iijNBvTpCTuaob9a GsoZRCoIkZIY7EY9ycaiFtpFqlGVbtZuHjff6feydkUUVZywrWAVUrK1SdJCTF/wylNkWFKW 420cv2/tuLre9Rb9+Bzk3KAxwkpGVsTVKZVlQnvVBByReiqbzLBW6+5X478B9+a7999yDdrc 0plF7yT3KWKlGW6VeGyKFo9uHbM1JmEmSEkmzW+wYbXJT6tJDMToCg57r8b4v08fNfdUpoVM hhozyzqgUC1oCE0FwzDoED1oDzacRLYmJxWqqDjFWCbEBRgcHYNvOmPCq3z09WufDoiD7dmy zIi+BOMArh9NVVovQ3UTvLhiuoGz1A1ZyXXuzjDSUdWuzplcixI0RYjollCr7eWsEhLW05XL kBJ7R9RuOp5qoUMviwWNMEQ6tvAGhmbAOy6ewGRhpZXhFsL/isJvsWmx5Vcvir+fXI7Ox4WW lOq/R8LMCMKFsbpc69lpGL/HG0u1YIoRy8yjWLzVelXzRouSrs5Ul1qLuSnKyCC7Jbolz3X4 X2VyJeFwXYlE638jXd7vP69K2U39urq9/Dly1brFd5+Hs+dv80d6A3wU/Q3oQ5IgloH9VNAE D+0KairmVSJiSDIf6Tp7N/WWQud116fwzO42I/0ou9US/Jw7+qukM1+2fmzsIAZ5aIsx/uIF 7f3iIjZER4kRH5fqfsEQfQeQ/wT+uiO/X/pj+JGfsId6yT+QQP5R/kv7qYwwrtzPRoKFeZJD +eEKMGn+mhoatZsr/Sfw5j/1mCOBkZNOdDQ1djauprqa7Q03baNkHEAoxSQkKLsb3oURWUIS Eg2NIhiBcOx/REZB/5919A/Wh0Bgtujq4PQ/zzKA5+AE/sMw/aarXVFsjpl4Q7kOz4iWCWIE gaUm5/UGNgxTDCGMWoyD+XyfZbpzfoS19PlplUUUb9vsD5f+szIhz/l+4f5AoNsIHD+rL2J3 zBDYR2g7+T7yq37AzEHcN222H+AO1dTfnwEK1feMRX46zQsW18juzx2dIQDZyP3cS8iwiPUb CJJheXXPI0RZR2zYYuiI5xYQRBi2HgD52KIxysh6dkhSGijoGXFemlN4H7kQ9KLc2LnbE+0y kYQ169YQzBRmPLzdELx2hJBhASQSa24zb+zhJggbybwbnMP5il/aIkd49qrfdYqpRKxq79JW MV9eYbtWhD0DtTcpEP2URgnvDQ1lD3guN2I5wIHvoNm/tKdRvNnhRDsoQ3WvsLifs9ZDYZ9F H02T4Dd/cvMHnLrwb4jDDdD1pAU8HZBr7m0JCuUNAZ44tGGeyDIvYYduy8G2DZDMbjbemSSO TfY7rMTD8UjyKYTbX0/ouJMKwwLE1S8Zm+7bD4nepErfJC3QF9hb6DbcU46OXJ0SKi1PoPQW FC2BzcVwDitcIFOp9W0RB70FMQ6Bz9rcEMQ3u3bh84aFJuDAgJAkhCvGTDX4lhjipJf6hQDE uH1xiKEYGvS7WrDHYNnAwwNITepryeveLxL2c5Ehh+6UvJP6h0OFzFAe4XNtwznD3MeAGLGy bdPSdXo5gRHcBADa6TfYigWDARfto4gZFNE42gNADYfm/APm47WkLvNE0TD0NQi8xIQbH8ye Jq6XWBUCawyE9WCh5g+nHk5Hh1YKvRN0jPEl0FDn0CiERBwDAEZ9PvcgaQWDIgwBJFAYgodb CgiKS02T5KHITeHvsvxkHbhJfLOh91Mj6zxavd5cDceTwZkk+bw+c9o69OYPXT5nzedhHlRO ccW7tfHvOYA3r06b/X0M2DHW2r4D4Mww09uC7TZr50x2Z92NuQecwTWrRu4RT1+nit1lzD7k Xz90nl7dr/+p9jCcSYBD07DAf76KZch3c0h/XQKDXIUrXAKKCAoMJD7Oo7/Q8hEcye4/fDAY JlJCEhDKigzNAPaCg9rjqAmo9T9+OK74ncFGTfv+EFEEVGRkQSMRiCRRkZBWRYrFRRFVjGMV IkSJFViRkjJERURXiTxsO5IQHWuNePOls+gNgO43LxNKWFRmVP9348wTo9zr/e5cT5wLng8Z qiQnVSe63yNB4uQPnDfRXGdTzHTWBxf9KNtUR9z0RRM3rLNj5DH0fsxf1BOlHbEyYF/Ocgs6 +T/t8Tzc+r5KunTuk7G83G2AfRhHERB6HExvzuCpY+UPz8Dfc1Ki5uytuGgcolJvOAUbtym3 Re5R48B3mHaD8NUyTAIQKT6KzJgPLxI+OY3IJDoROryfYFMhIEIMDZy85/DWTPLJMn6pc6NY fJu4V6KQyhjdFEcAUecLaz6JI4HTmPUeBeQzYanV8Gaagy0AmNb4PXxKHe41dIN4wn5xIfmy 0HQz4GYTiHos55N6THf0PqZuAc9TFo0z7vkx/n0g7fcduJt7725fb8vNONIOB52cR4ETxh5X twMWEIR+1ophCDERERH5KURtKMRP+NsRiI5S+3SiIiIiIny0+h96QhE0IiIiIiIjPRSjhSwo Hud+GhEREREoFKJ1pRERtLaFLSiIiIiZcw8+FERE0bc4+AntIY2ZgfMHY88kkIcsogGDkExD 52hH5PeNc3N5mci/Yi39Zib921EKuD9oY2t6nb92AaaKeEg0iWB5oAaaIVFNi0ochjc1FkPN XL5aQlFYnpoPJHnMmfRChgVy3/K7gBaAflPyxxsYGNOVDQVkYyMhyV00ssyBQe05nSzlOPqD yH7JfNSafSecHlhjMd12TwoCAtuYHIRKbLDCgTA0A9nn4/OB4mOf5JIFZIKSAzIxaIMovxov jskw9BIXPHjnxAQzNQmjqyoLkr279vdgj6w5e85A9OPoDoB3mZgSxLHw3qerLodqG8j1bPHA +fGbXhlqkBZg/NmbkekDqkYbGZmNNWpj2FXQoEIDATv7Gtl3ESIdW81kDsyLm3p1rZbZWRTm QNQGIRECMEIhFG4REaBIIjmZm49B7aJ6a6/S0fnKDAy93kQNTFZBJCxyGcy08F6bWvYui0ym KleUEaBSikSiJIjUEohG/nNE/NUCWLt9OTDpITu4t+LXtKgfEDEy08mHLfea7i6qqKukuyoV XWnTfT1nYEHSoWG8+hfafwPrtB9jCGRGvb6bj5KIGmaYUb2amMsuWwDHqfEhqU7IA56gUdXb xOg1+fW7MSGMYEgSQVCoEdHQe8iX/Yc54esKPRaThoHN2vD6rFQPCeyHy2AzzjlGjrCjFNz4 7FfvjiiHrSBD5nb7A6QfUWa4J60YecBHu8RY8XYdoZMVVrGtx2LduB3OG0q3RxSCdgwZoYLc dxCSSFPp8rOu7ogYfF2YOkxLzdrdmO48QPW0jcUIjttKD+eJzTwOB2u85uyY6/042AHgE3+F hdlgUbzMZkbmPiPwDVtgGTdmrNC1k2JwD8cRzr4bPmmz5mGT5/qU9fywRfGEmoiogm2+7nl+ VTf+P3yv91mEIZOpaGd4Jned3jTYzgH08XN3Ig9sEQePVYNkA8j5PtDz7H428Nqur/j8+hfp EUbA6XB2GF1C7nlDrWweb7T+9fetFx9qj9J+su1/ojnEJMjOpG9umvzyH1Hw8kQdMD2cYQIQ IBxIH4Z5L7VYJhDOCDRkwWlyGGBnGY0fox/u1dke7WJoRZTrUK16+tSsi5D+ev1N1zve+SFy HJEd5Ai8cUIQIjSU3AoEHpAEfp0yGR7Y2JdTFARtjTnqPg5Dh6p/fOQR84TghAlA0C0vbqXU SaSb2x8+NUY/PsHmGomadSiO0s3jrv4megSYfK8xiKMYNp4zXKGHVIQGMPudKaGRjlekkgQ4 HGpxCnSaOQbMjNELNUP6SzQmSFONrkGOMIzIJDSGD7EAdjITCTRTGIJ7SI+Y9spcvfRlBkUs xj76A9RmUDhDaWmluE9saI+z2lNxThNNh+/ifZxDEaIO1f4pQqIdf9AbrK5aGrQuDgmNKm4s zKGwrjQCazdxKMEArqoCMU1YGDEVw+/cFlSEXaJF3jHQiUR64WgnJ+YHA0+Ad8gCwulDSUZZ 5vNDbBdkUOkQ56FHOHKCgUREOo/IHSLIskJEkxhnjuJ+I1hlaK/ntguJwb0bOrsyQmpU8wyF 0zSeEdYWUlB02vgoSQHGIu5WHlIST8isFgIgorBSSMREVgAjICkEVEQWKyRkmjp633kUYMj1 BoM/WdeIsUI9QKBLQX2vUY5qnrJklxkTOG68cTB2VJgDbk74paPVwRizldB1uNJWZQ2VtX8K qwH4KJ4Qkf8yfbqHHBQWB+xMTSQ/KgbSDBU1aEtqCn58wnCXVkQEGBlkMTFdsS5izhN7KIfa y2i274wBBknRgoNsFJfEUOE0MYk0kWAoIgLI7shcLCpFkowqSevCgMg6sLDTiTodeRKWZbLb RVEiwsyhZnX/rrJr9t40UrOcKGIG9lAhohNBYGgm9YawaopBZvdMFGG0rFJWVKyF5yGGRFWl 5yx3Sia5JhJpEdYuwIx1ysTExAa3UX1YtZBjFyjYwknQQ0kdmhkyMQ6JKDqJwYXolEMEOtsY w3qFhUigxYIDYUDT0ZOrBEAUESAsixQu6BB4g9vghRIUkYfPRTzw6nhQBy83k8M1mgrifE8X momSgyWUhttUGE7JkfzP7WAQJuJn8KvE4fL6TQhzt+MvDhS8bzecJDGHmmuU1GFh2T7hMCaZ BWhHUByZGAjDR+sYnwzie3fgz+zIm1wHGfM4xKMA9vzKAn4VIKigwYKCjCMUgw6nkNhPq5h5 dm7eN0q9CZfFyIBMytMrnX1JWP1Qz4TZmazonNVKDARiLIKQEf+LCxOHQBhY/dThb4hb+Ynf OsOtBX3QDpCw6MjDHpl9vN1DN3nCyiQiEICMCPnctBfljoVu/Fce4XeGKFTUG3o7oQyTt4A4 5dXdnlzMLIdZq5k5faNi0ACW83W0LQuYuBA2Y45KeRtB021DU5GlUU9UV70+awkGRIwJA1s3 cT175cLfWZSaHYMFQukxuGTDA1bqNu/k80Q5r05D2APXEQov8iU0fLzlhig2qVQR9mSlyWYV HuHbDL0yrih+UNAsR+Slku4Y69gV2U+7us7Oc/kTibsOJDFNIVecgs1tGuMPu+JQmH8KDicV No/iHyPzK6wXy1oekiTcalGWSdDj30Zi/XszLKzvG8pPyxV6SSZjINbmdpWp4jAwANWpoxP1 Cptgqd0Goola0PkIE0kgLA8QksrKk85d7FIb3g5VZvgZlZ4JEVkHET1OqpShgAhCMzHp6UWr NzVnVtRSiWgNyS9HDDEfXo+TV0nUcrYhbSUERAilNLzmGQJC6Ipizx6LoVvvTKW2222yWowL kauOYJCQO2n4ljBObkwFvZbxxCuyYnPUCW9BJUCm1rebrXJanZhp8uzCGxkJVbuAZnDq1hbx D/DK4uw2nxCHEzsgcDbUZGIF5IBAgWntxvQcbyGyHY43LQGQQcOUyndCThoTEdPMewhjZwTh WUCEsiFOwyOHMSuh/ittMPmsgkh+CWGwl+nJDShlDZvMdGH2Ve5DEhYbDoIiFjeSkeJ5HK9z CoieLvZ4b9GrPIJSbGAUUVkUSylBZlkxZBBgYwpACyywrqMoioRCQU7kKHdlqvr8eCDa8ePg Xzonf1/WeQe4yxLvUvq4Xn8MhoR/JDc5zm6FKkSUpJ5v/FQjXbB+7qdDQh3Q9u4DCjaUE6WE lGB5iNOOEgU89zWQsgb1wDxUqXWqlo1c0mwn3kPgbQqSQp3RD1Rai/I9hbkH6+ALXGvPKi5C /poBuR1fEDE9EO473cjrARfUREALJmOh5MRAu4EvSZWAz1yg2HsRe/rHt6cMOzCVUICd3t3h 1IG8pADg0GWUakahECBMPRtjWpl4u27MqE1LNaRDbIaQ5s4PPoCc3VxmZq6o4lIrJDZZVK1G aTSTHSUQIjFAmrQK7ZMBmD96MxjHTAT5sMSRebREjBeLiYwbAva9XXIF44LMO1gbOxqcjqYO PFdKTMdkGvqORZfZr9W4yd8hmJ475FgPcG50D0BRIiCqLEgk8PQQGCEAXEqDIgpqmfI38mb4 0ECSRRFdndP7CQqSHKWewYo+x+IxW5Qw5e8m9erhcosOMMt7DggNHChFD/Ii5NnfmyB3oGUb m/NHEJq4ytmbn/jv/0t5IOREO3mTOCHHeSSG6JwBDSLrhmVOZfuMaGp0rKFj+EPfH7uwgj5r e2smh9575A14N6cG1GulE+rPJN3Xfwp8rlYuXIRJCEOobGm0uCEsZE6Xh6bJo2Uk7CRN2gom HSkhtkcOEw8RDlWKFtFOvx9r3lw6DqbnGZuPyt9jOBo2eCHKaB+M2QsKLAGdJ0kJosGUCuAo o3zLXijc6uGeF2xEunHznYFODIgUw13rhTsUHbQVd7adBcWWgo1Kjx27PKGultCNjQN17FI8 Pn3F6PXiuI42gOhptpvee8cmUDCMIkdLqtqCdXdF27GByguAs792rdR1WQUOTLsQr5LOFfTh XiKRgIBA5Qzjs6ulMjgAFAORuGO1E+nYQW3nts0OsOqxEB0cIiMCx6sKtMbnsM4cCgeuoQoO vLMAVB4JqQgoTXWNyIQ6ldC40qsdyqSSEQKeTOouoRAEoaoK7d9C4CoSSN+GsF/IoPiSErpz 07tup69WTYs6uXLOrlHd2cppy0xldFsx01VU6W713muHrNwkexuQYukRAFFWJfmgFqGSAQCQ iM+7qgshyrLg3aidW8ma201xrjRTElcVKlzGlaJNwokUqu6iGAZU1pRkhZFvj5tTVsBYA7wF 4BAzDWb8BtN64dDJczQhMCUW1TBkkcnIMATQNwZiZhkkzetdyYCwxziGgH4G0eLUEg542i2O J16q0dWWC7QrJMmE208DxwN+MRWKiB+Mp3rIZZDqdfL+ikhINM6GRZjaFwwE5yGX+YXXN6JB gHpDGE3Ft43pdFxeBreaS1u7SAh6lS/k4iIARSFRBhARhA5TntRPC5nGatCazMhpDTiVnYOt 3YP0G/BkQV694Sl7zjtn6Q4jkEAAIBBEIQi9ICVExBVDnwTxDft9SZyczs1haKya8fT26JyG pB/QCSRiRfFACoIgkQSMWAyJODgT6LS/OfgtTQH0RBLoDUujHEDo8RmNmwZqhxoFXAVvedIS EhIi8XMO/TviKGHg/NnIyNAdXCTr31ujRVGaJ35Ogr3DnSKwbV9oMecYjYwgw2iHEDw6ybyO 8c4AhkkmYYDuEAMOGT6Y+fWjco0NDUpDIYIgmEpEywTCeamoSfbAeGdANTIDjWDGdqKXDKNE Lempyhd0gQNLUM1VW1xYe72s1kAgBsMzMkNauFWGJpwy1W3GVMQ6wwLI7KbZTHwzfo0Uq4Af Cu3vLxgIqinfq7HEPBPN4b15WxYiq+HkuVLAyD4k6uHpEgJBAjCBFgSEU6rK9U4pv03mVhzY eUaIcqK7iOQ4xJfPs2LBu23cKSKK2IN7TryIMRl651cLTY5vqHe77TuJEzoKhD5AiXwfdfJP dOnkycZb7VgQ1qozLhtmfpEREVFRRUYCiookUhP0tUVFVUBVB4JaIqE6JKqojDoe56g/cwIP fjt6c+BuFDLeMoAejACQXBteYJ17Xt7Gbu7kbUIZlotivY7ggJCAQJHSJggOKdhtqlPnqvfY 4sKkMMm5DQgfH8yO/puONStrVa1FUtoqqKqKirMpVUUFPntltFG0n15RRSKKxTdLpW5aqKqF QGXLafXbqlbmYuKFZrjI60KMclKKumFUiJXWVPIQCQQZEiSOylK7SRzBO0wFctwxNRKKyESi hEIGAyNQoNsavger0ntB9wEikAUkge2FDISZIElBEBj7EJCJChaRtz9dC0kDfBPa9GeGDkFA XAIGxNEhnZUXAEfxIJgB7Gi6LgGn7Yitz/A/WGDCY9P0yaH3baShI3CDdnCbcFwLSB9/TgaB MkH4Q4oacCthJ2E0mHlAJUkjKK+dHFzMBn/K4Vb5EeE5kObbAfAY5ZAXVEhptr3H4dlwHqzl dL3cidxc2jPnLSpdoNiYUfMFg1PsYKCgoIlDEJAoMCQkOjIqNxRMEUR3diEdSzKjVL1tstUG Dfee8UcgQaSZ4JAi8oVpTJmP20c0vUkiUgV7CWdC8kWAQwKWCMEirEuDAFgwihBqUVgwZUY1 DTlJC8E8A3iqFmoOdjWYGH2aGIO2A7oLqQsTaP7QdIEe+JH1pg2YjYwvf8F2QHWyq1oyxUZt h5Jsnn44Wb8t54DeIkylQQN2fgLLTDd14XLQUAgHzjDQ5T0mIXAxGokJFYQViLIwEiJFD9SV QSIiMiMiAWMeuc0qNXPgix4iMmJl2ywCTEyVbMZiyZ+qyZ6wdqPrBhIeJkJA5zN+NtSBLHFy lrvviGp0o5jaFwkkgkXPAD7/2Tvh0P1HsruOSwu5c1ApOURkH/hbyMGRFZEPP3C7dofSLZt4 PLgApeA9zI8uVdifAPmXzuTu6xPrAqhpGIF4ihYkgj4tWF89cb5BhmqYV2ooVaC8JmWZQsEk ZLmEqQLF3ZKh3nf2h18YGZmGfPomYnfAkReM+MgxEInqfA5098gsiiv2sdi9rxW73JSn/DJY 8qnb9kbC3It03CC7h4Qycv4volh75YZCi1oi+kJOYuhfvmHGtQ6z7TIDM7T9HjXLJYneiicE jw2eEhvnZPc7tY+kSQkSAc0wfNu4y26AGzUADXHSm8/SG2yCOaYlpz8acZhfROcU91rY7MiN CFzeQ0SYAmkEd8cOZoR5EZB+5vRIstF82JY+P1pfd04RLpj1sM1vOwyLxWKsRPkSjZx0AzM0 dTatZNjcxHQedDsdydDia5s3aaSSflYiflYE5OfmzGYhxsvCRYIyRTtGAYmyE2FgYE4sN6A+ Vu9Gy2cboqIP02csNsm0hw8AmJWuHP1JCRYSRQFIAIkAWQIggCkV9r+ZLplT2DIPAgSQnDmq nIfWK5IegzRz/QkQUSLnkdaLBJCQCuyhyPI+auO+hrDrf0cWFnj7Df4vxHJ1hzATgMZGEiQY wq5D6+416IuDgmzN7EObzg0eQVQ0MMWbWJQV+soPqkgNowZF4VT4IFiUpnYHAmz9u340Udhq IcPZ8wnysqwUkgxVCRUIxZERhFpKUOL3M8PbGpYr7gm7pDWQ36FEP6kIaVO5qisBGIzSKFZG 2HKYMEScblhggI0obhkkA9QxA4PQYGwzPkA1KCR+zRmtU6cQoooHVA90FMwMh6aUlKRXWAXG S/GiohdYU7aLObFD4ODMizMJQGaumN6YKBiuWgiSerzWGuKbOlxFqW0tLWDaGmGk8yRtgpIZ 0KQYiwZElGBIBnZYFx13BaF755qvhJCQkJ7tun8oRDZNivMPqMaO8qgkaXmUckOR3lBTypKJ C2UsgIUjQcNRTcnr7+OfY7fedC2olS/y+00k/n3c9ovJ47v0pAgbq5D3Bk7Dw8+Hm5Sgh0A8 Xpg5CmVGSd9ihU8bcSxtKSJGCrAZEQUGVCiqqKsDTYkxnjDAlJFIVsBAdTUosjlEwZVJEIMS AFqWpSHDQfRHgA7SJLg/cHKUdULCdoe9QkFYQYFB7IeYzvVEjYU0U6w5/ReT09iVonhHrk57 6hIYm++XKDudxEO+xrmN+fBtCoz8WYDlGHNiaPbsQbAwqB1nvQeGWMjf6baJJO/xxg+jI6pc V6B7AbMi5lR0IBIIRxjsalGoUZT2jkBJ4gV8HvHvm71obb1IanrQru5lZRDE3qaDSfHDpB0e B1sAoFWieNxBmRbLRVVikjI0RFrRUpWSxKCIIkU0gWbPos2j5P40b+neOxNDcESDuLgaJW66 /jnCw7Y7hdhAK8vCm4nbVERy3vdbRt3TvhTw+LJM0DUo01mgHLqm7hDXzNrK60h7B0bABZF0 wDyYFBgjiYFCK0cVKXiBzrcumahJHQyqjAhLFUwsKGUADFn8ORkYr22dC7t02ibrNsavCzBQ Si8Ml2El0Jc2qJgMTFqDvUGE4YVM1jgGb5ytzHELwQlQQYGYlCOCCHfouHlOcWSBGb5M4BVG Ih7dD87RO9hmzhixHcNA3IDTNx8ZAhQQRpnuJAYN+3ltPUc4JilN9HGNYaQZ1ZDFvAkDE8gk YmqUhr2QN4dggKrJwQkDYuIa3i4CXBWMgfroMTowiZUqbgr+pDAXEu6GTncg60ijnUuAJCol EEsWDO0ZOgcRUQhFIvcPeQpPDsaPTfTP903x2CckSCIgIrJhAxLaQUhQZPUGQbtx2QJAVM89 v3WodJPaf2CyuBULC0ojcM4htCg5xcGXggbk9U7AIpnOAGtHl6F6yTleAoz3VVzJICwCAsFg CiIoaQ4QBYGaIjKMNa+LQSSBt2CqqWGmyZIwDY2mTPV2wJ6wkHGcx+qTWz7nAPXDREmNuy6n GtYQh4nhD1L6iL2R5IGOFPgqgyaov+zDYBclmvR8TG+YZ3bTNQ5h1RGBBkJEjBkSQ97Bo9o8 LXChAkk3xKiQIKBfypLigZwZO8AdUYRHb6D4+E2MUWEknsaL2KQtBbkg3FZBIwJAIgU8w71H 1KQPKQ3hxA+Y8z2qCHQe0DwQsPoYxf5TdyG+VcFLKmKSMUiwgMQ6egN5ilEWIwyzzk9sAOzP OlQ5kyBT0JQdcO38ahVmkCHQbkO2UG7JQyFgAwdXYwItguXKJKe8cc4+U0GdSYqn4xeZNib0 OzrRcHgd6q5fOlF894bgyCJYqgoge6NokCiSMfXZg6dAZxDGYGD7S3XzU4kJA2iHoSyCppk5 fITmwOHnH+T8D994hllWcGLMgMP40PbFPv0NTLfw4WejxfZ8CBUVRXv8w+6vK6KCpI1ETomr fuqGOFZ9qM0R/17tJPgVPez3u6Gz4E+qBWNViKi5v34fKfd/wcqFH3sEZEH0Igj46pkGg6bA Dcc+01O+1wHZAQy8gbyEw19Wxad5npPFx67/mpnbDt6Q28Yq7wQpd2zVhnr+aAjurtdxBuQ4 3QZDfNlokJFcDf3P+KthWbSPk5ncfaDBMDlPJgo4CT3BdjP2e59hk5sMK4z60Tv1e6euk9jx dOlFWy2zVJGBoflOOxYn1bdkTrI6n5kDg6eeMIHVA+5j3mMnA1p9YW6eRN2w1fxxdTvJKO/9 gNySCSAnlzHiDYMzcq4W3MtauBt3s6iuBiVsYOjZGNnu2R0XJL6YJDRd/TKQ2zQJKTEgQIsB eGmDN58qZwN/VN9TRCaw7GJty9d0W0UvaZBIJv6C1lkz6jwOfMauses0DQeCBbFENGCrzOsE oQhz8IS2J0WaIXhCikEGRgHsChYJABGJHi0UQMLLFlI0QRMaJMY7h5WhkJNGWEaPS0wpbAiU qWUCjRGKqiEkEnNMprAwQNs2qH12qqoh5mpA+II1hDlged/hhJ0osVHbBawigeK1SYRU3x0g eZ8jgj1nA9uzXLltWuKL35kC98NpC5zYJg3/slaqvjC60p+efdhzGqQ45Wt3DRzhxBPligZw V3GvGx9fKekoaIjFNQbQIcchTAFAMPwp80h+hCYDgM+MMMwWLEKe9qU1PdGG3Wkt+ksAwy04 sJSYUC144HJXB8MB8h3YFIeuMCAxgLzdaCG4qnDhkYdAdYGHVD+hFj9fmrF758CIe0kF1GFt RWrFtgKCIFaeqBvpF2qHJeJBkVw31ucQCj6sZI5ZN5Y+U/mknQDfJv2DyxmKN2AShABAEkkR kgRBgskkpQRIlrv3osVJHoh4hNYfe8Q5/IWMYdHV7/Wr6N7wgGzq9NydOS9ZkH0tlX9lwhBi B5Q4zSdsS4YkbVBREDzwOk3JIsBmFlEARkiDJUscwRV/QhD4mR8hfugUIpBfJttzqj9tkOwg VB8WPteq5Em3YGqbiVFDNMcxmnL3u/tQchka66uuW+58KXwdc3Lk0WcITCN7mUMw6VEMzdR2 BQPbdXZXJEiWDK7ElCV5T5esfseUy7VrUVkUzFGYimhrewHJPaLJYkmZLZl67sId0NzhYDfY aYYnG7fQ+OXHi7hh0qe4D5tM/PGui5ypjp77v3Ru2+7FcbZzf7BFKwazo6OUm7b1kDYDAqhJ G4I3R0s3vtttC3GyjcpcWaqCGZiTaxN5dZSkTnJ+5Cb3SxKMH7KA8KfJV6ShcIAJ53RHUdB2 aUUknWFukBADmLe7ynFaSKRY7szBuF7GGZDME7pmOW6cYmVJS2ZO8tD+BuEVmV3PKKz7bMMw 92PYJSg3kPRgAHAENeUMOG8+TU33CaALDXeCTe7CQgKCveiKI80Q2RQU3EAV5Tt39ie84d+T D2deZepOSoczV3WeCHRxubuuhYGIuMNeMacsWMQyiuPLaQLtn4ZQqzCfA1LEMhUIwSbOSB2K eUh0kRxQE8PB4D1pdDI76aUG4cEEnIQxHlLlSya/gGaZoiKMSMnhSggwQeILyQYDMEThYThQ 32AhtgA6jxpgGebpM+Js5ovaT6UkEk7aekWRxneCG/s9LkXlySYr7GmKcoNbU6lOrdnib4Xj iHWdATnmvlvqqubDN2EHA1rDFkgTZyRbE1DgG7r9YPHmEAJup2sQgd7E9WHqHDiPkLeJvjMC 01GiILEJDIIohyVG+OGUfO10EjPbDXTyYj3gJMkkJEUgpP0yjYFtCDUVlo0aL5MC0auw4BoA BqQANwMLPev2ijh0dy2qAEzzb2uJXPMumjmZBwq4Gbom9XCqyfxIbVhoZOMuDRhTaKOva0Vr NqO0u0LImhRpGhvjBp7jsRM0bnaMbW5sMZKgoKEOVtq0aGXdzbUgsMZkeebIYiPAskHgGxEN hGhgyBoS5ahjAxVkI4DA0ESxUD3YkNcDk667/WvZD5WfjgZFoUQYHL1h5Cjilh8IsvhCijzN bvhnM8OJZk6GYRUCFKSsjWgpsyg36NZAjnSLUYARRLu0sBkLEJQEBAUlMBCiEIwg+H0Zl/Vn kfNq48dWsR2Zl7Kt0otVlSJqiUgKQTfN8bDr0OhgI9g6b6XXzmuMkiaNpgrO286Fs1BPGIV5 vc5IxEOAfDJHkwDIgFS5qGAGjnk41Hr1u8wCF3qfSZWmYhoXSCm8mZRSJewoFDJy103WZqjS whI0xvU6OoUCTpBSlKDs4oFGZDoLhXQt6oXmAQDEqCdrfeVILwVIRAndcAmLYcd2nXToIrpq 5NaCSQEeLeEs7VavNL1kJrihWENGo8YazTvu6QNDkKHknUNAYRIVJyMDDYnTDoJUUOwyMSJo jik2hnkZDYSBo5XFTMwU6aRFuKCWIyRhFCTQpYQXTTMO/dv0MEywMDuMTUqEDDM7DVfUm1MB vA/2JCQFQjGKkITxoWCDEZCLA7cjDuHXZ1Jvwf+mJA1EMFDJQFJomMS0dxImMatWqBd7ddAG BgxnCcm2c1TiYAyhiT4UWR1XKxi3UpCX3hffVRkkUkGZhsDkw2E0ABd0JIUYmKCqqDBgHs5x RRTmyTiE1GvN8D5dm3bl6UjImbUIapErFVciVs+xLBnAzlREbxsGSIO837NBqDSEdqDs6JsV srWwjqVLhwhCk46TcGvbbO7MzRDL4/u5Xsg658jljgcyhNILpHcnKy/JC4balmx3I9vMjOac G3s/F16mPBeSLwDbARVuXS9FFJBI0abDbxcePuzwNJtqnSluluydV4hbXbRsNMynivBoxgvK h2c4maAGUAMkQ0M3+Ix08YuMkq7Gnv/fQOTPSbTZyOJd2bDcdgRh0Az4G0Ds6AGI+EbB80Wc 5xwJi+MhoQ3htxsNjUdB7+n6Ty4d8EVboPHD+0JSUUUDxFNFlRP5JAZMk2RRNCDCKbzvUYPu 6ePAqd4WOHhzB0dDyH3bnWn4dIX+0ntIp0FWRDb3EL2gI9ykN0eH75u93MQ+1F/u0nj41oKE nGvMhE/IeVX2mY9niDhfonugUgQYnj9HJ9ehQiwUWKQwE2P0QDyicRDdKsaDKkveG+dIiXs/ Nj+mHwKx8GYbfFCoqj6/llII0BQDxqlx5Aw96d03jZNcDTIme/1dfq7j9KL4XrljWm0mR0Ed pvLGRJkoSdxYwzqbseG0A8uJjBgKwZBQEVFgwQkUhEcJIH3WLD30esjJ/htBeJD6mCgb6dDy HdSmUt2Q9ouBENnHgAajIGJBYCLBADnt388jQMSWXmTzgrnEXMKifZA0L1LKhbH8ATXn+g1i Xo/ITGl25mNFwAABJERGq1tWlti20ltgoW0BRRBnXMtawrg0MO+euInaYWNG6EtOo6EBwChw Rd7xpGS9MglIkSC+3ByAnFCmZT8voaFg4ZiC/fP/0/SEMszd3YEpUcKPEjksKh2LJkIXyk97 phvj1tETCDD8CBhiwoBgUraIYgP6wwbXWkzyTOzQCOU8pg1SQIC+gXNAMyCxSZRkoOjBHGIo p6AmE3QHOJ1m3wISGhVb6+xOnS3LZNbGrepaopq1guYkPn3KFp7OYKK8qLHdoLsSg4joH5BC wmPqO/bbDqaMe1yF/tBwGLoq8GSMYjkLoYmQQQ2hrhI7TaDxgHhhAgAyAoQYggdu4BO6MRVj GMRFRIrBQSKgKMBEIsUCVgHyjAmP8K6qDPxs/pYgwOPrOER/GwpqHQQCbmi4qKGGB8wNxVm0 Fh1UTruaXaf2uJhqmzoz/+LuSKcKEgWlW6Lg --pf9I7BMVVzbSWLtt-- From jimmy@e.kth.se Thu Feb 14 05:25:10 2002 From: jimmy@e.kth.se (Jimmy Engelbrecht) Date: 14 Feb 2002 06:25:10 +0100 Subject: [OpenAFS-devel] Java API for AFS Admin In-Reply-To: References: Message-ID: "Shyh-Wei Luan" writes: > Here a set of Java Admin API is proposed. The goal is to make the API > suitable not only for administrators to write custom AFS automation tools > but also for developers to write general and powerful tools for easy and > efficient AFS management. I have some questions. As you know the different servers allow you to do a few hundred different RPC-calls, is the idea that all of them should be accessible though the java-API ? How do you want to do RPC-calls from java ? Is there a usefull and working package that can do that for you ? You want to generate the RPC-stubs yourself ? Or you just steal the stubs from some exsisting AFS-implementation ? /Jimmy From haba@pdc.kth.se Fri Feb 15 01:31:16 2002 From: haba@pdc.kth.se (Harald Barth) Date: Fri, 15 Feb 2002 02:31:16 +0100 (CET) Subject: [OpenAFS-devel] Re: OpenAFS CVS Commit: openafs/src/rxgen by shadow In-Reply-To: References: