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.
