Endlich auch mal eine SSD

Nachdem ab heute die dreijährige Garantie von meinem Apple MacBook Pro abgelaufen ist, habe ich mich entschieden, das Gerät ein wenig zu pimpen. Neben dem Austausch des Arbeitspeicher – von insgesamt vier auf acht Gigabyte – werde ich die 320 Gigabyte grosse Festplatte durch eine etwas kleinere 250 Gigabyte grosse Solid State Disk (SSD) ersetzen. Diese Maßnahmen sollen dem Gerät noch einmal einen kleinen Speedpump geben. Wurde uns ja schliesslich seit Jahren erzählt, dass wir immer schnellere Prozessoren brauchen, hat sich in den letzten Jahren doch heraus kristallisiert, dass doch die Festplatten mit ihren drehenden und sonstig bewegenden Teilen den Flaschenhals in einem Computer bilden.

Für meinen Laptop habe ich mich nun also für die Samsung 840 Basic-Variante mit 250 Gigabyte entschieden. Da der Computer, in der sie verbaut wird, schon eben drei Jahre alt ist, gibt sich allerdings schon eine kleine Einschränkung: Die Disk ist für die aktuelle Serial-ATA-Schnittstelle mit bis zu einer Transferrate von 6 Gigabit pro Sekunde konzipiert, während die Schnittstelle im Computer maximal 3 Gigabit pro Sekunde in der Lage zu transferieren ist. Zum Glück ist aber der S-ATA-Bus gegeneinander auf- und abwärts kompatibel. So kann ich zwar nicht die volle Leistung der SSD ausschöpfen, aber sie liegt deutlich über die einer konventionellen Festplatte, so dass zumindest der Bus bis zum Maximum ausgenutzt wird. So liegen die Lese- und Schreibgeschwindigkeit in einem Benchmark beide bei 210 bis 220 Megabyte pro Sekunde. Obwohl sie laut Datenblatt bis zu 540 Megabyte pro Sekunde lesen und 250 Megabyte pro Sekunde schreiben kann. Die herkömmliche Festplatte schaffte in dem selben Benchmark nur 210 Megabyte pro Sekunde im Lesen und 65 Megabyte pro Sekunde im schreiben.

Benchmark HDD

Benchmark HDD

Benchmark SSD

Benchmark SSD

Eine Anwendung, wo dieses Kernfeature schon deutlich zum Tragen kam, war das Verschlüsseln des Datenträgers auf Dateisystemebene. Hat diese mit FileVault2 bei der 320 Gigabyte grossen Festplatte über fünf Stunden gedauert, so waren es mit der 250 Gigabyte SSD nur noch 45 Minuten.
Ausserdem ergeben sich durch den Einsatz einer Solid State Disk noch zwei weitere Effekte: Zum einem ist eine SSD vom Gewicht viel leichter als eine herkömmliche Festplatte. Gemessen habe ich 45 Gramm (SSD) zu 104 Gramm (HDD). Das macht auch den tragbaren Computer insgesamt um circa 60 Gramm leichter. Ausserdem kommen hier keine beweglichen Teile mehr zum Einsatz, welche angetrieben werden müssen. So eine SSD verbraucht also auch weniger Strom. Was dazu führt, dass zum einem der Akku ein klein wenig mehr geschont wird und zum anderen, wenn sie extern über USB konnektiert werden, sie damit mal endlich die USB-Spezifikation hinsichtlich der Stromaufnahme nicht überschreiten.

Erwähnenswert wäre noch, welche Software ich für den „Plattentausch“ genutzt habe. Mit dem Carbon Copy Cloner habe ich die ursprüngliche Festplatte auf die Zielplatte, welche über FireWire oder USB extern an dem Rechner angeschlossen ist, eins zu eins geklont. So braucht diese dann nur noch einfach getauscht werden, ohne dass irgendetwas neu installiert werden muss.
Da es sich aber nicht um eine original von Apple verbaute SSD handelt, schaltet das Mac OS X den Trim-Befehl nicht ein. Obwohl der Befehl im Betriebssystem vorhanden ist, muss er manuell eingeschaltet werden. Hier empfiehlt sich das Programm Trim Enabler.

ZEVO ZFS Community Edition für Macintosh

Nach ewigen Hin und Her gibt es nun den Treiber für ZFS in einer kostenlos downloadbaren Community Edition. Der Nachteil von dieser gegenüber der vorherigen Kaufversion ist allerdings, dass man über das GUI-Frontend in den Systemeinstellungen keine Volumes erstellen kann, sondern nur den Intigritäts-Check durchführen kann.
Also werde ich hier mal einen kurzen Workaround aufstellen, wie man sich unter der Konsole ZFS-volumes erstellt und verwaltet.

Mit dem Befehl ls -l /dev/disk* lässt man sich erstmal alle verfügbaren Datenträger anzeigen.

sommteck:~ franky$ ls -l /dev/disk*
598 0 brw-r-----  1 root  operator    1,   0 27 Jul 21:26 /dev/disk0
600 0 brw-r-----  1 root  operator    1,   1 27 Jul 21:26 /dev/disk0s1
602 0 brw-r-----  1 root  operator    1,   2 27 Jul 21:26 /dev/disk0s2
604 0 brw-r-----  1 root  operator    1,   3 27 Jul 21:26 /dev/disk0s3
606 0 brw-r-----  1 root  operator    1,   4 27 Jul 21:26 /dev/disk1
835 0 brw-r-----  1 root  operator    1,   5 19 Aug 10:42 /dev/disk2
839 0 brw-r-----  1 root  operator    1,   6 19 Aug 10:42 /dev/disk2s1

Für eine detaillierte Auflistung aller Datenträger benutz man die Funktion list des Kommandozeilenprogramm diskutil.

sommteck:~ franky$ diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *320.1 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:          Apple_CoreStorage                         319.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Simba                  *318.9 GB   disk1
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *2.1 GB     disk2
   1:               Windows_NTFS Ohne Titel              2.1 GB     disk2s1

In der Ausgabe sieht man drei Datenträger.
/dev/disk0 ist der Erste und gleichzeitig die Festplatte des Computer auf der ich das hier veranstalte. Auf ihm liegt die Partitionstabelle, die EFI-Firmware des Computer selbst, die Partition mit dem Computerbetriebssystem und allerlei Daten, und eine spezielle Recovery-Partition für das Mac OS.
/dev/disk1 wird als ein weiteres Laufwerk angezeigt, ist aber in Wirklichkeit die Computerfestplatte und deshalb noch einmal aufgelistet, da es sich um ein LogicalVolume von Apple’s CoreStorage handelt, welches verschlüsselt ist.
/dev/disk2 ist schlussendlich der 2 Gigabyte große USB-Stick den ich für das ZFS verwenden möchte. Er beherbergt erst einmal ein Windows-Dateisystem.

Da die bisherige Community-Edition bisher keine bootfahigen ZFS-Volumes erstellen kann, zeigt der Befehl zpool showdisks nur die Laufwerksgeräte an, die für den Treiber in Frage kommen und man sollte nicht in der Lage sein, seine Systempartition zu zerschiessen. Also wird nur der USB-Stick angezeigt, der in Frage kommt und den ich verwenden will.

sommteck:~ franky$ zpool showdisks

DISK DEVICE      SIZE  CONNECTION    DESCRIPTION
/dev/disk2    1,91GiB  USB           SanDisk U3 Titanium Media

Jetzt ans Eingemachte! Mit zpool create wird ein ZFS-Volume mit einer Disk erstellt.

sommteck:~ franky$ sudo zpool create -f ZFS-Disk /dev/disk2

Da jetzt nun ein Laufwerk mit ZFS vorhanden ist, wird der Befehl zpool list eine Ausgabe geben.

sommteck:~ franky$ zpool list
NAME        SIZE   ALLOC    FREE     CAP  HEALTH  ALTROOT
ZFS-Disk  1,78Gi   672Ki  1,78Gi      0%  ONLINE  -

Mit zpool status und dem Namen des gewünschten Pool lassen sich die Informationen vertiefen.

sommteck:~ franky$ zpool status ZFS-Disk
  pool: ZFS-Disk
 state: ONLINE
 scan: none requested
config:

	NAME                                         STATE     READ WRITE CKSUM
	ZFS-Disk                                     ONLINE       0     0     0
	  GPTE_20835C0B-2B01-4E41-B117-3E88498CD134  ONLINE       0     0     0  at disk2s1

errors: No known data errors

Disclaimer:
Für meine Übungsbeispiele habe ich bewusst USB-Sticks genommen, weil sie einfach, leicht und handlicher als Festplatten sind. Allerdings performen sie so überhaupt nicht. Das Kopieren einer ca 700 MB grossen Filmdatei dauert mit ZFS auf ihnen ein vielfaches an Zeit, als wenn auf einem Stick ein FAT oder HFS+ betrieben wird. Beim Versuch, ZFS auf eine 250 Gigabyte grosse externe Platte zu bringen, wurden die Daten tatsächlich mit der Geschwindigkeit geschrieben, die auch der Bus zu leisten vermag. In dem Fall eine IDE-Platte.

USBIP auf einem Raspberry Pi starten

Innerhalb meiner Peergroup hatte die Tage jemand versucht, mit Hilfe der Linux-Software USBIP Geräte, welche an einem USB-Port hängen, auch für ein Netzwerk nutzbar zu machen. Im Gegensatz zu einem normalen Debian-Kernel für Standart-PC’s, sind die entsprechenden USBIP-Module aber für die ARM-Architektur im Kernel nicht enthalten. Und irgendwie scheint es prinzipiell wohl Probleme zu geben, die Treiber für den Kernel zu bauen. Dies trifft also nicht nur auf den Raspberry Pi, sondern auch so netter Embeded-Hardware wie der Dockstar. Nach ein bischen stöbern über die allseits bekannten Suchmaschienen bin ich aber hier auf eine – für’s erste funktionierende Lösung gestossen. Sie ist auf ein Debian Wheezy abgestimmt.

Als erstes sollte man sich vergewissern, dass man für sein Raspberry Pi sowohl den aktuellsten Kernel, als auch die neuen Firmware-Treiber und Module geladen hat. Dann wie folgt:

sudo apt-get install git
git clone git://github.com/raspberrypi/linux.git kernel
cd kernel
wget https://raw.github.com/raspberrypi/firmware/master/extra/Module.symvers
zcat /proc/config.gz > .config

Als nächstes öffnet man mit einem Editor die .config und fügt am Ende folgendes hinzu:

CONFIG_USBIP_CORE=m
CONFIG_USBIP_VHCI_HCD=m
CONFIG_USBIP_HOST=m
CONFIG_USBIP_DEBUG=n

Danach auf der Kommandozeile folgende Befehle absetzen:

make oldconfig
make LOCALVERSION=+ modules_prepare
make SUBDIRS=drivers/staging/usbip
sudo make SUBDIRS=drivers/staging/usbip modules_install
sudo depmod -a

Jetzt USBIP installieren:

sudo apt-get install usbip

Nun den Host-Treiber laden (um USB-Geräte teilen zu können)

sudo modprobe usbip-host

Zum Geräte auflisten:

sudo usbip list -l

Man sollte sich die Bus-ID merken, damit man das Gerät dann zum Teilen frei geben kann:

sudo usbip bind --busid 'BUSID'

Als Antwort kommt dann:

bind device on busid 'BUSID': complete

Für den Client wird dann folgendes ausgelöst:

sudo modprobe vhci-hcd
usbip list --remote 'pi ip'
sudo usbip attach --host 'pi ip' --busid 'BUSID'
lsusb

Telefonkonferenz unter Mumble

Ich kam die Tage in die Verlegenheit an einer Telefonkonferenz mit der doch noch relativ jungen Konferenzsoftware Mumble teilzunehmen. Bei dem allerersten Versuch vor fünf Wochen hatte ich für meinen Desktop die offizielle Mumble-Client-Version für Mac OS X benutzt. Obwohl bei der Einrichtung des Programm mit einem Server alles funktionierte, konnte ich bei der eigentlichen Konferenz nur zuhören, aber leider nicht aktiv teilnehmen. Bei der zweiten Konferenz habe ich dann mal die iOS-Applikation Mumble für iOS ausprobiert. Mit ihr konnte ich dann zwar aktiv an der Gesprächsrunde teilnehmen, aber ich bin dann aus Mangel an Erfahrungen in einige Probleme gerannt.
Prinzipiell währe es einmal sinnvoll, wenn man diverse Spracherkennungsdienste wie Siri auf dem iPhone abstellt. Sehr schön ist auch, wenn der Client einem die Möglichkeit bietet, einen Loopback-Test – also einen Rückopplungstest – durch zu führen. Für eine Mumble-Konferenz ist sicherlich auch ratsam, die Einstellung im Client auf Push-to-talk und die Qualität auf wenigstens 20 Millisekunden pro Audiopacket, beziehungsweise die Bandbreite niedrig zusetzen.
Ob diese Einstellungen der Weisheit ihr letzter Schluss sind, wird man bei der nächsten Telko herausfinden. Für ein optimales Verhältnis zwischen Sprachqualität und Audiolatenz wird bestimmt noch Raum sein.

Größere Dateien im WordPress-Blog verwenden

Ziel des eigenen WordPress-Blog gegenüber dem Freehost-Angebot von wordpress.org war es für mich doch, dass ich selber bestimmen kann, welche Dateitypen ich den Artikeln anhänge, ohne dabei auf die Größe der Content-Dateien achten zu müssen oder für individuelle Anpassungen von Design- und Featureset jedes mal einen zusätzlichen Obolus zahlen zu müssen. Ich hatte aber erst einmal nicht damit gerechnet, dass eine WordPress-Installation nicht Dateien größer 8 Megabyte zulässt. Entsprechen scheiterte der Upload einer mp3-Datei die eine Größe von 8,3 Megabyte hatte. Die Internetrecherche ergab aber, dass sich das auf unterschiedlichste Weise sehr schnell ändern lässt. Die folgende habe ich gewählt.:
Dabei werden in meinem Fall in der Datei .htaccess im Verzeichnis /var/www/vhosts/’Domain’/httpdocs folgende Zeilen am Anfang hinzugefügt. Existiert die Datei noch nicht, muss sie neu erstellt werden. Entsprechend sind dann den eigenen Wünschen nach die Limits der maximalen Uploadgröße zuändern. Je größer der Upload-Wert ist, desto höher muss auch die Verarbeitungszeit sein.

  1. php_value upload_max_filesize 8M
  2. php_value post_max_size 8M
  3. php_value max_execution_time 300
  4. php_value max_input_time 300