Raspbian VDR Streaming Client - SD Management
Inhaltsverzeichnis |
SD Management
Backup mit rpi-clone
Alle Linux Installationen auf dem RPI haben zumindestens eine DOS Partition und eine Linux Partition. Die DOS Partition wird vom Bootloader des RPI verwendet und enthält auch die MPEG2/VC1 Lizenzinformation.
Man sollte nicht einfach 'dd' verwenden um die komplette RPI SD zu kopieren: Selbst 'gleich-große' SD desselben Herstellers/Typs müssen nicht immer exakt dieselbe Anzahl von Sektoren haben. Außerdem kann es vorkommen, daß SD/USB Adapter weniger Sektoren zur Verfügung stellen als der MMC Adapter. Die raspian Installation nutzt aber die SD Karte bis auf den letzten Sektor. Wenn man solch eine Installation auf eine SD Karte mit nur einem Sektor weniger mit dd kopiert kann man davon nicht mehr booten.
Man kann mit einigem Aufwand die Linux Partition auf dem RPI etwas kleiner machen (ca. 95%) als die SD-Karte um einfach mit 'dd' zu kopieren, aber einfacher ist es, mit rpi-clone zu kopieren.
Information
https://github.com/billw2/rpi-clone
Download
cd /data/installfiles wget https://github.com/billw2/rpi-clone/archive/master.zip unzip -x master.zip rm master.zip cd rpi-clone-master
Damit man rpi-clone bei laufenden VDR client funktioniert, muß man sicherstellen, das in den RSYNC_OPTIONS "x" enthalten ist, ansonsten kopiert rpi-clone die NFS gemounteten Verzeichnisse des VDR servers:
Rpi-clone mit Editor der Wahl modifizieren:
RSYNC_OPTIONS="--force -rxltWDEgopt"
^
Installieren
sudo cp rp-clone /usr/local/sbin
Benutzen
Zweite, ausreichend große SD Karte via USB Adapter an den RPI anschließen. Kontrollieren, daß die Karte erkannt wird:
ls /dev/sd* /dev/sda /dev/sda1
Wenn die Karte noch keine Kopie der VDR installation enthält:
sudo rpi-clone -f sda
Wenn man eine existierende Kopie aktualisieren will:
sudo rpi-clone sda
Dies geht schneller, weil nur inkrementell kopiert wird. Es wird aber nicht mehr die DOS-Partition kopiert. Wenn man dort Änderungen vorgenommen hat, dann muß man die leider händisch übertragen.
Leider braucht es in der jetzigen Version noch zwei fixes.
sudo mkdir /mnt/sda2 sudo mount /dev/sda2 /mnt/sda2 sudo chown pi /mnt/sda2/srv/vdr/video sudo rm /mnt/sda2/var/swap sudo umount /mnt/sda2
Nach dem kopieren RPI herunterfahren, Kopie in den SD Slot einlegen und verifizieren, daß die Kopie funktioniert.
Clonen
Wenn man ene Kopie der VDR Clientinstallation auf einem weiteren RPI laufen lassen will, dann muß man nach dem kopieren alle Parameter anpassen, die auf dem neuen RPI anders sein sollen wie auf dem ersten.
sudo mkdir /mnt/sda1 /mnt/sda2 sudo mount /dev/sda1 /mnt/sda1 sudo mount /dev/sda2 /mnt/sda2
- Hostname
- Editieren in /mnt/sda2/etc/hostname
- IP-adresse (wenn statisch vergeben)
- Editieren in /mnt/sda2/etc/network/interfaces
- MPEG/VC1 Lizenzen
- Editieren in /mnt/sda1/config.txt, aber wahrscheinlich einfacher nachdem man den neuen RPI gebootet hat, damit man einfach die Seriennummer auslesen kann.
Anschließend die Kopie unmounten:
umount /mnt/sda1 /mnt/sda2
Und im zweiten RPI ausprobieren.
Lebensdauer der SD verbessern
Die Lebensdauer von SD-Karten ist vor allem durch die Anzahl an Schreibzyklen geprägt. Angeblich haben ältere 'gen mlc' flash 10k Schreibzyklen, neuere 'tlc' flash 1k Schreibzyklen pro Speicherstelle [1]. Es wird aber beim mehrfachen Beschreiben eines 'sektors' auf einer guten SD Karte nicht immer derselbe physikalische Speicherbereich auf der SD beschrieben, stattdessen versucht die "wear level management" software auf der SD Karte, die rechner-sichtbaren Sektoradressen dynamisch bei Schreibvorgängen so auf die physikalischen Adressen der SD abzubilden, daß alle Sektoren möglichst gleichmäßig und wenig beschrieben werden [2].
Dazu muß diese SD software wissen, welche Sektoren 'unbenutzt' sind, so daß diese Sektoren neu zugeordnet werden können. Ext4 und andere neuere filesystem (nicht ext2, ext3) erlauben dem Speichermedium via "TRIM" Befehle mitzuteilen, welche Sektoren unbenutzt sind.
Geht nicht ? Hdparm
Leider ist nicht klar, ob dies mit dem SD karten treiber im RPI wirklich funktioniert und etwas bewirkt: Das Standardprogramm um festzustellen welche Features das Speichermedium unterstützt ist hdparm:
# Auf einer echten SSD:
sudo hdparm -I
hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks)
* Deterministic read data after TRIM
Auf dem RPI SD MMC treiber (/dev/mmcblk0) scheint der Befehl nicht unterstützt zu sein und und wenn man eine SD via USB Adapter mounted, wurden bisher keine erfolgreiche Bestimmung von TRIM support gemeldet (bitte hier ändern, wenn doch).
Geht nicht ? Smartmontools
Für SSD und "normalen" Festplatten gibt es die "smartmontools" mit denen man Statusinformationen von Festplatten auslesen kann ("smartctl -a <device>"). Leider scheint dies auf SD nicht zu funktionieren, und auch sonst sind auch keine Möglichkeiten bekannt um effektiv die verbleibende "Lebensdauer" einer SD-Karte zu bestimmen. [ Bitte dieses Wiki anpassen, wenn welche bekannt sind]. Deswegen sind die folgenden Optimierungen potentiell unnötig weil die SD Karte vielleicht auch ohne diese Verbesserungen länger lebt als der RPI oder es einfacher ist, einfach die SD-Karte alle paar Jahre gegen eine neue auszutauschen.
Schreibzyklen durch Filesystemzugriffe minimieren
Durch Editieren von /etc/fstab wie folgt:
# /etc/fstab ... /dev/mmcblk0p2 / ext4 defaults,noatime,nodiratime,discard,errors=remount-ro 0 1
Noatime bewirkt, dass man lesenden zugriff auf Dateien die "acces time" im Dateissytem nicht aktualisiert wird. Dies spart viele Schreibzugriffe auf die Metadaten im Dateisystem. Nodiratime bewirkt dasselbe für Lesezugriffe auf Verzeichnisorder. Discard bewirkt, dass das ext4 Dateisystem versucht dem Speichergerät über TRIM Befehle mitzuteilen, welche Sektoren frei sind. Errors=remount-ro bewirkt daß im Fehlerfall keine weiteren Schreibzugriffe auf das Dateisystem passieren.
Nach diesen Änderungen rebooten.
Das Kommando mount zeigt an, mit welchen Optionen die Dateisysteme gemounted sind um die Resultate zu kontrollieren:
# mount /dev/root on / type ext4 (rw,noatime,nodiratime,discard,data=ordered)
Explizites trimming
Um explizit TRIM Befehle an das Dateissytem abzusetzen kann fstrim verwendet werden.
# sudo fstrim -v / /: 12345678 bytes were trimmed
Dabei wird angezeigt, wieviele Sektoren dem Speichermedium als frei gemeldet werden. Wenn die option 'discard' beim mounten gesetzt ist, dann werden anscheinend beim ersten mal fstrim alle beim booten freien Sektoren gemeldet, aber bei weiteren Aufrufen von fstrim keine weiteren, weil das Ext4 filesystem wegen der discard Option freiwerdende Sektoren immer automatisch meldet. Statt discard in /etc/fstab zu verwenden könnte man also auch periodisch fstrim über einen cron Befehl absetzen. Dies wird bei größeren SSDs auf Serversystem häufig als die performantere Lösung empfohlen, ist wahrscheinlich aber bei einem client-VDR eine unnötig komplexe und vernachlässigbare Optimierung gegenüber discard.
Ermitteln der tatsächlichen Schreibzugriffe
Um die tatsächliche Anzahl an Schreibzugriffen auf der SD zu ermitteln:
iostat
Linux 3.12.35+ (raspi) 07.01.2015 _armv6l_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3,28 2,93 14,16 0,54 0,00 79,10
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
mmcblk0 3,15 72,78 1897,40 83297 2171588
Die angezeigte Zahl sind die Schreibzugriffe seit Reboot. Angenommen auf einer 8GByte SD sind noch 2.5GByte frei und werden effektiv für einfaches dynamic wear-level management verwendet, dann sind bei 2.2GByte (2200000 KByte) pro Tag nach 3 Jahren 1000 Schreibzyklen pro Zelle erreicht.
2.5GByte * 1000 / 3 / 365 = 2.2 GByte/tag
Ermitteln der Dateien
Um zu ermitteln, welche Dateien aktiv beschrieben wurden am besten 48 Stunden nur normalen Betrieb fahren (also kein Debugging, installation, etc..):
find / -xdev -ctime 1 -print
Dies zeigt alle Dateien die in den letzten 24 Stunden verändert wurden.
Den größten Teil der Schreibzugriffe im client-VDR sind wahrscheinlich die log dateien in /var/log und die VDR EPG Datei /var/cache/vdr/epg.data.
Um die Menge der Schreibzugriffe durch syslog zu reduzieren gibt es eine Reihe von Möglichkeiten, die hier nur angedeutet werden:
Alle Syslog Ausgagen auf eine datei leiten, alle anderen Ausgaben unterdrücken. Damit wird jede Logmeldung nur einmal, statt in der dfaultkonfiguration mehrfach geschrieben. In /etc/rsyslogd.conf:
*.* /var/log/syslog # ... alle anderen Dateien auskommentieren
Syslog auf den VDR Server umleiten.
Syslog auf ein tmpfs lenken.
Swap
In der Standardinstallation des RPI wird eine Datei als swap angelegt, /var/swap. Wenn diese verwendet wird, dann erzeugt diese Schreibzyklen. Dies sollte aber im VDR Clientbetrieb nie der Fall sein. Deswegen sollte es sich nicht lohnen, diese swap-Datei zu entfernen, da der Swapspace bei Installation/Entwicklung/Debugging evtl. gebraucht wird. Um zu kontrollieren ob der Swapspace nicht verwendet wird:
# swapon -s Filename Type Size Used Priority /var/swap file 102396 0 -1
Der used Wert muß 0 sein, wenn seit Reboot nur normaler VDR Betrieb stattgefunden hat.
TODO: Beschreibung wie die Swapdatei entfernt wird (hoffentlich nicht notwendig).
Journal
Eine zweite Option zur weiteren Optimierung der Schreibzugriffe ist das 'journal' des Ext4 Dateisystems. Dieses journal sorgt dafür, daß das Dateissytem auch nach Absturz korrekt ist, und beim Rebooten kein langer Filesystemcheck durchgeführt werden muß. Gerade wenn man den RPI evtl. durch den Benutzer unkontrolliert ausschalten lassen will sollte man das Journal nicht entfernen. Selbst wenn man weiß daß der RPI immer kontrolliert rebooted wird, werden nicht viele Schreibzyklen gespart: In der Standardinstallation (data=ordered für das Dateissytem) werden nur die Metadaten bei Schreibzugriffen doppelt, also durch das Journal geschrieben, nicht aber die eigentlichen Dateiinhalte, und diese stellen im VDR Clientbetrieb den überwiegenden Teil der Schreibzugriffe dar.
Wenn man das Journal vom Root-Dateissytem entfernen will muß man die SD als zusätzliche SD (eg: via USB) anschließen, da sich das Journal nur bei ungemounteten/ro-gemounteten Dateissytem entfernen läßt, und beides ist für das Root-Dateissytem nicht möglich. Beispiel:
# Mounte Ziel-SSD per USB, dann entferne journal sudo tune2fs -O ^has_journal /dev/sda2 fsck /dev/sda2
