[Tinyos-Storage WG] Meeting minutes 04/13

[Gaurav Mathur]

04/13


Two definite items out of the emails were discussed

Discussion about DirectStorage as a possible hardware independent layer
-- Why do we need a flash independent layer ? Both platform dependent 
and independent layers can co-exist. Offers additional flexibility to a 
person developing a new storage system or introducing of a new storage chip
-- The interface is platform independent but has a platform dependent 
implementation
-- Should buffering be handled at this layer or below it ? It can take 
advantage of chip-specific on-board buffers to improve performance
-- Layer may not expose all the functionalities of the flash below it, 
but that’s ok for implementations that use this abstraction layer. 
Future chip-specific storage object implementations are supposed to 
provide higher performance by not using this abstraction layer and 
working directly with the chip
-- Should VolumeSettings be an interface or just #defines in a header 
file ? Probably a combination of both that provides good performance and 
an elegant way for an application to query the storage layer to find out 
platform characteristics (which it might choose to optimize itself for)
-- Provide generic implementations of BlockStorage, LogStorage and 
ConfigStorage components on top of DirectStorage ? David to look into 
this in more detail

Checkpointing / rollback support
-- David described his implementation of how checkpointing is done. 
State stored in the micro-controller EEPROM. Data structures plug in 
state that is stored during each checkpoint. As long as “ordering” of 
data-structures does not change, state is correctly restored after each 
reboot, but is not preserved across mote reprogram cycles.
-- Checkpointing could use internal EEPROM or the flash – the choice 
could depend on the availability of an internal EEPROM on the 
micro-controller, size of erase units and the number of erase units 
available on a specific flash chip

Please feel free to add in anything I missed.

- Gaurav

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3299 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.millennium.berkeley.edu/pipermail/tinyos-storage/attachments/20070413/4cdb8035/smime.bin