• 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          8

So 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!

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

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 t_i genügt der Bedingung T ≤ t_i < 2T.

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.

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:

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...

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

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

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...

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.