On 8/25/06, R. Steve McKown <[EMAIL PROTECTED]> wrote:
I'm thinking more about initializing flash volumes for the various storage
abstractions. Initialization would be an issue for new motes with "factory
fresh" flash, or motes which have been reprogrammed after a change to the
volume organization (volumes-<impl>.xml file). For sake of argument, I'm
going to call these conditions "invalid volume", relative to the storage
abstraction which is (to be) using the volume.
If I read TEP 103 correctly, BlockStorageC and ConfigStorageC can detect an
invalid volume, using BlockRead.verify and ConfigStorage.valid (after
mount()), respectively. Is this correct?
Yes.
I can't find a similar mechanism for LogStorageC; is there one? TEP 103
doesn't say, but I'm assuming if LogStorageC has an invalid volume,
LogWrite.erase() must first be called?
Yes, erase must be called first. We spent some time wondering about
explicit or implicit mount operations - explicit mount gives a good
place to indicate invalid volumes, but I believe we ended up w/o it
for the reason outlined below.
The issue with specifying invalid volume detection is that it's
probably impractical (impossible?) to do w/o checking the whole volume
(*): imagine the following scenario:
- the mote had a log in blocks 0 - 100
- some later use puts some random data in block 55
- the most recent use again uses blocks 0 - 100 for a log
There's no obvious way to notice that random data short of checking
all the blocks.
FWIW, the at45db log storage implementation returns FAIL when it has
problems locating the end of the log on the first operation. But the
lack of a FAIL return doesn't guarantee anything if the log's blocks
have been used for non-log purposes (it's doing a binary search for
the end of the log, so may easily miss weird blocks...).
David Gay
*: note that this is what BlockStorageC.verify and
ConfigStorageC.valid end up doing. I guess that attempting to read the
whole log would be one way of detecting problems - if you get any
failures, then the log is invalid and must be erased...
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
