Hi David, On Friday 25 August 2006 12:13 pm, David Gay wrote: > On 8/25/06, R. Steve McKown <[EMAIL PROTECTED]> wrote: > > 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.
I understand. And since the application is eventually going to read all the data in a log volume anyway, it makes more sense to perform integrity checks incrementally as the data are accessed by the application, if for no other reason than minimizing energy consumption. 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? 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. I look forward to your thoughts. Perhaps I'm stil missing an essential piece of the picture here. All the best, Steve _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
