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