BlockDevice

Types of block devices and their properties

Name/Type	Capabilities	Location	Lifecycle	Command	Side Effects
Null/Block	write	local		data	Reliability=0
RAM/Block	read write	local	temporary	data	Expire to Disk/Net
Disk/Block	read write	local	persistent	data
Net/Block	read write	remote	persistent	data command
Disk/File-proxy	read	local	persistent	data	Regular scan of real files to build blocklist

Native capability can be reduced to configured capability run-time to reduce usage of device.

Type of data requested in block requests

Different types of block request operations have different requirements to how data is transfered, and how many devices are used.

Module	Operation	Location	id cksum
Dir	write-always	existing local	pathname
Dir	read	cheapest local	pathname
Dir	read	all remote	pathname
Inode	write-new	cheapest	body
Inode	read	cheapest	body
File	write-new	cheapest	body
File	read	cheapest	body
Chat	write-always	all remote	body+nodeid+date

• existing local = If one copy already exists in any local device, then write to same device. Otherwise choose cheapest.
• Raid level is handled in inode, so each block only needs to be written in one device.
• XXX: Stat, delete, cost... ?

Block operations

messagetype	Operation	Data
request	read	id
request	write	id+data
request	stat	id
request	cost	id
request	delete	id
response	read	data

Choosing Device

When a single device is be chosen from a larger set of possible devices, this information is considered:

• stat = block is known to exist on device
• cost = expense of retrieving the block from device
• perf = speed, reliability and noise level of device

Perhaps stat is a subset of cost, and not needed?

Command vs. Data

A command is routed to a single loaded module that will handle requests and responses for command. Routing is handled by Command module. Commands are local only.

Data requests can potentially be handled by several devices. Choosing devices is done by BlockBroker?. There might be several outstanding requests for same data block, and BlockBroker? will keep track and respond to all when data becomes available.

File and inode blocks are only encrypted once on the originating device. After that they are transfered as-is, and only decrypted when leaving ABFS. All other data transfers are re-encrypted every time.

Echo and Chat could be either considered commands or data-write requests. Probably both.

Other

• tmp file that are never written to persistent storage. They are only stored in Ram or are in constant transit.
• Find, traverse combined tree.
• ping
• When pushing data, should mentioned if storage is ok or not
• Generate blocklist of device for evacuation
• Already encrypted vs. needs encryption