Testing TRIM with LUKS on LVM
One can find many guides on the net on how to test TRIM using dd and hdparm, which all describe the same procedure:
- create a random-filled file, sync it to disk
- determine the LBAs the file resides in using
hdparm --fibmap [file] - pick one sector, raw-read it with
hdparm --read-sector [sector] [device] - delete the random file, sync again
- verify TRIM was issued by reading the same block again, should return only zeroes
The problem with all these guides is that they don't say anything about the influence partitioning and other layers like LVM can have on the right LBA to use with hdparm --read-sector.
You must add any offsets resulting from either other partitions or payload-offsets from LVM, LUKS and thelike to the address you got from hdparm --fibmap!
I'll explain the concrete steps using my setup:
[alex@thor ~]$ fdisk -l /dev/sdd Disk /dev/sdd: 128.0 GB, 128035676160 bytes 255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xddfc7af4 Device Boot Start End Blocks Id System /dev/sdd1 * 2048 1050623 524288 83 Linux /dev/sdd2 1050624 250069679 124509528 8e Linux LVM
The PV our target LV resides on starts at sector 1050624, which is our first offset.
[alex@thor ~]$ dmsetup table root-plain: 0 56619008 crypt aes-xts-plain [keyslot] 0 254:0 4096 1 allow_discards m4vg0-root: 0 55050240 linear 8:50 2048 (...)
Here we can see that LVM has a payload offset of 2084 bytes and LUKS (dm-crypt) one of 4096 bytes (fits well for an SSD).
[alex@thor usr]$ hdparm --fibmap testfile
testfile:
filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 272600 272607 8So finally we calculate the "real" address of our chosen sector (the first one) by 272600 + 1050624 + 2048 + 4096 = 1329368.
Happy TRIM-testing, and keep in mind the implications for crypto-recurity!
Thinkpad X220 Power Saving
Das Thinkpad X220 leidet wie alle Rechner mit SandyBridge-Grafik (Intel HD 3000) an den Auswirkungen der aktuellen Kernel Power Regressions (siehe hier und hier), was zu CPU-Temperaturen über 50°C (idle!) und permanent relativ hoch drehendem Lüfter führt.
Mit folgenden Zeilen schaffe ich es im Idle auf 42°C und einen gelegentlich inaktiven Lüfter:
# /etc/rc.local # set governor cpufreq-set -g ondemand -c 0 cpufreq-set -g ondemand -c 1 # disable bluetooth echo disable > /proc/acpi/ibm/bluetooth # set brightness level echo 6 > /sys/class/backlight/acpi_video0/brightness # set vm laptop-mode echo 5 > /proc/sys/vm/laptop_mode # increase vm dirty writeback time echo 1500 > /proc/sys/vm/dirty_writeback_centisecs # set SATA link power management for D in /sys/class/scsi_host/host*/link_power_management_policy; do echo min_power > $D done # disable kernel nmi watchdog echo 0 > /proc/sys/kernel/nmi_watchdog # set pci/i2c bus power management for I in /sys/bus/{pci,i2c}/devices/*/power/control; do echo auto > $I done # enable scheduler power saving echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
In der Kernel-Line im Bootloader noch folgende Parameter:
pcie_aspm=force i915.i915_enable_fbc=1 i915.i915_enable_rc6=1
hdd-spindown.sh
Mal wieder Zeit gefunden, einen schon leicht angestaubten Punkt auf meiner 2code-Liste abzuhaken:
Ein Bash-Script, das Platten bei Inaktivität nach definierbarem Timeout per hdparm -y in Standby schickt. Für mich sehr nützlich bei SATA-Platten, die sich nicht per hdparm -S konfigurieren lassen.
Gehostet wie immer auf github, oder direkt hier:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | #!/bin/bash # # Automatic disk standby using kernel diskstats and hdparm # # Version 1.1, 2011 by Alexander Koch <lynix47@gmail.com> # # DEVICES syntax: DEVICE:TIMEOUT_SEC DEVICES=( "sda:120" "sdb:120" ) function device_worker() { test -e "/dev/$1" || return 1 logger -t hdd-spindown.sh "spawned monitor thread for $1" COUNT_R=0 COUNT_W=0 while true; do NEW_R=$(awk '{print $1}' /sys/block/$1/stat) NEW_W=$(awk '{print $5}' /sys/block/$1/stat) if [ $COUNT_R -eq $NEW_R ] && [ $COUNT_W -eq $NEW_W ]; then if hdparm -C /dev/$1 | grep active &>/dev/null; then logger -t hdd-spindown.sh "suspending $1" hdparm -qy /dev/$1 if [ $? -gt 0 ]; then logger "failed to suspend $1" return 1 fi fi else COUNT_R=$NEW_R COUNT_W=$NEW_W fi sleep $2 done } for D in ${DEVICES[@]}; do device_worker $(echo "$D" | cut -d ':' -f 1) $(echo "$D" | cut -d ':' -f 2) & done exit 0 |
Auf Performance-Optimierungen habe ich bewusst verzichtet und alles möglichst simpel gehalten.
Funktionsbedingt ist der einstellbare Wert für den Timeout (T) übrigens nicht hart; die reale Zeit an Inaktivität ti genügt der Bedingung T ≤ ti < 2T.
Thinkpad X220: BIOS Update
Mein kürzlich erstandenes Thinkpad X220 leidet unter den mit aktuellen Kerneln (~2.6.38 - 3.0.4) auftretenden Hitzeproblemen (Post folgt). Mit einem BIOS-Update soll sich laut Lenovo das Lüfterverhalten verbessern - Grund genug 
In diversen Wikis werden die unterschiedlichsten Methoden beschrieben, das von Lenovo bereitgestellte CD-Image ohne optisches Laufwerk und mit Linux-Bordmitteln gebootet zu bekommen. Mit der gängigsten Methode (syslinux) bekam ich jedoch nur einen kompletten Freeze (nebst verbundenem Schreck).
Funktioniert hat mit meinem X220 die Variante Using grub4dos. An den Temperaturen hat das soweit ich sagen kann aber nichts geändert.
SSD Encryption Benchmark
Kürzlich konnte ich dem allgemeinen Hype um SSDs nicht mehr widerstehen und habe das lästige Brummen meiner Systemplatte durch die Stille einer Crucial M4 mit 128GB ersetzt.
Die Wahl viel nicht auf eine aktuell recht günstig zu habende OCZ Vertex 2, da der SandForce Controller seine spezifizierten Transferraten nur durch hardwareseitige Kompression erreicht, und bei verschlüsselten oder bereits komprimierten Daten stark einbricht. Die Crucial-SSDs (M4 ebenso wie ihr Vorgänger C300) nutzen Marvel Controller und "tricksen" nicht durch Kompression.
Verschlüsselung und TRIM-Support
Bei Verwendung von SSDs ist der TRIM-Support entscheidend für Lebensdauer und Performance. Auf meinen HDDs verwende ich überall FDE mit LUKS (dm-crypt), was allerdings leider erst ab Kernel 3.1 TRIM unterstützen wird. Das neue Kernel-Release wird wohl erst im Oktober erscheinen; außerdem fehlt noch Userspace-Support für TRIM in cryptsetup.
Da für mich die Verschlüsselung der Daten unverzichtbar war, ein Unlocking per Login aber ungünstig finde (cron-jobs...), habe ich nun eine Hybridlösung im Einsatz: die Rootpartition (~1,2GB) bleibt weiterhin LUKS-verschlüsselt, während ich für /home auf Verschlüsselung auf Dateiebene zurückgreife. Wegen der vielen Berichte über miese Performance von EncFS (irgendwie einleuchtend wegen der vielen user<->kernel switches) habe ich mich für das in-kernel implementierte eCryptfs entschieden.
eCryptfs für /home
Wer LUKS gewöhnt ist, der hat mit eCryptfs am Anfang einige Umgewöhnung vor sich, denn eCryptfs arbeitet deutlich anders. Zum groben Setup habe ich mich an einem HowTo orientiert, allerdings lasse ich mein eCryptfs-Volume nicht beim Login über PAM mounten, sondern automatisch über /etc/rc.local (ist wegen blockverschlüsseltem root kein Problem).
Dazu habe ich die Passphrase in eine Datei unter /etc gepackt und nutze diese Zeile in der fstab:
# /etc/fstab (...) /home.crypt /home ecryptfs rw,verbosity=0,ecryptfs_sig=XYZ,ecryptfs_passthrough=n,key=passphrase,passphrase_passwd_file=/etc/vol.key,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_fnek_sig=XYZ,ecryptfs_unlink_sigs 0 0
Benchmarks
Nun zum titelgebenden Inhalt: Benchmarks 
Natürlich wollte ich wissen, wie viel Performance ich durch die SSD gewinne, bzw. welcher Anteil davon durch die Verschlüsselung wieder flöten geht.
Gemessen habe ich die Transferraten beim Lesen bzw. Schreiben einer 1GB-Datei per dd:
[alex@thor bench]$ LC_ALL=C dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 10.7813 s, 99.6 MB/s [alex@thor bench]$ sudo su -c "echo 3 > /proc/sys/vm/drop_caches" [alex@thor bench]$ LC_ALL=C dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 13.583 s, 79.1 MB/s
Als Dateisystem kam überall ein korrekt align'tes EXT4 zum Einsatz, mit aktivierter discard-Option wo möglich. Darunter lag über dem physischen Layer noch ein ebenfalls sorgfältig eingerichtetes LVM. Zum Vergleich habe ich auch noch mein Software-RAID1 (Blogpost folgt) auf zwei herkömmlichen HDDs (WD Caviar Green WD20EARS) getestet, wo ebenfalls EXT4 auf LUKS auf LVM zum Einsatz kommt.
Wie man sehen kann erreicht die SSD zwar nicht ganz ihre Datenblatt-Werte, aber da diese sowieso immer recht utopisch sind und ich die Platte nur an einem SATAII-Port hängen habe, bin ich mit den Transferraten für unverschlüsselte Dateisysteme zufrieden.
Alle Werte für verschlüsselte Dateisysteme zeigen einen Performanceverlust, der beim Lesen deutlich größer ist als beim Schreiben - darüber muss ich noch nachdenken
Hier geht es mir aber um den Vergleich LUKS-eCryptfs, der deutlich zu Gunsten von LUKS ausfällt.
UPDATE: LUKS+TRIM, Mehr Benchmark
Hier noch ein überaus interessanter Artikel zu Folgen von TRIM auf dm-crypt Volumes aus kryptographischer Sicht.
Außerdem noch ein Screenshot des Disk-Benchmarks palimpsest (ehemals Teil des gnome-disk-utilitiy), der die Transferraten auf der unformatierten M4 (nach Firmware-Update) zeigt:
BeQuiet – wörtlich
Nach nun fast drei Jahren hat der Lüfter meines Netzteils (BeQuiet Dark Power Pro 750W) im unteren Drehzahlbereich hochgradig nervige Betriebsgeräusche entwickelt.
Entgegen einiger Forenbeiträge ließ er sich jedoch mit etwas Basteleinsatz (Kabel trennen und neu verbinden, Klemme irgendwo unterbringen) durch einen alten Papst-Lüfter ersetzen, der hier noch rumlag.
Ergebnis: himmlische Ruhe...
DBus durchsuchen
Wer den DBus durchsuchen möchte, um schnell herauszufinden, welche Calls eine bestimmte Anwendung anbietet, dem könnte DBusExplorer sehr nützliche Dienste tun.
Mir hat das gerade eine Brücke zwischen xbindkeys und Exaile geliefert, um per Multimediatasten den Player zu steuern:
# ~/.xbindkeysrc "dbus-send --type=method_call --dest=org.exaile.Exaile /org/exaile/Exaile org.exaile.Exaile.PlayPause" XF86AudioPlay "dbus-send --type=method_call --dest=org.exaile.Exaile /org/exaile/Exaile org.exaile.Exaile.Next" XF86AudioNext "dbus-send --type=method_call --dest=org.exaile.Exaile /org/exaile/Exaile org.exaile.Exaile.Prev" XF86AudioPrev
ALSA Power Saving unter Arch
Nach dem Wechsel der Soundkarte zurück auf die Semi-Onboard-Lösung hatte ich ein kleines Soundproblem: kurze Sounds (Mail-Benachrichtigungen, Chat-Töne, etc.) wurden gar nicht oder nur teilweise abgespielt - es fehlten oft die ersten Millisekunden.
Das Problem verursachte das aktivierte Power Saving feature des verwendeten Moduls snd_hda_intel. Hier sind zwei Parameter relevant:
power_save: setzt den Timeout für den Power Saving Modus
(in Sekunden, 0=deaktiviert)-
power_save_controller: Schaltet im Power Save auch den Controller ab
(Y=aktiviert, N=deaktiviert)
Der zweite Parameter wird unter Arch standardmäßig auf Y gesetzt, was einen tieferen Schlaf für den Soundchip, aber auch eine dementsprechend längere Aufwachphase bewirkt. Durch Deaktivieren dieses Features konnte ich mein Problem mit den Benachrichtigungen lösen.
Übrigens: in der /etc/conf.d/alsa wird leider nicht ganz deutlich, dass über POWERSAVE direkt der Timeout-Wert gesetzt wird, d.h. es sind auch Werte >1 zulässig:
# Enables powersaving mode for AC97 and hda_intel audio chips. # Set to 1 to enable powersaving. # Set to 0 to disable powersaving (default). POWERSAVE=10
ALSA: Best Config is No Config
Nach einigen Problemen mit dem angelöteten Frontpanel-Ausgang an meiner guten, alten Audigy 2 musste ich nun doch zurück zur Semi-Onboard-Lösung greifen und habe die beim Board mitgelieferte Pseudo-X-Fi eingebaut. Da das Teil kein Hardware-Mixing unterstützt musste ich meine /etc/asound.conf bearbeiten, um korrektes Upmixing inkl. dmix zu bekommen.
Das Erstaunliche dabei: es funktioniert am besten gänzlich ohne /etc/asound.conf
Out-of-the box, inkl. korrektem Upmixing von Stereo auf 5.1. Hier also der Tip bei Problemen mit aktuellem ALSA und vorhandener Config: vielleicht einfach mal ohne probieren...
Netbox Fan-Mod
Mehr Kühlung kann die NetBox-nT330i aus dem Hause Foxconn gut gebrauchen: im Auslieferungszustand liegen die Temperaturen im Idle unter Xorg bei ca. 35°C für den Atom 330 und ca. 41°C auf der NVIDIA ION GPU.
Der Umstand des laufenden Xorg ist hier nicht zu vernachlässigen: ein bloßes Laden des nvidia-Moduls lässt den Grafikchip scheinbar nicht runtertakten - erst eine richrige Xorg-Instanz bewirkt das. Die CPU unterstützt kein Frequency Scaling und läuft daher immer mit Volldampf.
Wenn man die Box als HTPC verwenden möchte, stört einen der schon im Idle relativ hoch drehende, kleine Lüfter enorm - mal ganz davon abgesehen, dass die Temperaturen unter Last (HD-Videos per vdpau) kritische Bereiche anschneiden (~46°C CPU, ~70°C GPU) . Es besteht also Handlungsbedarf - hooray, ein Grund zum Basteln!
Da die Halterung für die ab Werk verbaute Kühler-Lüfter-Kombination proprietär zu sein scheint, scheidet ein Austausch der beiden aus. Die Wärmeleitpads hatte ich gleich zu Beginn durch Arctic MX-3 ausgetauscht, was aber nur leichte Verbesserungen brachte (~1°C). Neben der Idee, durch zusätzliche Kupferplättchen die Wärmeübertragung zum Standardkühler zu verbessern bleibt also nur die Verbesserung der Frischluftzufuhr: Case Modding.
Nach diversen Versuchen mit kleinen 8er Bohrungen auf der Oberseite des Gehäuses (siehe Löcher mit Klebestreifen) habe ich nun mit großem Geschütz in Form eines alten 120mm CoolerMaster-Lüfters, der für den Einsatz im PC-Case zu schwach, aber dafür recht leise war, Erfolg. Durch die komplett ausgesägte Öffnung in der Oberseite wird nun genügend kühle Luft angesaugt, die nebenbei auch noch Platte und RAM kühlt. Befestigt habe ich das Ding mit den üblichen Senkkopfschrauben von Innen.
Die Temperaturen bleiben auch unter Last mit 26°C CPU und 31°C GPU so niedrig, dass der integrierte Lüfter nur noch selten anspringt, und die verbaute Platte bleibt ebenfalls unter 32°C.
Den ohnehin schon recht leisen CoolerMaster-Lüfter betreibe ich an einem der rückseitigen USB-Ports, wo er aufgrund der Spezifikationen mit lediglich 100 mA laufen muss und daher auch nicht seine maximale Drehzahl erreicht - praktisch lautlos.
So betreibe ich das Ding unter Arch mit XBMC als MediaCenter, und umgebauter XBOX-Fernbedienung.