(Illustration by Gaich Muramatsu)
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