Svens Netzblog - Unix

Mehr Platz, Igor!

sven@svenhartge.de (Sven Hartge) — Fri, 01 Apr 2011 21:38:28 +0200

Heute habe ich mich endlich dazu aufgerafft, meinem Datenelend ein Ende gemacht und zwei Platten zu je 3TB (mit internen 4K-Sektoren und externen LBAs mit 512 Bytes) gekauft.

Pro: Mehr Platz als, ich ~~jemals~~ in der für mich absehbaren näheren Zeit brauchen werde. Aber 640K Hauptspeicher waren ja auch schon immer genug für jeden.

Contra: 10 Stunden Sync-Zeit für das RAID1, dass ich daraus gebaut habe. (Ja, ich bin ein wenig Paranoid, was Festplatten angeht. Die meisten meiner Daten fallen jetzt nicht in die Kategorie "überlebenswichtig", aber ich fände es blöd, wenn ich z.B. meine CD-Sammlung wieder neu rippen müsste, weil dies dann doch einige Tage in Anspruch nehmen würde. Echte lebenswichtige Daten habe ich als Backup auf a) Band, b) verschlüsselt in der Dropbox und c) auf DVD oder CD [die ich einmal im Jahr prüfe, ob die Lesbarkeit noch gegeben ist]) Immerhin setzt Linux den Sync an der letzten Stelle fort und fängt nicht immer von vorne an.

Ein wenig abenteuerlich war auch die Partionierung. Eine normale MSDOS-Partitionstabelle reicht nicht mehr, es muss eine GPT (GUID Partition Table) sein. Und da die Platten intern Sektoren mit 4KB-Größe arbeitet, möchte man auch dafür sorgen, dass die Partitionen und damit die Dateisysteme innerhalb der Partitionen an eben diesen 4KB-Sektoren ausgerichtet (aligned) sind. Sonst wird man eine erstaunliche Verlangsamung von Schreibzugriffen bis zu Faktor 10 erleben.

In meinem Fall habe ich die korrekte Partionierung mit parted durchgeführt.

Richtige Platte auswählen:
> select /dev/sdX
Partitionstabelle anzeigen lassen, ob man auch wirklich die richtige Platte hat:
> print
GPT erzeugen:
> mklabel gpt
BIOS Boot Partition erzeugen. Dies wird gebraucht, weil direkt in der GPT kein Platz für das core.img von GRUB ist. Das Alignment ist hier egal, da auf diese Partition eh nur während der Installation von GRUB geschrieben wird.
> mkpart primary 34s 2047s
> set 1 bios_grub on
Die 33 Sektoren am Anfang werden von der GPT eingenommen und fallen daher weg. Will man von dieser Platte nicht booten, so kann man sich diese Partition theoretisch schenken. Aber da man für die korrekte Ausrichtung bei 4KB-Sektoren intern und externen 512 Byte LBAs als kleinsten nutzbaren Sektor bei 40s ist und man nie weiss, ob man nicht doch einmal GRUB auf die Platte installieren will oder muss, sollte man die BIOS Boot Partition gleich mit anlegen, später geht das nämlich nicht mehr.
Es ist übrigens egal, wo man die BIOS Boot Partition anlegt, generell wird aber empfohlen, diese an den Anfang, mindestens aber unterhalb der magischen Grenze von 2^32-1 Sektoren (also 2TB) anzulegen.
Dateisystem-Partition im kompletten restlichen Bereich anlegen und RAID-Flag setzen. Hierbei ist es wichtig, auf die Ausrichtung zu achten. Bei einem Verhältnis von internen zu externen Sektoren von 8 (also 4096B / 512B) muss der Start-Sektor also glatt durch 8 teilbar sein. 2048 erfüllt diese Kriterium. Für SSDs muss man ebenso rechnen, allerdings gilt es hier, die Größe des Flash-Erase-Blocks zu kennen, der meist 64KB oder 128KB ist. Bei einem Verhältnis von 131072/512 gilt also 256 als magischer Teiler. Präsentiert die SSD dagegen 4K-Sektoren nach aussen, so sinkt dieser Wert auf 32. Alles in allen würde 2048 diese Kriterien auch erfüllen, ist also ein guter über-den-Daumen Wert. (Wenngleich 2048 Sektoren bei 4K-Sektoren auch schon 8MB Verschnitt sind. Bei Plattengrößen von 256GB für SSDs oder 3TB für Magnetscheiben ist dies aber mehr als verschmerzbar, denke ich.)
> mkpart primary 2048s -1s
> set 2 raid on
Und nun das ganze Procedere für die zweite Platte wiederholen.

Danach dann wie gewohnt mit mdadm -C das RAID erzeugen, Dateisystem oder LVM drauf packen, fertig.

Linux und Trafficshaping

sven@svenhartge.de (Sven Hartge) — Wed, 10 Nov 2010 00:03:00 +0100

Ein klarer Fall von "Hä?!":

Ich stelle via tc eine maximale downstream Rate von 16000kbit ein.

Und was erhalte ich?

Eine maximale Downloadrate von ca. 4500kbit. Komisch.

OK, probieren wir einmal eine fertige Lösung, z.B. den guten alten Wondershaper (http://lartc.org/wondershaper/):

wondershaper eth1 16000 1000

Und wir erhalten:

Eine maximale Downloadrate von ca. 4500kbit. Hmmm.

Nehmen wir etwas anderes, das gerade im Linux Magazin besprochene tc-Script (http://www.linux-magazin.de/static/listings/magazin/2010/12/TC/):

trafficcontrol-inetgw eth1 16000 1000

Und wir erhalten:

Eine maximale Downloadrate von ca. 4500kbit. Hmmmmm!

Vermutlich bin ich zu doof, zu blöd, mein Kernel (2.6.32.x) ist zu alt, das Karma nicht richtig justiert, oder tc nimmt mir übel, das ich es früher einmal als undokumentiertes Stück esoterischen Code tituliert habe.

Ich glaube, ich werde meine Tage mit einer ungeshapeten Verbindung verleben müssen, denn einerseits funktionieren die fertigen Lösungen irgendwie nicht richtig und andererseits übersteigt die Logik und Syntax von tc einfach meinen Horizont. Ich habe nun schon so oft versucht, mir das anzueignen, aber die Dokumentation ist einfach grottig, die vorhandenen Beispiele in der Dokumentation sind für mich nichtssagend und die Beispiele im Netz sind ebenso unter- bzw. undokumentiert oder beziehen sich auf uralte Kernel und Methoden.

Ich geb's echt auf. Da administriere ich lieber Windows auf der Kommandozeile als noch einmal tc zu verstehen zu versuchen zu wollen.

ext4 oder XFS für Maildir?

sven@svenhartge.de (Sven Hartge) — Thu, 04 Nov 2010 22:16:02 +0100

Was ist wohl besser geeignet für einen Maildir-Storage von ca. 1TiB Größe?

XFS, mit mkfs.xfs -f -d su=64k,sw=5 -l size=32768b,version=2 /dev/mapper/vg03-maildir_lv erzeugt
oder ein ext4

Das ganze auf einem via FC-4GBit angeschlossenen RAID5 mit 5 Platten und 64k Stripe-Size. Der Server hat mit 12GB genug Speicher für Cache und Co.

(ReiserFS3 fällt weg, da es praktisch ungewartet ist und es diverse Berichte gibt, dass es unter Last gerne mal zusammenbricht, Reiser4 muss auch wegen der sehr unklaren Entwicklungssituation ausscheiden.)