Exnode specification

The exnode specification is implied by current usage in L-Store and LoRS.

Example LoRS exnode xml file

Example L-Store xml file

exnodes and erasure codings.

• L-Store writes extra erasure allocations.
  • These allocations are also stored in the exnode file
  • These allocations are only useful to a data-rebuilder not the data user
• L-Store can write a LoRS compatible exnode file that excludes the erasure allocations.
  • LoRS compatibility
  • LoRS does not have access to L-Store's capability to regain a file.

Is this OK?

• The data user does not need (and probably should not be bothered with) to handle error recovery.
• data recovery, data warming, etc all are done by services/agents apart from the data consumer.
• So what user interface and development API are needed by the data users?
• command line tools
  • file movement
  • file system (some use the term namespace management) tools
    • list files, create directories, etc
• C/C++ API
  • just need my simple offsets and lengths
  • would like to read a vector of data blocks (non-blocked reads)
  • don't want to deal with erasure stuff at this point.
    • is there a nice way to recover from errors?

Schema

The exnode xml is fairly unstructured and the functionality of a schema is minimal.

Simplified xml file (remove xmlns to see/understand structure more clearly)

Simple schema

• The schema shows that only the element mapping has much structure.
• The element metadata's use of attributes is completely open.
• The only re-used type is the IBP_capability (read,write,manage)