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 <kos...@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
