Exnode specification: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 23: | Line 23: | ||
== Erasure codings == | == Erasure codings == | ||
*L-Store writes data in its original format (possibly encrypted, etc), just like LoRS. | *L-Store writes data in its original format (possibly encrypted, etc), just like LoRS. | ||
**These | **These blocks can be read directly by LoRS. | ||
*L-Store also writes extra erasure | *L-Store also writes extra erasure blocks to recover lost blocks. | ||
**the XOR-ing to generate erasure | **the XOR-ing to generate erasure block is calculated on the depots | ||
***nfu operation stored on the depot | ***nfu operation stored on the depot | ||
**erasure | **erasure blocks are also stored in the exnode file | ||
**erasure | **erasure blocks are only useful to the data-management area and not the data-client (see diagram) | ||
**erasure | **erasure blocks 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. | *L-Store can write a LoRS compatible exnode file that excludes the erasure allocations. | ||
**LoRS compatible (the base schema) | **LoRS compatible (the base schema) | ||
**LoRS does not have access to L-Store's capability to recover | **LoRS does not have access to L-Store's capability to recover a block | ||
*The L-Store data-client (Lstcp) has no | *The L-Store data-client (Lstcp) has no block recovery capability. | ||
*data recovery, data warming, etc all data-management tasks, not data-client task. | *data recovery, data warming, etc all data-management tasks, not data-client task. | ||
Revision as of 10:41, 18 January 2008
The exnode specification is implied by current usage in L-Store and LoRS.
Example L-Store exnode xml file
Schema
The exnode xml is fairly unstructured and the functionality of a schema is minimal.
- (removed xmlns to view structure more clearly)
- In this example schema
- The schema shows that only the element "mapping" has required elements.
- The element metadata's use of attributes is unrestricted.
- The only re-used type is the IBP_capability (read,write,manage)
- L-Store additions
- element "function"
- erasure metadata "parity slice size"
- additional erasure encoding info to be added here.
Erasure codings
- L-Store writes data in its original format (possibly encrypted, etc), just like LoRS.
- These blocks can be read directly by LoRS.
- L-Store also writes extra erasure blocks to recover lost blocks.
- the XOR-ing to generate erasure block is calculated on the depots
- nfu operation stored on the depot
- erasure blocks are also stored in the exnode file
- erasure blocks are only useful to the data-management area and not the data-client (see diagram)
- erasure blocks constitute an extension of the base (LoRS) exnode concept (or schema)
- the XOR-ing to generate erasure block is calculated on the depots
- 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 a block
- The L-Store data-client (Lstcp) has no block 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
- file movement
- file replication, augment, trim
- command line tools for namespace management
- list files
- create directories, etc
- LoRS API
- uses the base exnode schema (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 parse exnodes?
- talks to L-Server with the L-Store protocol
- receives IBP commands individually from L-Server?
- sends these commands directly to IBP depots?
- typical C/C++ API needs (proposed)
- simple offsets and lengths
- non-blocked (vector) reads