On 8/28/06, R. Steve McKown <[EMAIL PROTECTED]> wrote:
So shouldn't then TEP 103 specify data integrity requirements? I can't imagine a use of log storage where it'd be ok to read back different data than I'd originally appended. And if that's true, wouldn't data integrity be more efficient close to the physical storage mechanisms where is particular peculiarities and benefits be accommodated than out in the application?
Currently, TEP103 specifies that crashes and reboots don't cause data loss, and that writes are atomic. Offhand, I'd say ensuring this requires some kind of CRC, so adding some data-corruption detection guarantee (well, within the limits that CRCs provide) probably wouldn't be too bad. However, providing guaranteed data corruption detection is trickier (see below).
How about something along these lines: - seek() returns a new error code if the app attempts to seek into an expected valid area of the log but cannot do so. Perhaps some implementations might have a metadata structure that could cause this condition. If this condition happens, seek should automatically forward to the first whole record in the log that it can identify. The error return from seek() allows the application to know that data are unavailable at the desired seek location. The app could issue another seek() if it's doing its own blocking, or go ahead and read if the records defined by append operations are suitable. - read(), on SUCCESS, provides a reasonable guarantee that the data originally appended are read back without corruption. Read should return a new error code if the data to be returned resides in an area of the flash that is known corrupt. The integrity check presumably happens during a read operation, optimized according to implementation (i.e. only once per flash page, etc). The read pointer should automatically move to the next whole record just past the known corrupt area. The application can read again or do a seek.
The at45db implementation will currently notice when data is invalid. However, it tends to believe that this means it's at the end of a log (because an unintialised page, or a failed page write will give you something with an invalid CRC). Detecting the different between failure and data corruption would require extra complexity, I think (especially given a circular log). A reasonable compromise might be that read is guaranteed to return valid data. 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. David Gay _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
