Month: November 2019

Undelete Files with SnapRAID

Today I accidentally deleted a whole folder of important documents on my OpenMediaVault(OMV) NAS, while doing some cleaning up.
Of course I would have a backup of the folder on an external hard-drive, but this was the perfect opportunity to test SnapRAID.

SnapRAID is a software RAID which comes as a plugin for OMV. SnapRAID computes redundancy/parity information for the files stored on multiple data disks. This redundancy/parity must be stored on a separate disk. If one data disk fails, the lost data on that disk can be reconstructed from the redundancy/parity information and the other remaining data disks. SnapRAID is quite flexible and allows any number of data disks and redundancy disks and a lot of options, which I haven’t even looked at to be honest.
The most important difference to other RAID systems is that SnapRAID is an offline RAID. This means SnapRAID will not constantly monitor disks and update the redundancy in real-time. Instead you are required to run SnapRAID manually every couple of days/weeks or schedule a cronjob to periodically update the SnapRAID parity disk.

Enough of that, here is how a deleted file or folder can be restored. The SnapRAID plugin for OMV allows to do this from the web UI, but I ended up using the shell anyway.

To check which files have been removed (or added) since the last parity update:
$> snapraid diff --test-fmt path
$> snapraid diff --test-fmt disk

To fix an entire array, i.e. fix everything that is missing:
$> snapraid fix -m
To fix everything on one disk (example disk name “MyDisk2” as assigned during SnapRAID creation):
$> snapraid fix -m -d MyDisk2
To fix a folder with a given name (located on any data disk):
$> snapraid fix -m -f myFolder/
or a file:
$> snapraid fix -m -f myFile
To just check what SnapRAID would do instead of fixing errors right away do:
$> snapraid check -m -f MyFile -v

After a couple of minutes my folder was back where it belonged. Feels good to be prepared for mishaps like that 🙂


Getting Started with Magic VLSI

Magic VLSI – or just Magic – is a free and open source VLSI layout software. Simply put Magic allows you to draw the mask layers used in a semiconductor facrication process. The Magic software is another “Berkeley Child” (like BSD and others) and first came into existence in the 1980s. Magic is still under active development as of late 2019.

Some Linux distributions offer a pre-build package for Magic from their package repository. Most often these packages are outdated and therefor it is best to build Magic from the sources.

Start by pulling the latest release from the official project page.
$> git clone git://
$> cd magic

$> git checkout magic-8.2

I am building Magic in a WSL Ubuntu 18.04 while writing this guide, so installing some additional packages is required before continuing. This step is subject to the build machine and may vary.
$> sudo apt install csh
$> sudo apt install libglu1-mesa-dev freeglut3-dev mesa-common-dev
$> sudo apt install tk tk-dev
$> sudo apt install libcairo2 libcairo2-dev

Now let’s continue to build Magic. I like to install software to /opt so it’s not burried deep inside the file tree and is available to all users on my machine (which is just me). The installation folder is set by the --prefix option.
$> ./configure --prefix=/opt/magic-8.2
If all the dependencies above where installed you should see a fivefold yes after the configure script has completed.

With that out of the way the build process can be launched as usual. The installation step may require to change the permissions on the installation folder, so that the current user has write access to the installation path.
$> make
$> make install

That’s it! Let’s see if it worked.
$> cd /opt/magic-8.2/bin
$> ./magic &

Success! Magic 8.2 has been launched.

In order to have something more than a gray box to look at let’s load the layout of an example gate from my Magic VLSI examples repo.

“Nice colors!” “Oh NAND you.”

That’s it for now. More examples on how to get started with Magic may follow.
P.S.: Before I forget to mention it, Magic requires a mouse with 3 buttons to work as intended. No kidding!


Getting Started with GHDL

If you haven’t heard of GHDL, it is *the* free open-source VHDL simulator out there.
GHDL stand for “G Hardware Description Language” (the G is without meaning). GHDL is mainly implemented in Ada and can be build with different backends: mcode, LLVM and GCC. The different backends provide different performance levels and vary in build complexity. I recommend LLVM since it performs well and is still quite straight forward to build. Building GHDL from latest sources from its github project is probably the best way to go.

Despite its free nature GHDL provides very good support for all major VHDL-LRM releases: VHDL-1987/1993/200X/2008(partial). Unforunately GHDL is a pure VHDL simulator, so there is no support for Verilog at all. This is understandable as there are already some very good simulators for Verilog out there.

Compiling GHDL

The following guide assumes a Ubuntu 18.04 environment (either a native installation or docker or WSL will do).
Clone the latest GHDL sources or any stable release from github:
$> git clone
Decent into the ghdl working copy and run the configure script with options to use LLVM as backend (–with-llvm-config) and a custom install path (–prefix):
$> cd ghdl
$> ./configure --prefix=/opt/ghdl-llvm --with-llvm-config

Install some dependencies:
$> sudo apt install -y bison flex
Afterwards you can build and install ghdl:
$> make
$> make install

The ghdl main executable is located at /opt/ghdl-llvm/bin/ghdl (the path given to the –prefix option). I usually create a symbolic link to make the ghdl command directly available in the $PATH:
$> ln -s /opt/ghdl-llvm/bin/ghdl /usr/bin/ghdl

That’s it for now. If you are familiar with docker, there is an easy to use docker image for ghdl available on dockerhub.