[OpenAFS] How to correct errors in prdb
D Brashear
shadow@gmail.com
Sun, 23 Feb 2014 22:29:57 -0500
--001a1133352ef53aa604f31e95eb
Content-Type: text/plain; charset=ISO-8859-1
You can dump it with pt_util, and then reload it; editing of the raw file
can of course be done while it's in text format.
On Thu, Feb 20, 2014 at 4:53 AM, Kostas Liakakis <kostas@physics.auth.gr>wrote:
> Hello,
>
> Recently an aging AFS cell we had online for several years, started
> experiencing problems: ghost volumes not willing to be removed from vldb,
> volumes appearing with the same id but could be accessed by different
> names... we traced it down to a corrupted vldb file, we fixed it using
> vldb_check and it appears to behave again.
>
> While dealing with it, I also did a prdb_check and it came back with this:
>
> [root@srv-10-206-123-246 logs]# prdb_check -database prdb.DB0
> Bad user/group dicotomy in membership list
> Entry at 722624: flags 0x2, id -269i, next 722816.
> c:04/16/2006 22:02:02 a:06/28/2013 10:45:56 r:05/16/2013 14:38:43
> n:time-not-set
> ids 10207 10718 10772 11072 11120 12059 12134 13108 13226 13247
> hash (id 0 name 136256). Owner 1i, creator 1i
> quota groups 0, foreign users 0. Mem: 57, inst: 0
> Owned chain 1155392, next owned 715520, inst ptrs(0 0 0).
> Name is 'webmasters'
> Entry at 722816: flags 0x4, id -269i, next 1089728.
> c:time-not-set a:time-not-set r:time-not-set n:time-not-set
> ids 13598 10611 11608 11137 12117 10027 11584 14027 12365
> -310
> 11123 12031 14013 11127 13010 14024 13241 12050 13728
> 13202
> 10927 14768 10001 13381 12478 14283 11944 12970 13323
> 15396
> 13197 10086 14770 11444 15628 11676 13216 14263 12686
> Entry membership count is inconsistent: 56 entries refer to this one
> Entry at 722624: flags 0x2, id -269i, next 722816.
> c:04/16/2006 22:02:02 a:06/28/2013 10:45:56 r:05/16/2013 14:38:43
> n:time-not-set
> ids 10207 10718 10772 11072 11120 12059 12134 13108 13226 13247
> hash (id 0 name 136256). Owner 1i, creator 1i
> quota groups 0, foreign users 0. Mem: 57, inst: 0
> Owned chain 1155392, next owned 715520, inst ptrs(0 0 0).
> Name is 'webmasters'
> Entry at 722816: flags 0x4, id -269i, next 1089728.
> c:time-not-set a:time-not-set r:time-not-set n:time-not-set
> ids 13598 10611 11608 11137 12117 10027 11584 14027 12365
> -310
> 11123 12031 14013 11127 13010 14024 13241 12050 13728
> 13202
> 10927 14768 10001 13381 12478 14283 11944 12970 13323
> 15396
> 13197 10086 14770 11444 15628 11676 13216 14263 12686
> Entry at 1089728: flags 0x4, id -269i, next 0.
> c:time-not-set a:time-not-set r:time-not-set n:time-not-set
> ids 12841 14278 13208 15078 11212 15651 13259 12842
> Entry membership count is inconsistent: 2 entries refer to this one
> Entry at 844544: flags 0x2, id -310i, next 0.
> c:12/19/2007 15:14:51 a:12/19/2007 15:52:37 r:time-not-set n:time-not-set
> ids 11123
> hash (id 0 name 418688). Owner -269i, creator 1i
> quota groups 0, foreign users 0. Mem: 1, inst: 1
> Owned chain 0, next owned 795200, inst ptrs(0 -269 0).
> Name is 'webmasters:alumni.physics.auth.gr'
>
> The cell has 4 prdb/vldb servers, 3 of them are version 1.4.5 and the last
> one, 1.6.6.
>
> The newer versioned server was installed just recently because the
> vldb_check from 1.4.5 could not fix the vldb errors. Along the same lines,
> prdb_check from 1.4.5 distribution does not report any errors on prdb,
> while the one from 1.6.6 gives the above mentioned errors.
>
> Though not alarming to my eyes at least and no evident problem on the cell
> so far, we would like to fix the prdb problems as well. Question is how?
> prdb_check utility is missing a -fix flag.
>
>
> Thanks for any input,
>
> -Kostas.
>
>
>
--
D
--001a1133352ef53aa604f31e95eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You can dump it with pt_util, and then reload it; editing =
of the raw file can of course be done while it's in text format.<br></d=
iv><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Fe=
b 20, 2014 at 4:53 AM, Kostas Liakakis <span dir=3D"ltr"><<a href=3D"mai=
lto:kostas@physics.auth.gr" target=3D"_blank">kostas@physics.auth.gr</a>>=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hello,<br>
<br>
Recently an aging AFS cell we had online for several years, started experie=
ncing problems: ghost volumes not willing to be removed from vldb, volumes =
appearing with the same id but could be accessed by different names... we t=
raced it down to a corrupted vldb file, we fixed it using vldb_check and it=
appears to behave again.<br>
<br>
While dealing with it, I also did a prdb_check and it came back with this:<=
br>
<br>
[root@srv-10-206-123-246 logs]# prdb_check -database prdb.DB0<br>
Bad user/group dicotomy in membership list<br>
=A0 Entry at 722624: flags 0x2, id -269i, next 722816.<br>
=A0 c:04/16/2006 22:02:02 a:06/28/2013 10:45:56 r:05/16/2013 14:38:43 n:tim=
e-not-set<br>
=A0 ids =A010207 =A010718 =A010772 =A011072 =A011120 =A012059 =A012134 =A01=
3108 =A013226 =A013247<br>
=A0 hash (id 0 name 136256). =A0Owner 1i, creator 1i<br>
=A0 quota groups 0, foreign users 0. =A0Mem: 57, inst: 0<br>
=A0 Owned chain 1155392, next owned 715520, inst ptrs(0 0 0).<br>
=A0 Name is 'webmasters'<br>
=A0 =A0 Entry at 722816: flags 0x4, id -269i, next 1089728.<br>
=A0 =A0 c:time-not-set =A0 a:time-not-set =A0 r:time-not-set =A0 n:time-not=
-set<br>
=A0 =A0 ids =A013598 =A010611 =A011608 =A011137 =A012117 =A010027 =A011584 =
=A014027 =A012365 =A0 -310<br>
=A0 =A0 =A0 =A0 =A011123 =A012031 =A014013 =A011127 =A013010 =A014024 =A013=
241 =A012050 =A013728 =A013202<br>
=A0 =A0 =A0 =A0 =A010927 =A014768 =A010001 =A013381 =A012478 =A014283 =A011=
944 =A012970 =A013323 =A015396<br>
=A0 =A0 =A0 =A0 =A013197 =A010086 =A014770 =A011444 =A015628 =A011676 =A013=
216 =A014263 =A012686<br>
Entry membership count is inconsistent: 56 entries refer to this one<br>
=A0 Entry at 722624: flags 0x2, id -269i, next 722816.<br>
=A0 c:04/16/2006 22:02:02 a:06/28/2013 10:45:56 r:05/16/2013 14:38:43 n:tim=
e-not-set<br>
=A0 ids =A010207 =A010718 =A010772 =A011072 =A011120 =A012059 =A012134 =A01=
3108 =A013226 =A013247<br>
=A0 hash (id 0 name 136256). =A0Owner 1i, creator 1i<br>
=A0 quota groups 0, foreign users 0. =A0Mem: 57, inst: 0<br>
=A0 Owned chain 1155392, next owned 715520, inst ptrs(0 0 0).<br>
=A0 Name is 'webmasters'<br>
=A0 =A0 Entry at 722816: flags 0x4, id -269i, next 1089728.<br>
=A0 =A0 c:time-not-set =A0 a:time-not-set =A0 r:time-not-set =A0 n:time-not=
-set<br>
=A0 =A0 ids =A013598 =A010611 =A011608 =A011137 =A012117 =A010027 =A011584 =
=A014027 =A012365 =A0 -310<br>
=A0 =A0 =A0 =A0 =A011123 =A012031 =A014013 =A011127 =A013010 =A014024 =A013=
241 =A012050 =A013728 =A013202<br>
=A0 =A0 =A0 =A0 =A010927 =A014768 =A010001 =A013381 =A012478 =A014283 =A011=
944 =A012970 =A013323 =A015396<br>
=A0 =A0 =A0 =A0 =A013197 =A010086 =A014770 =A011444 =A015628 =A011676 =A013=
216 =A014263 =A012686<br>
=A0 =A0 Entry at 1089728: flags 0x4, id -269i, next 0.<br>
=A0 =A0 c:time-not-set =A0 a:time-not-set =A0 r:time-not-set =A0 n:time-not=
-set<br>
=A0 =A0 ids =A012841 =A014278 =A013208 =A015078 =A011212 =A015651 =A013259 =
=A012842<br>
Entry membership count is inconsistent: 2 entries refer to this one<br>
=A0 Entry at 844544: flags 0x2, id -310i, next 0.<br>
=A0 c:12/19/2007 15:14:51 a:12/19/2007 15:52:37 r:time-not-set n:time-not-s=
et<br>
=A0 ids =A011123<br>
=A0 hash (id 0 name 418688). =A0Owner -269i, creator 1i<br>
=A0 quota groups 0, foreign users 0. =A0Mem: 1, inst: 1<br>
=A0 Owned chain 0, next owned 795200, inst ptrs(0 -269 0).<br>
=A0 Name is 'webmasters:<a href=3D"http://alumni.physics.auth.gr" targe=
t=3D"_blank">alumni.physics.<u></u>auth.gr</a>'<br>
<br>
The cell has 4 prdb/vldb servers, 3 of them are version 1.4.5 and the last =
one, 1.6.6.<br>
<br>
The newer versioned server was installed just recently because the vldb_che=
ck from 1.4.5 could not fix the vldb errors. Along the same lines, prdb_che=
ck from 1.4.5 distribution does not report any errors on prdb, while the on=
e from 1.6.6 gives the above mentioned errors.<br>
<br>
Though not alarming to my eyes at least and no evident problem on the cell =
so far, we would like to fix the prdb problems as well. Question is how? pr=
db_check utility is missing a -fix flag.<br>
<br>
<br>
Thanks for any input,<br>
<br>
-Kostas.<br>
<br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div dir=3D"ltr">D</div=
>
</div>
--001a1133352ef53aa604f31e95eb--