[Tinyos Core WG] storage

[Philip Levis]

On Sep 15, 2006, at 6:40 PM, Jonathan Hui wrote:

>
> While I see the problem, I'm not sure on how exactly should Block/ 
> Log/ConfigStorage provide timing guarantees for each of its  
> operations. The issue with most NOR chips are that erases are very  
> slow, on the order of seconds. For a circular log, times when you  
> need to reclaim space can keep the storage chip busy for a long  
> time. So when should the erase happen? When someone expects sub- 
> second delay between appends, there's nothing you can do.
>
> The only possibility I can see is that a storage chip must provide  
> some documentation on what the worst-case time is for an operation  
> to complete. This would help in deciding how much buffer an  
> application should allocate when putting things into the queue.
>
> Sure, the action of mounting could take more time than a sector  
> erase and having nodes implicitly mount at boot would reduce the  
> maximum latency to an erase time, but buffering decisions when  
> streaming stuff into flash must still be made.

I think the question is whether you want to do operations lazily or  
proactively. As you point out, the mount() operation only solves the  
starting case; in a circular log, you're going to run into the  
problem many times.

But you can mask these latencies. For example, rather than erase a  
block when you reach it, you can erase it when you reach the previous  
block. As it is now, it's very difficult to write a high-speed logger  
with a circular log. There's little sense of how long the erase will  
take, and therefore how much buffering you'd have to do.

This leads to two questions:

1) Stronger: should there be API support for masking latencies when  
needed?
2) Weaker: should the TEP recommend that implementations mask  
latencies when possible?

Phil