OOPS at mount

[David Woodhouse]

On Thu, 2007-04-26 at 14:15 +0100, David Woodhouse wrote:
> I haven't _quite_ placed my finger on a sequence of events which leads
> to you having a few older nodes of this inode and a later metadata
> node.
> 
> Had it been deleted while you were still using summary?

If it had, that could explain it.

You start off with this file starting in some eraseblock, with its
dirent, then filling a few more eraseblocks...

 ( D for dirent, I for data node ), [...] is an eraseblock.

1 [......DIIIIIIII]
2 [IIIIIIIIIIIIIII]
3 [IIIIIIIIIIIIIII]
4 [IIII...........]

You seem to have something which will 'touch' these files
in /tftpboot/download when you boot -- which is why I think we aren't
seeing the problem in the image you took. Note the change time on ino
#9943 is yesterday. So somewhere entirely different on the flash you'll
have one mode metadata node for the inode in question.

5 [.......I.......]

Now, you delete the file. You can immediately erase eraseblock #2 and
#3, but because you're using SUMMARY, you don't mark the nodes in the
other eraseblocks as obsolete. You delete the file you downloaded
immediately after the one we oopsed on too, so you erase eraseblock #4.

You do write out a deletion dirent, but I suspect that got erased
somehow later (perhaps when you weren't using SUMMARY?) 

So you're left with this on the medium.
1 [......DIIIIIIII]
 ...
5 [.......I.......]

And that's what caused the crash.

I've handwaved a bit about the deletion dirent going missing, so I'm
still not 100% convinced but I'm fairly sure it's disabling summary
which was the problem.

I wonder if we should seek out obsolete nodes and mark them as such, if
we're mounted on a filesystem with summary nodes when summary support is
deleted.

Then again, why in hell is !jffs2_can_mark_obsolete() when we have
summary support anyway?

-- 
dwmw2