On Fri, Nov 10, 2000 at 08:46:53AM -0500, Greg Troxel wrote:
> 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.
Ouch, I'm trying to figure out how this could have happened.
Possibly after a rename,
'mv (0x47)/demo-report (0x47)/DOCUMENTS/demo-report'
while weakly connected or disconnected and only the (0x47) directory
got resolved successfully.
> 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
Which is what I would have tried as well.
> 08:45:29 JE: parent = 0x1000002.47.380a ; child thinks parent is 0x451.4d46;
>Shouldnt Happen
Is there still an entry for 0x451 in 0x47 as well?
> 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.
Yes, although RVM transactions should have given us some guarantees that
these things don't occur, except ofcourse in the nasty case of partly
resolved cross-directory rename operations.
Hold on a second....
08:23:34 JE: parent = 0x1000002.451.4d46 ; child thinks parent is 0x45d.4d4c;
It never printed the vnode of the object that actually failed.
norton> show directory 0x1000002 0x451 0x4d46
^^^^^^^^^^^^
(0x461 0x4d4e) test6
(0x45d 0x4d4c) .
^^^^^^^^^^^^^^
(0x47 0x380a) ..
(0x160e 0x4d83) m1.tgz
This looks very wrong, why is the `.' of 0x451 pointing to 0x45d, which
shows up as being the entry FLIGHT_DEMO_STUFF in directory 0x47.
0x47
0x1 (parent)
0x1 ..
0x47 .
0x449 DOCUMENTS
0x45d FLIGHT_DEMO_STUFF
0x449
0x47 (parent)
0x47 ..
0x449 .
0x451 demo-report
0x451
0x449 (parent)
0x47 .. !!BAD
0x45d . !!BAD
0x45d
unknown contents, hopefully:
0x47 (parent)
0x47 ..
0x45d .
It looks like 0x451 for some reason has the . and .. entries of 0x45d.
Jan
