[Tinyos Core WG] storage

[Jonathan Hui]

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.

--
Jonathan Hui
jhui at archrock.com

Philip Levis wrote:
> With the disappearance of mount(), there's no real startup call to most 
> storage abstractions. On one hand, this is clean. On the other, it can 
> cause some issues. Typically, the way this is handled is the first 
> operation does whatever setup that needs to be done. E.g., in the at45db 
> implementation of ConfigStorage, the first write after a commit (or 
> boot) makes a copy of the storage.
> 
> One issue this causes is huge differences in timing that can lead to 
> weird bugs. For example, Kannan was running a simple networking test:
> 
> for src in range (0, n):
>   for dest in range (0, n):
>     if (src != dest):
>       for i in range (0, 200):
>         src.send_packet_to(dest, i)
>         log(i, was_acked())
> 
> receive(src, i):
>   log(src, i)
> 
> So nodes send bursts of packets to each other, the source logs whether 
> the packet was acked, the dest logs all received packets.
> 
> The problem he ran into was this: the first node a node transmitted to 
> worked fine; the second (or later) wouldn't log any received packets. 
> The reason was pretty simple, but took a while to find out. The first 
> call to log() has a very large latency. On the first transmission, both 
> nodes share the latency: the source for its log, the destination for its 
> log. For the second node, though, the source doesn't have the latency 
> (sends packets fast), while the destination does (drops them all).
> 
> The only solution to this problem is to write a dummy record to the log 
> on startup. Should there be a command that lets you prepare the log 
> without writing? Should this exist in every storage abstraction? Without 
> significant buffering (and in this case, it would be hundreds of 
> packets)...
> 
> Phil
> 
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>