BanaNAS


BanaNAS. NAS mit dem Bananapi. NetworkAttachedStorage. HDD anstecken und gut ist.
Dank Gigabit und SATA Port, eignet sich der BananaPi vornehmlich als NAS. In Anbetracht des Preises von 30€ - das ideale Selbstbau-NAS.
Benötigt werden zudem

  • 2A 5V Netzteil
  • Spezielles BananaPi SATA-Kabel mit Stromanschluss (für 2,5") direkt auf dem Board.
  • 2,5" HDD
  • (Gigabit-Switch)


Im Folgenden ein paar Benchmarks:

CPU
cat /proc/cpuinfo
Processor    : ARMv7 Processor rev 4 (v7l)
processor    : 0
BogoMIPS    : 1195.38

processor    : 1
BogoMIPS    : 1199.69

Features    : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer    : 0x41
CPU architecture: 7
CPU variant    : 0x0
CPU part    : 0xc07
CPU revision    : 4

Hardware    : sun7i
Revision    : 0000

Leider kein Intel.

SATA Port - Festplatte Lese/Schreibgeschwindigkeit
dd if=/dev/zero of=/dev/sda bs=1M count=1024
1073741824 bytes (1.1 GB) copied, 29.6038 s, 36.3 MB/s

dd if=/dev/sda of=/dev/zero bs=1M count=1024
1073741824 bytes (1.1 GB) copied, 12.1234 s, 88.6 MB/s

Wegen eines Bugs in der Firmware o.ä. beträgt die maximale SATA-Schreibgeschwindigkeit ca. 40 MB/s.
Zudem werden nur 2,5" Festplatten unterstützt, wenn die Stromversorgung direkt vom Board aus erfolgen soll.
Die Lesegeschwindigkeit dagegen kann voll ausgereizt werden.

@reboot hdparm -B 255 /dev/sda; hdparm -S 241 /dev/sda

Die Festplatte nach 30 Minuten Inaktivität auszuschalten, spart nicht nur Energie, sondern verlängert auch die Lebensdauer einer gewöhnlichen, nicht für den Dauerbetrieb ausgelegten HDD. Für den Dauerbetrieb würde ich mir eine WD Red zulegen.

RAID 1 ist möglich, mit SATA-Port-Multiplier und Kompilierung eines eigenen Kernels. Die CPU soll sich beim RAID-Array rebuild aufhängen, angesichts der Schreibrate von nur 40MB/s dürfte das auch noch sehr sehr lange dauern.

Ethernet
nc -v -l -p 1234 > /dev/null # BananaPi
dd if=/dev/zero bs=1M count=1024 | nc -v 192.168.123.123 1234 # other pc

1073741824 bytes (1.1 GB) copied, 21.2694 s, 50.5 MB/s

Ein halbes Gigabit ist drin, was auch mit anderen Benchmarks aus dem Internet übereinstimmt.
Bei unverschlüsselter Übertragung mittels Netcat. So kann die Platte immmerhin lokal einigermaßen schnell gespiegelt werden.
Sollen später Daten außerhalb des heimischen LANs übertragen werden, muss natürlich verschlüsselt werden.

SSH
Ob rsync oder scp, alle nutzen unter der Haube SSH.
Eine gute SSH-Performance ist deshalb unumgänglich.

Der BananaPi verfügt über keine AES-Hardwarebeschleunigung, es muss also eine andere Chiffre her:
ssh -Q cipher, diese müssen in der /etc/ssh/sshd_config angefügt werden, da unsichere Cipher per default deaktiviert sind.
#!/bin/bash
cd /tmp
dd if=/dev/zero of=testfile bs=1M count=1024
echo > bench
for cipher in $(ssh -Q cipher); do
    echo -n "$cipher " >> bench
    dd if=testfile | ssh -c $cipher 192.168.123.123 "dd of=/dev/null" 2>&1 | grep bytes | awk '{ print $8$9 }' >> bench
done
sort -r -h -k 2 < bench > results
cat results

arcfour128 21.8MB/s
arcfour256 20.9MB/s
arcfour 20.1MB/s
chacha20-poly1305@openssh.com 14.7MB/s
aes128-cbc 13.2MB/s
aes192-cbc 12.4MB/s
aes128-ctr 12.4MB/s
aes192-ctr 12.0MB/s
cast128-cbc 11.9MB/s
rijndael-cbc@lysator.liu.se 11.8MB/s
blowfish-cbc 11.7MB/s
aes256-cbc 11.7MB/s
aes256-ctr 11.4MB/s
aes128-gcm@openssh.com 10.5MB/s
aes256-gcm@openssh.com 9.1MB/s
3des-cbc 3.9MB/s

arcfour128 (RC4), nicht zu unsicher, nicht zu langsam bietet einen satten Durchsatz von 174 Mbit/s an.
Der SSH-Daemon lastete immer nur einen der beiden Kerne aus.

Später mit LUKS auf SSHFS LUKS auf nbd spielt Verschlüsselung eh keine Rolle mehr...

Fazit
Die Leistung des BananaPis ist ziemlich ARM 😅. Für den Preis und den Verbrauch kann ich mich nicht beschweren. Ich meine, der Stromverbrauch ist so gering, dass ich mir nicht einmal die Mühe mache, nachzumessen.
Um einfach nur eine Festplatte online zu bringen, mit den Vorzügen eines echten Linux-Systems, das nach den eigenen Wünschen angepasst werden kann, für diese Aufgabe ist der BananaPi hervorragend geeignet.