[LinuxBIOS] [PATCH] v3: add a check for a termination member

[Peter Stuge]

On Fri, Jan 11, 2008 at 03:07:11AM +0100, Carl-Daniel Hailfinger wrote:
> > In practice, the marker is the most efficient method, but it is a
> > bit of an abomination IMO. :p
> 
> Big question: Is v3 a matter of pride or speed or userfriendliness?
> I haven't decided yet. ;-)

All of the above, to me at least.


> > How do we handle the integrity issue when a single flash block
> > that contains the start of a lar file is erased at runtime? (Thus
> > breaking a link in the list.)
> 
> If we really do erases at LB runtime, the person waiting for the
> erase surely has the time to rebuild the index/cache (which will
> probably need a fraction of the time needed for erase).

No matter who is erasing, the reality is that the marker is not
foolproof;

<carldani> for that to happen, power will have to fail exactly after
8 bytes of magic have been written to a sector

I think that the run-time index should always be created once we hit
the marker.

But we should try to avoid ever hitting the marker in the first
place. Perhaps by introducing certain requirements for the
"open-ended" special filenames that we currently have, ie. segment0
and any others.


On Thu, Jan 10, 2008 at 08:08:57PM -0800, ron minnich wrote:
> For the other discussion, iterate over the flash to find all the
> headers is taking 2-3 seconds. Sorry, that's just too long.

Fully agreed.


> We need the terminator in LAR; iterate over all of FLASH even once
> is just not going to work.

We should try to redesign so that it never happens in the common
case. For the corrupted flash case I think the best we can accomplish
is the runtime index, which will have to cost a bit of time, but at
least it will only be once per boot rather than once per file lookup.

Maybe it's not possible to redesign so that we can avoid the scan in
the common case. Then I would start looking at aligning members and
increasing 16 byte steps to maybe 4k or so.


//Peter