On Monday 28 August 2006 16:53, David Gay wrote: > On 8/28/06, R. Steve McKown <[EMAIL PROTECTED]> wrote: > > So shouldn't then TEP 103 specify data integrity requirements? [snip] > > [snip] > A reasonable compromise might be that read is guaranteed to return > valid data.
I'd love to see the spec guarantee that read returns valid data. Are you envisioning a read returns a len of 0 on bad data or end of log? This seems to fit nicely with the implementation of at45db, where bad data on a page and end of log conditions are generally synonymous. The specification addition "read is guaranteed to return valid data", as you consider above, would afford plenty of implementation flexibility. The stm25p impl, which uses virtual addresses and can identify end of log separately from a bad block, could silently skip bad data and continue at the next block in the log, if one exists. I believe the existing record atomicity requirements would apply to skipping bad data (bad data is record-atomic); if so, the loss of records due to bad data should impact an application no more than loss of records due to appending new data to a full circular log. > But recovering data from a corrupted log (i.e., not from > crash/reboot style failure) is something which is probably best left > to off-mote tools, I think. For the types of applications we'll develop, if the mote can't read some data from a log, the value of that data would never be worth enough to take the time and effort to extract it using other methods. I presume, using the mechanisms we're discussing, that an app could monitor error conditions from log IO operations to decide if it should try to erase the log and continue, stop and whine, etc. All the best, Steve _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
