# Main # Tech #

CSRB VFS

The CSRB VFS layer is a virtual filesystem that exposes the communication functionalities of the CSRB Network, in a structure similar to a filesystem. The VFS layer resources are accessed via similar methods as accessing files using open(), read(), write(), ioctl(), etc functions. These functions are then exposed to the user applications either by linking to the CSRBnode library, or via a libFUSE version of the CSRBnode that mounts a local filesystem to expose the CSRB Network communication functionality.

The libFUSE based method creates some additional communication overheads but also opens up the interfacing capabilities, making it possible to transparently access the CSRB network via applications written in any programming language that supports file access (C/C++, Python, Rust, GO, Java, etc, even Shell-scripts).

The CSRB VFS layer provides a virtual contiguous address space for sequential OBJECTs, represented as OBJECTBLOCK. By crafting a suitable address access format, the user can access a sequential address space of OBJECTS of any chosen size, in the form of a single file. This makes it possible to transparently emulate small to huge OBJECT-backed data blocks in the form of files. These files can then be used as standard files or even block devices. The CSRB VFS layer transparently handles internally all data fragmentation/reassembly, OBJECT access, asynchronous parallel communication, etc.

The storage backend used by all CSRBnodes to store OBJECTs is based on LevelDB. The computers used for these tests are medium to low-end specs with spinning hard-drives, and from the tests it can be seen that LevelDB is quite inefficient when writing/modifying data. Very long (1-5mins+) suspensions of OPs are caused by the internal auto-compaction functionality. Reads are supposed to be the most efficient but if they follow large writes, which created fragmentation, they can still trigger the compaction process. LevelDB is fine if running on SSD storage but still such pool performance and full-blocking design while writing just a few GBs of data is bad.

All communication is encrypted with AES-256-GCM, with the encryption keys updated periodically at runtime without any operation interruption and with negligible latency/performance impact.

Demonstration videos: LAN, Embedded

# Email # Twitter # YouTube # IRC # © 2017-2042 CSRB #