Exnode specification: Difference between revisions

From ReddNet
Jump to navigation Jump to search
No edit summary
No edit summary
Line 14: Line 14:
**LoRS does not have access to L-Store's capability to recover an allocation
**LoRS does not have access to L-Store's capability to recover an allocation
*The L-Store data-client (Lstcp) has no allocation recovery capability.
*The L-Store data-client (Lstcp) has no allocation recovery capability.
*data recovery, data warming, etc all are done in the data-management area, not the data-client.
*data recovery, data warming, etc all data-management tasks, not data-client task.
*user interface and development API are needed by the data client
**The base exnode (LoRS)
*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?


== Data client API & interfaces ==
*command line tools for file management
**list files, create directories, etc
*LoRS API
**uses the base exnode (LoRS)
**reads local exnode files
**talks to LoDN with a combined http:/LoDN protocol
**C/C++ Posix and posix-like API
*Lstcp API (not developed yet)
**does not use exnodes
**talks to L-Server with the L-Store protocol
*typical C/C++ API needs (proposed)
**simple offsets and lengths
**non-blocked (vector) reads


== Schema ==
== Schema ==

Revision as of 21:42, 16 January 2008

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

Example LoRS exnode xml file

Example L-Store xml file

Erasure codings

  • L-Store writes extra erasure allocations for allocation recovery.
    • erasure allocations are also stored in the exnode file
    • erasure allocations are only useful to the data-management area and not the data-client
    • erasure allocations constitute an extension of the base (LoRS) exnode concept (or schema)
  • L-Store can write a LoRS compatible exnode file that excludes the erasure allocations.
    • LoRS compatible (the base schema)
    • LoRS does not have access to L-Store's capability to recover an allocation
  • The L-Store data-client (Lstcp) has no allocation recovery capability.
  • data recovery, data warming, etc all data-management tasks, not data-client task.

Data client API & interfaces

  • command line tools for file management
    • list files, create directories, etc
  • LoRS API
    • uses the base exnode (LoRS)
    • reads local exnode files
    • talks to LoDN with a combined http:/LoDN protocol
    • C/C++ Posix and posix-like API
  • Lstcp API (not developed yet)
    • does not use exnodes
    • talks to L-Server with the L-Store protocol
  • typical C/C++ API needs (proposed)
    • simple offsets and lengths
    • non-blocked (vector) reads

Schema

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

Simplified xml file

  • (removed xmlns to view 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)