Coda File System

bad parent pointer - codasrv won't run

From: Greg Troxel <gdt_at_ir.bbn.com>
Date: Fri, 10 Nov 2000 08:46:53 -0500
08:23:34 Entering DCC(0x1000002)
08:23:34 JE: parent = 0x1000002.451.4d46 ; child thinks parent is 0x45d.4d4c; Shouldnt Happen

Assertion failed: 0, file "vol-salvage.cc", line 830

Looking at the data, it seems that the .. entry in the directory does
not match the fid of the entry for the parent.

The problem directory:
 norton> show directory 0x1000002 0x451 0x4d46
     (0x461 0x4d4e)      test6
     (0x45d 0x4d4c)      .
     (0x47 0x380a)       ..
     (0x160e 0x4d83)     m1.tgz
     (0x1610 0x4d84)     ship1.tgz
     (0x160c 0x4d82)     m2.tgz
     (0x45f 0x4d4d)      foobar [names changed -gdt]
 norton> show vnode 0x1000002 0x451 0x4d46
     vnode number: 0x451 vnode index: 0x228
     type = directory    cloned = 0      mode = 755      links = 2
     length = 2048       unique = 19782  version = 8     inode = 1455748780
     vv = {[ 9 0 0 0 0 0 0 0 ] [ 61840738 205 ] [ 0x0 ]}
     volindex = 1        modtime = 919355660     author = 10853  owner = 10853
     parent = 0x449.0x4d42       magic = 0xad8765fe
     servermodtime = 973539631

     Vnode Resolution Log:
     **Server: 0xc00164ae StoreId: 0x3af9d62.cd 
     Directory(0x451.4d46)
     Opcode: NewStore 
     index is 199, sequence number 34258, var length is 68
     newstore Owner: 10853 Mode 493 Author 10853 Date 919355660 Mask 1 
 {[ 1 9 0 0 0 0 0 0 ] [ 0 61840738 ] [ 0xcd ]}
     ** End of Record **

The directory in the parent pointer

 norton> show directory 0x1000002 0x449 0x4d42
     (0x802 0x4710)      README
     (0x449 0x4d42)      .
     (0x47 0x380a)       ..
     (0x44f 0x4d45)      demo-plan
     (0x451 0x4d46)      demo-report
     [other entries censored]
 norton> show vnode 0x1000002 0x449 0x4d42
     vnode number: 0x449 vnode index: 0x224
     type = directory    cloned = 0      mode = 755      links = 9
     length = 2048       unique = 19778  version = 10    inode = 1457364300
     vv = {[ 11 0 0 0 0 0 0 0 ] [ 61840738 209 ] [ 0x0 ]}
     volindex = 1        modtime = 921070721     author = 10853  owner = 10853
     parent = 0x47.0x380a        magic = 0xad8765fe
     servermodtime = 973539642

     Vnode Resolution Log:
     **Server: 0xc00164ae StoreId: 0x3af9d62.d1 
     Directory(0x449.4d42)
     Opcode: NewStore 
     index is 129, sequence number 34262, var length is 68
     newstore Owner: 10853 Mode 493 Author 10853 Date 921070721 Mask 1 
 {[ 1 11 0 0 0 0 0 0 ] [ 0 61840738 ] [ 0xd1 ]}
     ** End of Record **

The directory in ..

 norton> show directory 0x1000002 0x47 0x380a
     (0x449 0x4d42	)      DOCUMENTS
     (0x47 0x380a)       .
     (0x1 0x1)   ..
     (0x45d 0x4d4c)      FLIGHT_DEMO_STUFF
     [other stuff deleted]
 norton> show vnode 0x1000002 0x47 0x380a
     vnode number: 0x47  vnode index: 0x23
     type = directory    cloned = 0      mode = 755      links = 11
     length = 2048       unique = 14346  version = 103   inode = 1459446156
     vv = {[ 87 0 0 0 0 0 0 0 ] [ 61840738 214 ] [ 0x0 ]}
     volindex = 1        modtime = 973539792     author = 10853  owner = 10853
     parent = 0x1.0x1    magic = 0xad8765fe
     servermodtime = 973539792

     Vnode Resolution Log:
     **Server: 0xc00164ae StoreId: 0x3af9d62.d6 
     Directory(0x47.380a)
     Opcode: Mkdir 
     index is 131, sequence number 34264, var length is 33
     FLIGHT_DEMO_STUFF [0x45d.4d4c] owner 10853
     ** End of Record **


So, it seems that
 dir 0x47 has an entry for
   dir in 0x449 has an entry for
     dir in 0x451

So the dir in 0x451 has a bad parent pointer.

Any clues on how to fix this?

1) I am tempted to comment out the ASSERT (or add to skipsalvage),
move all the stuff from the problem dir, and then rmdir it.

2) use norton to delete the .. entry in the vnode and recreate it.

So I tried 2 and 

norton> delete name 0x1000002 0x451 0x4d46 .. 1
norton> create name 0x1000002 0x451 0x4d46  .. 0x449 0x4d42

08:45:29 JE: parent = 0x1000002.47.380a ; child thinks parent is 0x451.4d46; Shouldnt Happen

So I'm not sure if something else bad happened.  I'll keep poking.
I'm partially posting because I think this indicates some sort of
server bug.  It would be cool if the salvage could fix these
backpointers a la fsck.
Received on 2000-11-10 08:48:37