Plugins

ABFS uses plugins to support different approached to various functions.

Plugin Types

Storage

A storage plugin defines storing and retrieving blocks. Suggested types of storage:

• Head - Use process memory. Should be kept small, and is temporary until process terminates.
• Ramdisk - Use computer ramdisk. Storage disappears when ramdisk is erased or recreated.
• Disk - Use disk. Considered permanent storage.
• File Backend - Use a real file on file system
• Dir Backend - Use a directory structure of subdirs and files for storing files
• ABFS Trusted Remote - ABFS running on another trusted computer, connected with tcp/ip
• ABFS Anonymous Remote - Connecting to and allowing connections from any computer
• Torrent - Gateway to use torrent as storage
• Other Network - various other network based storages, such as smtp, http, OFF etc.

Properties

The plugin must specify what type of operations it supports:

• Local/remote read/write TBD
• Readwrite/read-only
• Max block size
• Kernel events
• Other properties
• Multiple devices

Each plugin must support multiple devices of same type. For example there can be several Dir Backends, or several other remote computers to connect to.

Read/Write Operations

Common read+write operations must be supported.

Mount point

A device instance is mounted in the tree. Several device instances can be mounted on top of each other on same mountpoint. When reading or writing, a devices is chosen be weighted randomness.

Access Rights

Local storage devices can be shared or kept local.

File Assembly

A file is broken down into blocks. A file assembly plugin does the break down and the assembly. Breaking down a file consist of generating blocks and an inode listen the block as well information about assembly. Assembling a file consist of reading the inode and combine block to generate the original file.

Suggested algorithms for mapping files and blocks:

• Raid 0 - Concatenation of blocks of same size
• Raid 1 - Mirroring. Straight mirroring is not possible, because it will result in same checksum and not store extra information on disk. The mirrored block could be bit flipped (xor 255).
• Raid 4 - Parity block for every N number of data blocks
• Raid 6 - 2 Parity blocks for every N number of data blocks
• Concat - Concatenation of blocks, not necessarily of same size
• Inline - File content is inside inode
• Erasure Codes - Oversampling polynomials

File modules must implement read-ahead, write-behind as needed for each type.

Command

Control commands are implemented as plugins. Examples:

• Load/unload plugin modules
• Mount/unmount devices
• Configuration
• View starts
• Shutdown

Filter

Filters controle the sequence and dropping of requests from request queue. Examples:

• Cost - to determine which device to most efficiently read data from or write to
• Stat - which blocks exist on which devices
• Friends - which remote devices do we prefer to serve incoming requests
• Loop - detect requests send in loops
• Time - drop old packets and packets from the future

Plugin Architecture

Writing a Plugin

Each plugin inherites ::Plugin from same type. Example:

package Filesys::Virtual::ABFS::Command::Load;
use base ('Filesys::Virtual::ABFS::Command::Plugin');

The ::Plugin module has a base class as dependency. Example:

package Filesys::Virtual::ABFS::Command::Plugin;
use base ('Filesys::Virtual::ABFS::Common::Loadable');
sub _properties {
  <<EOF;
Depend:
 - Command
EOF
}