view release on metacpan or  search on metacpan

Changes-0.5  view on Meta::CPAN

Recent versions add a little bit more functionality (construct Cauchy
and Vandermonde matrices), and some bug fixing, but my main focus has
been on performance improvements. I mostly achieved this by converting
some expensive method calls with XS code. I avoided tinkering with the
existing ida_process_streams routine (in Crypt::IDA), even though it
could use a bit of rewriting.

Originally, I had written this module with a view to implementing a
RAID-like storage system, using files instead of block devices. I
intended to use low-powered computers (Raspberry Pi and ODROID boards)
and external disks for storing old backups. I wrote a command-line
tool for managing the archive, but it relied on mounting disks over a
LAN, or physically connecting them to a single machine. I wanted to
develop this idea, using something like POE to write a distributed
cluster, with proper network daemons and such, but I never got around
to it.

Recently, I came across the Mojolicious framework and realised that it
could be a good framework to use:

* can easily write high-level, user-friendly HTTP interfaces (as
  opposed to trying to write a FUSE driver, for example)

* has support for low-level, event-driven programming (easier to use
  than POE)

* easy to use secure networking (HTTP/TLS)

* websockets are more convenient to use than generic sockets (and they
  support TLS, too)

This revived my interest in the idea of using low-powered boards and
storage devices as a distributed storage cluster.

However, the performance of my Math::FastGF2 and Crypt::IDA libraries
was never very good on Pi or ODROID boards. Rather than rewrite
everything in C, I decided that I'd stick with Mojolicious and just
optimise the Perl/XS libraries.

As a result of the optimisations, the code is still too slow to be
practical on the Pi boards that I have (Model Bs). Splitting a
256Mbyte file with k=3, n=3 parameters takes just over 2 minutes (down
from around 3 minutes), reading and writing to the onboard memory
card. This translates to around 16Mbit/s, which is far too slow to
saturate the 100Mbit network connection. I didn't actually test
reading from the network and writing to an external disk (or another
network connection), but my intuition is that these Pi boards wouldn't
be very good machines to do splitting/combining on, at least not with
Math::FastGF2 and Crypt::IDA.

I'm sure that I can still use Pi boards purely as storage nodes in
this new setup. I have some ODROID boards as well, which have much
better performance, so I can use one of those as the "head" node that
does the split/combine operations, with shares being sent over the
network to/from the Pi storage nodes.

As a result of the optimisations (here and in Crypt::IDA), the same
test of splitting a 256Mbyte file takes just under 10s on my XU3 Lite
board. Previously, it took 56s. This is still around three times
slower than on my proper desktop machine, but it should, theoretically
mean a bandwidth of around 160Mbit/s, which *would* be able to
saturate the 100Mbps network interface that it has.

With these new optimisations, it should now be practical to use the
Math::FastGF2 and Crypt::IDA libraries on fairly low-powered boards
like ODROID's XU3/XU3 Lite.

Note that the boards that I'm using are quite old. The Model B
Raspberry Pi boards have had two major updates (Pi 3 and Pi 4). The
ODROID boards also have more powerful successors (XU4 and N2). I
suspect that the newer ODROID boards would be overkill, but perhaps
the newer Pi boards would be fast enough to use as head nodes.