Tag Archives: QNAP

Qnap, SonarQube and Elastic Search

Update 2021-10-20: Solution in the end of the post

I use SonarQube (and SonarScanner) to analyze my JavaScript source code in a project that has almost 200k lines of code.

SonarQube is a non-trivial install and it should be on a server so different developers can access it. Thus, SonarQube is an application that it would make sense to put in a packaged container, easy to set up.

I have a QNAP, with Container Station installed. That allows me to run Docker images and Linux (LXC/LXD) image. To me, this sounds like a perfect match: Just install a SonarQube Docker container on the QNAP and be happy!

Well, that was not how they thought it.

Last time I checked the SonarQube docker image did not come with a database. That would have been the entire point! Most work related to setting up SonarQube is related to the database. Docker support data folders, so it would be easy to configure the docker container with a single datafolder for the database and everything. No. You need two docker images.

The next problem is that SonarQube comes bundled with ElasticSearch which has some remarkable system requirements. Your operating system needs to be configured to support

  • 65535 open file descriptors (link)
  • 262144 vm.max_map_count (link)

Now the first problem is that Docker in QNAP does not support this. However it works with LXC.
The second problem is that QNAP is getting rid of LXC in favour of LXD, but you cant have 65535 open file descriptors with LXD (on QNAP – hopefully they fix it). So I am stuck with unsupported LXC.

But the real problem is – who the f**k at Elastic Search thought these were reasonable requirements?

I understand that if you have hundreds of programmers working on tens of millions of code you need a powerful server. And perhaps at some point the values above make sense. But that these are minimum requirements to just START ElasticSearch? How f***ing arrogant can you be to expect people to modify /etc/security and kernel control parameters to run an in-memory database as a priviliged user?

The above numbers seem absolutely arbitrary (I see that it is 2^16-1 of course). How can 65535 file descriptors be kind of fine, if 32000 are not? Or 1000? I understand if you need to scale enormously. But before you need to scale to enormous amounts of data, it would be absolutely wasteful, stupid and complicated to open 50k+ files at the same time. And if 32000 file descriptors are not enough for your clients big data, how long are you going to be fine with 65535? For a few more weeks?

This is arrogant, rotten, low-quality engineering (and I will change my mind and apologize if anyone can provide a reasonable answer).

All the data SonarQube of goes to a regular database. ElasticSearch is just some kind of report-processing thing serving the frontend. I did a backup of mine today, a simple pg_dump that produces an INSERT line in a text file for every database entry. Not very optimized. My database was 36Mb. So if Elastic Search would use just 36000 file descriptors, each file correspond to 1k of actual data.

I don’t know if I am the most disappointed with the idiots at ElasticSearch, or the idiots of SonarQube who made their quite ordinary looking GUI dependent on this tyrannosaurus of a dependence.

Hopefully the QNAP people can raise the limits to ridiculous values, so nobody at ElasticSearch needs to write sensible code.

And if anyone knows a hack so you can make ElasticSearch start with lower values (at my own risk), please let me know!


QNAP support helped me with the perhaps obvious solution. Log in as admin with ssh to the QNAP and run:

[~] # sysctl -w vm.max_map_count=262144
[~] # lx config set deb11-sonarqube limits.kernel.nofile 65535

The first command I already knew. You have to run it whenever the QNAP has restarted.

The second command is for setting the file limit in the particular container (deb11-sonarqube is the name of my container). I guess you just need to do it once (and then restart the container), and that the setting remains.

QNAP TS 251+ for Container Station

After many years of running home server systems on Raspberry Pi, another one broke down and I decided I can to better, so I bought a QNAP TS 251+ with two WD 6TB Red drives (suitable for NAS).

My objective here is to mostly use the QNAP with Container Station; for running virtual machines on it.

First Impression

The TS 251+ looks profesionally black, but it is all plastic. Installation was fine but for someone with little computer experience I would imagine it a bit scary. A few things to note:

  • It restarted several times for firmware upgrades, and restarting took some time
  • There are some “I accept privacy…”-things to accept. I guess it is fine. But one reason you get your own hardware instead of running in the cloud is that you know your data is private. So if you are paranoid, read the fine print or get into the details.
  • I suggest you familiarize yourself with RAID0, RAID1 and JBOD before you start it up.
  • I suggest you read about Static Volume, Thin Volume and Thick Volume, and make up your mind, before you start it up (I think Thin makes most sense, especially for use with Container Station).
  • The Web GUI is good – very “modern” – in a way that it almost feels like a desktop computer. A bit over-engineered and messy if you ask me. There are very many features and details, and it is a bit intimidating and confusing at first.
  • Container Station is just what I want and need!
  • I find it silent and cool enough (44C reported under load)
  • It automatically started some “Raid Syncronization” that takes about 24h with my drives. Guess it is fine, but it makes me a bit nervous with something new that I hesitate to restart or reconfigure it because it is doing something low-level and important.

Memory Upgrade

This model comes with 2GB RAM. That is quite enough, but not if you want to run Container Station conveniently. I have switched off most QNAP services, running a single LXC Container with syncthing using about 500MB of RAM, and the QNAP complains there is little available RAM (and it uses swap). So I think it is safe to say that to run Container Station or Virtualization Station, more RAM is recommended.

Officially max RAM is 8GB but there are multiple records of people saying it works with 16GB as well. It also appears that you may use just one memory module (out of two), they dont need to be installed in pairs.

So I bought 2x8GB and it seems to work perfectly:

  • Corsair DDR3L 1600MHz MACMEMORY
  • CMSA16GX3M2A1600C11


There are several Virtualization options with the QNAP:

  • Virtualization Station: running real virtual machines (like VMWare), emulating hardware. Just starting Virtualization Station used almost 1GB or RAM.
  • Container Station:
    • running (LXC) virtual linux machines, emulating just the kernel. This is much more light-weight, and it means the virtual machine shares disk and RAM with the main system (you do not need to allocate disk, all disk is available and shared for every virtual machine – they just live in separate folder)
    • running Docker containers
  • Linux Station: allowing the QNAP to work as a Linux Desktop.

Apart from virtualization, the QNAP also allows you to install things like WordPress, Mediawiki, MySQL and other services as packages.

Network Cable Problems!

For months I was getting unstable behaviour from my QNAP due to a bad network cable. The short version is that the NIC went up and down. Sometimes I had no IP. Things worked after software reset, but not otherwise. I think I am quite good at diagnosing computer problems but this one fooled me. I contacted support, they were patient, I was patient (however annoyed, because I was quite sure I had a defective QNAP), and after several days I discovered the problem (more or less by chance).

I believe the QNAP did not handle this unstable network in a very good way. However, I kind of cant blame it for my bad network cable. So I would not advice anyone against a QNAP because of these problems. However, for some days I was very disappointed.

After replacing the network cable, the QNAP has worked perfectly fine and stable – I have no complains whatsoever.

Container Station Problem

When I woke up in the morning it turned out my container was down. There was message from the middle of the night:

 [Container Station] Created interface "lxcbr0" with errors. Unable to start DHCP service.   

I found this strange, I could not start Container Station again, and I found other people had had this problem with no elegant solutions. I found that the problem was solved if I deleted the two virtual switches (docker0) and (lxcbr0); Container Stations creates them automatically when it starts.

I think my container may have crashed due to too little RAM in the middle of the night, and that somehow corrupted something.

Update and Problems 2020-02-29

One of my virtual container station machines had its clock out of sync. When I started investigating I could not connect to the QNAP itself. The two virtual machines were up normally. The QNAP itself was nowhere to be seen on the network. I restarted it (using the power button – I believe it shuts down properly), it came up and it wanted a firmware update, which I immediately accepted. After that it did not come up (on the network) again.

I tried to reach it on with no success.

I finally did a “reset” (using a paperclick on the rear side of the QNAP for 3-4s when it was already on). Following the reset it immediately appeared normally on the network. Password was “admin”.

However, the virtual container station machines did not start. I had to change their network settings to NAT, and then back to Bridge, then they worked. So it seems to me the virtual switch is not quite 100%.

All seems good now, but this took quite a while to figure out and fix. I bought a QNAP to get something much more stable and reliable than my old Raspberry Pi, but this was not impressive.

Update and Problems 2020-05-08

Quite same story as in February. The combination of

  • Container Stations
  • Virtual Switches / Bridged connections for Containter Station
  • Leaving QNAP up for a long time

is simply a very bad idea. Somehow the Network settings get corrupted and the entire f***ing QNAP, its bloated UI, and containers suffer. It takes hours to fix. Here is a little picture of the pleasure of trying to get rid of a virtual switch once it is corrupt (this was after mostly waiting for UI for an hour, achieving nothing).

My advice for now is to simply not use Bridged Network with containers and avoid creating virtual switches.

Upgrading Qnap TS109 from Jessie to Stretch

I have an old Qnap TS109 NAS that has been running Debian since long. I have previously written about my upgrade to Wheezy and Jessie.

The upgrade to Strech is the same procedure, and it was fine in the end, but…

In a very late phase of the upgrade I got:

update-initramfs: Generating /boot/initrd.img-4.9.0-5-marvell
flash-kernel: installing version 4.9.0-5-marvell

The initial ramdisk is too large. This is often due to the unnecessary inclusion
of all kernel modules in the image. To fix this set MODULES=dep in one or both
/etc/initramfs-tools/conf.d/driver-policy (if it exists) and
/etc/initramfs-tools/initramfs.conf and then run 'update-initramfs -u -k 4.9.0-5-marvell'

Not enough space for initrd in MTD 'RootFS1' (need 4210887 but is actually 4194304).

Well, the MODULES=dep thing does not help, but there is a another fix. You can compress your initramfs image. The procedure is described in the end of troubleshooting TS109.

The very short procedure is (I recommend you read the real article above):

echo "COMPRESS=xz" > /etc/initramfs-tools/conf.d/compress
apt-get install xz-utils
update-initramfs -u

Apart from that little problem, Stretch is just fine on QNAP TS109.

Upgrading Qnap TS109 from Wheezy to Jessie

The Qnap TS-109 runs Debian Wheezy just fine, but it has to be upgraded from Squeeze (no direct install). How about upgrading Wheezy to Jessie? This device is old and slow, so I decided to find out, and if it does not work, so be it.

Debian links:

Below follows a shorter version of the upgrade guide, focusing on what I actually did with my Qnap.

Getting ready
First you should of course backup your stuff if the device contains anything you can not lose.

It can also be a good idea to clean out packages that you dont need (to both avoid problems when upgrading them, and to save time during the upgrade):

$ sudo dpkg -l
$ sudo apt-get purge SOMEPACKAGES

It is also adviced to make sure you dont have packages on hold. You can do this with:

$ sudo dpkg --get-selections | grep 'hold$'

I confirmed that my system was then fully wheezy-updated

$ sudo apt-get update

$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

With that, I decided I was ready for an upgrade to Jessie.

Upgrade itself
I first updated /etc/apt/sources.list.

Old version:

deb http://ftp.se.debian.org/debian/ wheezy main
deb-src http://ftp.se.debian.org/debian/ wheezy main non-free

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main non-free

deb http://ftp.df.lth.se/debian wheezy-backports main

New version:

deb http://ftp.se.debian.org/debian/ jessie main
deb-src http://ftp.se.debian.org/debian/ jessie main non-free

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main non-free

I just deleted the backports source.

And begin upgrade:

$ sudo apt-get update
$ sudo apt-get upgrade

That went fine, so I did a reboot. It took longer than usual, but it came up. So I proceeded with:

$ sudo apt-get dist-upgrade

…which went fine, and I rebooted.

System came up and it seems good! If I encounter problems later I will write about it here.

Build Node.js on Debian ARM

Update 2015-02-15: So far, I have failed building Nodejs v0.12.0 on ARMv5

I have a QNAP TS109 running Debian (port:armel, version:7), and of course I want to run node.js on it. I don’t think there are any binaries, so building from source is the way to go.

About my environment:

$ cat /etc/debian_version
$ gcc --version | head -n 1
gcc (Debian 4.6.3-14) 4.6.3
$ uname -a
Linux kvaser 3.2.0-4-orion5x #1 Debian 3.2.51-1 armv5tel GNU/Linux
$ cat /proc/cpuinfo
Processor       : Feroceon rev 0 (v5l)
BogoMIPS        : 331.77
Features        : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 0

Hardware        : QNAP TS-109/TS-209
Revision        : 0000
Serial          : 0000000000000000

I downloaded the latest version of node.js: node-v0.10.25, and this is how I ended up compiling it (first writing build.sh, then executing it as root):

$ cat build.sh
export CFLAGS='-march=armv5t'
export CXXFLAGS='-march=armv5t'
make install
$ sudo ./build.sh

That takes almost four hours.

A few notes…

make install
Naturally, make install has to be run as root. When I do that, everything is built again, from scratch. This is not what I expect of make install, and to me this seems like a bug. This is why I put the build lines into a little shell script, and ran the entire script with sudo. Compiling as root does not make sense

-march=armv4 and -march=armv4t
Compiling with -march=armv4t (or no -march at all, defaulting to armv4 I believe) results in an error:

../deps/v8/src/arm/macro-assembler-arm.cc:65:3: error:
#error "For thumb inter-working we require an architecture which supports blx"

You can workaround this by above line 65 in the above file:


as I mentioned in my old article about building Node.js on Debian ARM.

I first tried building with -march=armv5te (since that seemed closest to armv5tel which is what uname tells me I have). The build completed, but the node binary generated Segmentation fault (however node -h did work, so the binary was not completely broken).

I do not know if this problem is caused by my CPU not being compatible with/capable of armv5te, or, if there is something about armv5te that is not compatible with the way Debian and its libraries are built.

Upgrading Qnap TS109 from Squeeze to Wheezy

Update: new instructions for upgrading Wheezy to Jessie

Now that Wheezy has been out for a while I thought it is stable enough even for my old QNAP TS109. A great source of information for Debian on Qnaps is Martin Michlmeyr, so I decided to upgrade from squeeze to wheezy using Debain standard instructions.

Package Checking
I did not have any packages on hold, but over the years I have installed quite many packages I dont need. So I spent some time listing and removing packages:

$ sudo dpkg -l
$ sudo apt-get purge SOMEPACKAGES

I thought, faster to delete them now, than to upgrade them a little later.

First real upgrade-related step is fixing /etc/apt/sources.list:

deb http://ftp.se.debian.org/debian/ wheezy main
deb-src http://ftp.se.debian.org/debian/ wheezy main non-free

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main non-free

I have just replaced ‘squeeze’ for ‘wheezy’ four times.

update upgrade
Now the point of no return:

$ sudo apt-get update
$ sudo apt-get upgrade

This presented me with a few challenges.

???????????????????????????Configuring linux-base?????????????????????????????
? Boot loader configuration check needed                                     ?
?                                                                            ?
? The boot loader configuration for this system was not recognized. These    ?
? settings in the configuration may need to be updated:                      ?
?                                                                            ?
?  * The root device ID passed as a kernel parameter;                        ?
?  * The boot device ID used to install and update the boot loader.          ?
?                                                                            ?
?                                                                            ?
? You should generally identify these devices by UUID or label. However,     ?
? on MIPS systems the root device must be identified by name.                ?
?                                                                            ?
?                                                                            ?
?                                 <  OK  >                                   ?

What is an ARM user gonna do about it? You can safely ignore this (if you are upgrading Debian on a QNAP – probably not if you are upgrading Ubuntu on your laptop!). This is supposed to be grub/lilo-related, and not relevant.

In the end of apt-get upgrade I got these messages, ensuring my system will boot properly even after upgrade. You should probably see something like this too, or consider to find out how to do it manually.

Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.32-5-orion5x
flash-kernel: installing version 2.6.32-5-orion5x
Generating kernel u-boot image... done.
Flashing kernel... done.
Flashing initramfs... done.

Sudo was a little challenge:

Configuration file `/etc/sudoers'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sudoers (Y/I/N/O/D/Z) [default=N] ? D

The “diff” told me that it intended to delete my sudo line related to me; the new way is to add people to the group (/etc/group) named sudo. So I added myself to the sudo group and bravely answered ‘Y’ to the question above.

Immediately, sudo did not work, as I was no longer in the sudoers file… However, a little logout/login fixed that, and the group works all fine.

After apt-get upgrade had completed I decided to reboot my system, before proceeding. For the first time ever it came up with another IP-address than usual. Obviously the dhcp-client did not bother to ask for the same address anymore, and the dhcp-server did not bother to hand out the same address either. So, a few nervous minutes before I found my QNAP on another IP.

apt-get dist-upgrade
Now that the system rebooted properly it was time for the final upgrade step:

$ sudo apt-get dist-upgrade

This procedure mostly works on it own, occationally asking something.

I answered Yes to this question (after reading the diff, not remembering having edited this file)

Configuration file `/etc/default/rcS'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** rcS (Y/I/N/O/D/Z) [default=N] ? y

The dist-upgrade once again replaced the kernel…

Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.2.0-4-orion5x
flash-kernel: installing version 3.2.0-4-orion5x
Generating kernel u-boot image... done.
Flashing kernel... done.
Flashing initramfs... done.

…so I made a final reboot. Everything seems just fine.

Building Node.js on Debian ARM (old)

Update 20140130: I suggest you first have a look at my new article on the same topic.

I thought it was about time to extend my JavaScript curiosity to the server side and Node.js.

A first step was to install it on my web server, a QNAP TS-109 running Debian 6. I downloaded the latest version (v0.10.15), and did the usual:

$ ./configure
$ make

after hours:

../deps/v8/src/arm/macro-assembler-arm.cc:65:3: error: #error "For thumb inter-working we require an architecture which supports blx"

That is not the first time my TS 109 has been too old. However, the english translation of the above message is that you have to have an ARM cpu V5 or later, and it has to have a ‘t’ in its name (at least, this is what the source tells, see below). In my case

$ uname -a
Linux kvaser 2.6.32-5-orion5x #1 Sat May 11 02:12:29 UTC 2013 armv5tel GNU/Linux

so I should be fine. I found a workaround from which I extracted the essential part.

// We always generate arm code, never thumb code, even if V8 is compiled to
// thumb, so we require inter-working support
#if defined(__thumb__) && !defined(USE_THUMB_INTERWORK)
#error "flag -mthumb-interwork missing"

// ADD THESE THREE LINES TO macro-assembler-arm.cc


// We do not support thumb inter-working with an arm architecture not supporting
// the blx instruction (below v5t).  If you know what CPU you are compiling for
// you can use -march=armv7 or similar.
# error "For thumb inter-working we require an architecture which supports blx"

After adding the three lines, I just ran make again, and after a few hours more everything was fine. Next time I will try the -march or -mcpu option instead.

Lisp on Debian/ARM

After reading Revenge of the Nerds I decided it was time to learn Lisp. Programming without some kind of real project is boring, so my plan is to write some web applications using jquery and Lisp (for the back end).

Since I have a Qnap TS-109 running 24×7 I thought it would make a good development machine and Lisp web server. It runs Debian 6.0, but running Lisp on it turned out to be a challenge.

Debian, Lisp and ASDF
Debian supports installing different implementations of (Common) Lisp. However, it seems to be tricky to find a version that installs a binary on Debian ARM.

Also, there is a package depency tool for lisp called ASDF. Lisp implementations should come with it.

The only Common Lisp that I managed to easily install (i.e. with apt-get) in Debain 6.0 ARM was GCL. But it is a version of GCL that is 5 years old, and it does not come with ASDF.

I spent much time trying to compile clisp, but in the end I ended up with:

  > ( / 6 3)
  > ( / 5 2)
  Segmentation Fault

Not so fun. Significant parts of clisp is written in assembly (both a good thing and a bad thing), and I was really not able to figure out if it was supposed to work on ARM EABI at all, or just on the old ARM ABI. So after much struggle I gave up clisp.

I managed to compile ECL from source. Not completely without hassle though. It comes with libffi, but I ended up with compilation errors (the processor does not support…). So, I downloaded libffi, compiled it myself and installed it in /opt/libffi. That was no problem, but I ended up making a symbolic link to include myself:

kvaser@kvaser:/opt/libffi$ ls -l
total 8
lrwxrwxrwx 1 root root   40 Mar 11 16:52 include -> /opt/libffi/lib/libffi-3.0.10rc9/include
drwxr-xr-x 4 root root 4096 Mar 11 16:37 lib
drwxr-xr-x 4 root root 4096 Mar 11 16:37 share

Now I configured ecl with:

CPPFLAGS=-I/opt/libffi/include LDFLAGS=-L/opt/libffi/lib ./configure --prefix=/opt/ecl --with-dffi=auto

That worked, and compiling went fine until ecl_min could not be executed, because it could not find libffi.so.6. I tried to fix that a while, but finally ended up making another symbolic link:

kvaser@kvaser:/usr/lib$ ls -l libffi.so.6
lrwxrwxrwx 1 root root 31 Mar 11 19:56 libffi.so.6 -> /opt/libffi/lib/libffi.so.6.0.0

After that, I ran make again to finish compilation. It went fine.

ECL, ASDF and cl-who
Now, where to put the Lisp http library cl-who? I copied the asd-file and the lisp-files to the ecl library folder and ran ecl as root:

kvaser@kvaser:~/lisp/cl-who-0.11.1$ sudo cp cl-who.asd /opt/ecl/lib/ecl-11.1.1/
kvaser@kvaser:~/lisp/cl-who-0.11.1$ sudo cp *.lisp /opt/ecl/lib/ecl-11.1.1/
kvaser@kvaser:~$ sudo /opt/ecl/bin/ecl
  ... ...
> (require 'asdf)

;;; Loading #P"/opt/ecl/lib/ecl-11.1.1/asdf.fas"
;;; Loading #P"/opt/ecl/lib/ecl-11.1.1/cmp.fas"
("ASDF" "CMP")

> (asdf:operate 'asdf:load-op :cl-who)    
  ... ...

Now, cl-who is compiled and installed, ready to use. Next time, it does not need to be compiled.

Hello LISP
I wrote a little Hello World program:

kvaser@kvaser:~/lisp$ cat hello.lisp 
(format T "Hello Lisp~%")
kvaser@kvaser:~/lisp$ /opt/ecl/bin/ecl -load hello.lisp 
;;; Loading "/home/kvaser/lisp/hello.lisp"
Hello Lisp

Quite good (except I already know the file was loaded and it disturbs my output, but whatever. How about compiling it?

kvaser@kvaser:~/lisp$ /opt/ecl/bin/ecl -compile hello.lisp 
;;; Loading #P"/opt/ecl/lib/ecl-11.1.1/cmp.fas"
;;; Compiling hello.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;; End of Pass 1.
;;; Note:
;;;   Invoking external command:
;;;   gcc -I. -I/opt/ecl/include/ -I/opt/libffi/include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fPIC -Dlinux -O2 -w -c hello.c -o hello.o 
;;; Note:
;;;   Invoking external command:
;;;   gcc -o hello.fas -L/opt/ecl/lib/ /home/kvaser/lisp/hello.o -Wl,--rpath,/opt/ecl/lib/ -shared -L/opt/libffi/lib -L/opt/libffi/lib -lecl -lgmp -lgc -lffi -ldl -lm 
;;; Finished compiling hello.lisp.
kvaser@kvaser:~/lisp$ ls
cl-who-0.11.1  cl-who.tar.gz  hello.fas  hello.lisp
kvaser@kvaser:~/lisp$ ./hello.fas 
Segmentation fault
kvaser@kvaser:~/lisp$ /opt/ecl/bin/ecl -load hello.fas 
;;; Loading "/home/kvaser/lisp/hello.fas"
Hello Lisp

Ok, how to make a standalone executable?

> (compile-file "hello.lisp" :system-p t)
  ... ...

> (c:build-program "hello" :lisp-files '("hello.o"))
  ... ...
> (quit)
kvaser@kvaser:~/lisp$ ls
hello  hello.fas  hello.lisp  hello.o
kvaser@kvaser:~/lisp$ time ./hello
Hello Lisp

real	0m3.084s
user	0m2.920s
sys	0m0.160s
kvaser@kvaser:~/lisp$ time /opt/ecl/bin/ecl -load hello.fas 
;;; Loading "/home/kvaser/lisp/hello.fas"
Hello Lisp

real	0m3.127s
user	0m3.060s
sys	0m0.080s
kvaser@kvaser:~/lisp$ time /opt/ecl/bin/ecl -load hello.lisp
;;; Loading "/home/kvaser/lisp/hello.lisp"
Hello Lisp

real	0m3.113s
user	0m2.960s
sys	0m0.160s

Clearly, some overhead is involved in invoking ECL. I compared to C:

kvaser@kvaser:~/lisp$ cat hello.c 

int main(int argc, char **argv) {
	printf("Hello C\n");
kvaser@kvaser:~/lisp$ gcc -o hello_c hello.c 
kvaser@kvaser:~/lisp$ time ./hello_c 
Hello C

real	0m0.012s
user	0m0.010s
sys	0m0.000s

So, I can not use this method for CGI programming right away – each call to the webserver will take at least 3 seconds.

Some performance benchmarks of QNAP TS 109

I bought a QNAP TS-109 with the intention of using it as a linux server (DNS, DHCP, www, vpn, ssh, file, mysql). The QNAP comes with its own (very nice) linux based firmware, but my plan was to run Debian on it. However, performance seemed not so good (found something on Google about missing DMA Engine in the kernel), so I decided to do some benchmarks before picking Debian or qnap firmware.

The harddrive is a Samsung 2TB drive (so those one works). All tests are made with a 500 Mb mpeg-file (high entropy). The server is a Mac OS X machine.

The commands used are:

  qnap$ nc -l -p 9999 > nc-500Mb.img
  mac$ time nc 9999 < 500Mb.img

  qnap$ time scp o@ scp-500Mb.img

  qnap$ time md5sum nc-500Mb.img

  qnap$ time cp scp-500Mb.img cp-500Mb.img

Results follow:

                   nc       scp      md5sum   cp   
Debian 6.0 btrfs   87s      273s     40s      71s
           ext3    73s      284s     22s      39s
           ext2    59s      273s     22s      27s
Debian 5.0 ext3    81s      259s     23s      40s
           ext2    62s      246s     23s      26s
Qnap FW            N/A      394s     N/A      27s

The commands nc and md5sum was not available in the qnap firmware.

Bricking, and recovery
I made a mistake when making backup of the original qnap firmware. So, when intending to restore the qnap firmware over Debian, I ended up making the qnap unbootable.

Another mistake was to not follow good advice; they tell you very clearly to "install recovery mode" before trying Debian.

I got a USB to 3.3V TTL serial cable and tried to revive it. It worked using these instructions 🙂 I ended up doing some soldering inside the qnap.

My advice: when you backup /dev/mtdblocks, make a simple cmp to verify that the file you created matches the block you intended to backup. Much quicker than realising later that recovering old OS actually bricks you machine.

As I see it, there are no performance reasons to use the Qnap firmware with the Qnap. Debain seems to be equally fast. Still, both are surprisingly slow - do I have a hard drive incompability issue?

After deploying Debian, I can say that real world performance for rsync (mostly large files) is just over 5 Mb/s.