[OpenAFS] How to correct errors in prdb

[Kostas Liakakis]

Hello,




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.

  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

         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.

  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

         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.

  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'








Thanks for any input,

-Kostas.

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. 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 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 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 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 c:12/19/2007 15:14:51 a:12/19/2007 15:52:37 r:time-not-set n:time-not-set 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.

smime.p7s
Description: S/MIME Cryptographic Signature