# SSD Systemlaufwerk mit LUKS, LVM und EXT4 + TRIM

## SarahS93

Auf dem Systemlaufwerk, einer 256GB SSD läuft der 3.10.7-gentoo-r1 Kernel.

Es funktioniert soweit auch mit LVM2 und LUKS, aber noch ohne TRIM funktion.

Bin auch noch verunsichert wie das mit TRIM funktionieren soll.

Bei der Installation und Partitionierung mit fdisk hab ich das Laufwerk so aufgeteilt das sda1 1GB hat und sda2 den Rest.

fdisk -l

```
Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors

Units = Sektoren of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0xe310eb7d

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System

/dev/sda1   *        2048     2099199     1048576   83  Linux

/dev/sda2         2099200   486541311   242221056   83  Linux
```

...

```
cryptsetup -v -c aes-cbc-essiv:sha256 -h sha -s 256 luksFormat /dev/sda2

cryptsetup luksOpen /dev/sda2 main

pvcreate /dev/mapper/main

vgcreate vg01 /dev/mapper/main

lvcreate -L 1G -n swap vg01

lvcreate -L 225G -n root vg01

   mkswap /dev/vg01/swap 

mkfs.ext4 /dev/vg01/root

mount /dev/vg01/root /mnt/gentoo

mount /dev/sda1 /mnt/gentoo/boot

mount -t proc none /mnt/gentoo/proc

mount -o bind /dev /mnt/gentoo/dev

chroot /mnt/gentoo /bin/bash

env-update

source /etc/profile

export PS1="(chroot) $PS1"

...
```

...

In der Kernel Konfiguration LVM Crypt target und unter Cryptographic API alles benötigte eingeschaltet.

...

```
emerge -av lvm2 cryptsetup genkernel

genkernel --lvm --luks --install initramfs
```

...

/etc/fstab

```
/dev/sda1               /boot           ext2            noatime             1 2

/dev/mapper/vg01-root   /               ext4            noatime             0 1

/dev/mapper/vg01-swap   none            swap            sw                  0 0
```

...

/boot/grub/grub.conf

```
default 0

timeout 5

title   linux_x86_64-3.10.7-gentoo-r1

root    (hd0,0)

kernel  /boot/linux_x86_64-3.10.7-gentoo-r1    dolvm    root=/dev/ram0    init=/linuxrc    ramdisk=8192    crypt_root=/dev/sda2    real_root=/dev/mapper/vg01-root    rootfstype=ext4    vga=ask

initrd  /boot/initramfs-genkernel-x86_64-3.10.7-gentoo-r1
```

...

Soweit meine Installation.

Nach einem Neustart bootet es auch durch, ich gebe mein LUKS Passwort ein und er bootet weiter.

Was muss ich alles tun damit TRIM verwendet wird?

In manchen Anleitungen im Netz lese ich etwas wie z.B. "fdisk -H 32 -S 32 /dev/sda" muss verwendet werden damit später  .."irgendwelche größen vom Dateiensystem zu der Sektorengröße der Flashbausteine auf dem Laufwerk passen", oder so ähnlich, hatte das nicht ganz verstanden.

In anderen Anleitungen wird nur das Programm fstrim per cronjob täglich ausgeführt. Ich bin verwirrt.

Was muss im Kernel eingestellt werden damit TRIM funktioniert?

Ich bin auch verunsichert ob ich LVM überhaupt brauche und will.

Genug Arbeitspeicher hat mein Computer, 16GB. Brauche ich ohne die Swap-Partition überhaupt LVM?

Wie habt ihr das geöst?!Last edited by SarahS93 on Wed Nov 27, 2013 10:40 pm; edited 2 times in total

----------

## Fijoldar

Hallo,

für die Trim Funktion reicht es, in der fstab die discard Funktion zu aktivieren: Bei mir sieht es so aus

```
/dev/sda1               /               ext4            defaults,relatime,discard        0 1
```

Ein manuelles trimmen ist da meiner Meinung nach nicht notwendig. Das ext4 Dateisystem kann mit SSDs gut umgehen.

Das Wiki (http://wiki.gentoo.org/wiki/SSD) sagt noch, dass man folgende Optionen setzen soll:

LVM

Datei /etc/lvm/lvm.conf

```
devices {

  [...]

  issue_discards = 1

} 
```

LUKS

Datei /etc/default/grub

```
GRUB_CMDLINE_LINUX_DEFAULT="[...] root_trim=yes"
```

Wenn nur eine Partition verschlüsselt wird, könnte man natürlich auf LVM verzichten. Ich würde allerdings eine kleine Swap Partition beibehalten. Gerade wenn man den Standby Modus verwenden möchte, braucht man ihn ja. Außerdem ist es gerade für größere Pakete wie LibreOffice sicherer, wenn man da etwa Puffer hat.

----------

## SarahS93

Danke für die Infos.

Von welchem Datum ist diese Anleitung? -> http://wiki.gentoo.org/wiki/SSD

Wie wichtig sind Sachen wie "mkfs -t ext4 -b 4096 /dev/sda2"?

Naja, wenn der freie Arbeitsspeicher zu eng wird, kann doch eine Swap-Datei auf / erstellt und als Swap gemountet werden.

In den Standby fahre ich meinen Computer nicht  :Wink: 

----------

## Fijoldar

 *Quote:*   

> This page was last modified on 30 September 2013, at 18:13

 

Die Anleitung sollte also noch stimmen  :Wink: 

Was du da ansprichst ist das richtige Alignment der Partition, was bei der Erstellung wichtig ist. Gängige Tools sollten das aber automatisch richtig machen. Um das überprüfen kann man folgendes machen

```
fdisk -l -u /dev/sda
```

Entscheidend ist dann der Wert Anfangssektor, welcher durch 2048 teilbar sein solle. Die Ausgabe sollte also so etwas liefern:

```

Disk /dev/sda: 120.0 GB, 120034123776 bytes, 234441648 sectors

Units = Sektoren of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0xfc522136

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System

/dev/sda1            2048   234440703   117219328   83  Linux

```

----------

## SarahS93

OK, da hätte ich mal bis ganz unten, und nicht nur bis dreiviertel lessen sollen  :Wink: 

Ob ich nun "fdisk -lu /dev/sda" oder "fdisk -l /dev/sda" mache, die Ausgabe ist bei mir immer die gleiche.

```
Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors

Units = Sektoren of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0xe310eb7d

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System

/dev/sda1   *        2048     2099199     1048576   83  Linux

/dev/sda2         2099200   486541311   242221056   83  Linux
```

Habe fdisk (util-linux 2.22.2).

Mit mkfs.ext4 /dev/vg01/root habe ich bei mir formatiert.

hätte ich das mit "-b 4096" machen sollen?

Nebenbei noch die frage, ist die option -j wichtig bei der formatierung mit ext4?

----------

## Fijoldar

Das Alignment ist ok. Da brauchst du dir keine Gedanken mehr zu machen. Die Option "-b 4096" ist die Standardeinstellung , d.h. wenn du es nicht extra angibst, dann macht der das automatisch.

Ich würde wie gesagt einfach nur noch die "discard" Option in die fstab hinzufügen. Dann sollte soweit alles stimmen.

Die Option -j sollte an dieser Stelle egal sein. Habe ich selbst noch nie benutzt. Wenn du es nicht ganz bewusst brauchst, dann würde ich es lassen.

 *Quote:*   

>      -j     Create the filesystem with an ext3 journal.  If the -J option is not specified, the default journal parameters will be used to create an appropriately sized journal (given the
> 
>               size of the filesystem) stored within the filesystem.  Note that you must be using a kernel which has ext3 support in order to actually make use of the journal.

 

(Aus man mkfs.ext4)

----------

## SarahS93

Wie kann ich mir im laufendem System anzeigen lassen welche "block-size" ein Dateiensystem hat?

Arbeiten Flashbausteine wie sie in SSD Laufwerken sind nicht mit 512 byte?

Wenn das Dateiensystem 4096 Byte pro Sektor benutzt, passt das denn dann noch ohne das übermässig viel geschrieben und gelöscht wird was vermieden werden könnte?

----------

## Fijoldar

Das geht z.B. mit

```
tune2fs -l /dev/sda1 | grep "Block size"
```

Es ist zumindest die Standard-Einstellung und wird so auch in vielen Anleitungen beschrieben. Daher würde ich das auch so lassen. Dass man jetzt besonders darauf achten muss, dass nicht viel auf die Platte geschrieben wird, gehört mittlerweile auch der Vergangenheit an. Moderne SSDs haben eine längere Lebensdauer als herkömmliche mechanische Platten. Selbst wenn man mehrere GB am Tag auf die Platte schreiben sollte, hält sie immer noch viele Jahre. Das sollte also kein großes Problem sein.

----------

## SarahS93

```
tune2fs -l /dev/sda1 | grep "Block size"

Block size:               4096
```

OK, das sieht dann wohl gut so aus ....

....

grub.conf

```
  title   linux_x86_64-3.10.7-gentoo-r1 

  root    (hd0,0)

  kernel  /boot/linux_x86_64-3.10.7-gentoo-r1_2  dolvm  root=/dev/ram0  init=/linuxrc  ramdisk=8192  crypt_root=/dev/sda2  allow-discards  root_trim=yes  real_root=/dev/mapper/vg01-root  rootfstype=ext4  vga=791

  initrd  /boot/initramfs-genkernel-x86_64-3.10.7-gentoo-r1
```

/etc/lvm/lvm.conf

```
  devices {

    [...]

    issue_discards = 1

  }
```

/etc/fstab

```
  /dev/mapper/vg01-root   /               ext4            noatime,discard     0 1
```

/etc/conf.d/local

```
echo noop > /sys/block/sda/queue/scheduler
```

Funktioniert!

Beim Booten, bevor ich mein Passwort eingebe, erscheint eine Zeile die sagt das Trim aktiviert ist.

"Enabling Trim Support for Root."

Im System dann:

dmsetup table /dev/mapper/root --showkeys

```
0 484438016 crypt aes-cbc-essiv:sha256 79e6db087affab501f2afaeb70300e31ae1eae7c431209f99bc30d257811ff 0 8:2 4096 1 allow_discards
```

sagt doch aus das Luks Wind bekommen hat das da was mit Trim gemacht wird, oder?!

Wenn ich jetzt soetwas ausprobiere:

```
echo "ABCDEFGHIJKLMNOPQRSTUVWXYZ" > /home/tempdatei1.txt

sync

hdparm --fibmap /home/tempdatei1.txt

hdparm --read-sector 46458680 /dev/sda

rm /home/tempdatei1.txt

sync

hdparm --read-sector 46458680 /dev/sda
```

ist der besagte Sektor nicht mit 0en Voll, den reingeschriebene Inhalt ist noch da.

Greift die Trim funktion doch noch nicht richtig oder ist mein Weg es so zu testen fehlerhaft?

Wie habt Ihr überprüft ob Trim richtig funktioniert?Last edited by SarahS93 on Wed Nov 27, 2013 10:50 pm; edited 2 times in total

----------

## Fijoldar

Hm...ich denke das funktioniert so nicht. TRIM heißt ja nicht, dass wenn du eine Datei löschst, der Bereich mit Nullen überschrieben wird, sondern nur, dass der Bereich wieder freigegeben wird.

 *Quote:*   

> Wie habt Ihr überprüft ob Trim richtig funktioniert?

 

Ganz ehrlich? Gar nicht! Ich selbst habe das noch nie selbst überprüft. Ich vertraue da meinem System, dass das schon richtig funktioniert. Meine SSD rennt jetzt auch schon gut ein Jahr und ich habe noch keinerlei Performance Verluste  wahrgenommen. Daher denke ich mal, das funktioniert schon so wie es soll.

Wenn du aber wirklich einen richtigen Test möchtest, bin ich an dieser Stelle überfragt.  Vielleicht hilft dir da folgender Wiki Artikel eher weiter: http://wiki.ubuntuusers.de/SSD/TRIM/Testen

----------

## frostschutz

Ich habe auch SSD/LUKS/LVM und TRIM funktioniert.

Das allow_discards in lvm.conf betrifft nur lvremove/resize (dann wird ein discard für die Region gemacht die nicht mehr von einem LV belegt wird). Ansonsten blockiert LVM gar kein TRIM.

Du musst eig. nur LUKS selbst auf discard stellen (cryptsetup luksOpen mit --allow-discards). Das ist defaultmäßig aus und verhindert damit den TRIM.

Bei deinem Test mit hdparm kann es sein daß du das falsche Offset verwendest. Ebenso können Caches alte Daten liefern. Probiers mal mit dieser Methode hier (mit yes-dd-filefrag-hexdump statt hdparm): http://wiki.ubuntuusers.de/SSD/TRIM/Testen

----------

## SarahS93

Naja, beim booten soll trim für / aktiviert werden, ich denke das tut soweit auch mit den besagten Optionen.

Wie müsste ich es konfigurieren wenn ich zusätzlich die möglichkeit haben will einen USB mit einer Schlüsseldatei anzustecken damit er durch bootet und ich dafür nicht an der Tastatur das Passwort eingeben müsste?

----------

## SarahS93

fstrim -v / 

```
/: 231580737536 bytes were trimmed
```

Das sind über 200gb?!? Ist sowas normal?

----------

## Fijoldar

Ja, sollte schon stimmen. Bei mir kommen ähnliche Ergebnisse. Ein manuelles Trimmen mittels fstrim ist aber nicht nötig, falls man die Option "discard" aktiviert hat. Schaden tut es aber nicht  :Wink: .

----------

## SarahS93

Wenn ein fstrim -v / was trimmt, heisst es doch das die discard option nicht richtig greif?

----------

## Fijoldar

fstrim und discard wissen erstmal nichts voneinander. D.h. wenn du manuell fstrim ausführt, trimmt der alle freien Blöcke auch wenn sie durch discard schon "online" getrimmt wurden. Man darf sich davon nicht verunsichern lassen. In diesem Post ist das nochmal recht gut erklärt: http://forums.fedoraforum.org/showpost.php?p=1568303&postcount=2. Ich war zunächst auch etwas verunsichert, aber nach einer kurzen Recherche habe ich mich doch davon überzeugt, dass das seine Richtigkeit hat.

----------

## frostschutz

fstrim trimmt den gesamten freien Speicher des Dateisystems. Ob das schon getrimmt worden ist, kann fstrim nicht wissen (läßt sich von der SSD nicht ohne weiteres abfragen). Die SSD weiss das dann schon selbst, was sie daraus macht.

----------

## tazinblack

 *SarahS93 wrote:*   

> Wenn ein fstrim -v / was trimmt, heisst es doch das die discard option nicht richtig greif?

 

also ich hab irgendwo gelesen, dass es performanter sei, das FS nicht mit discard zu mounten und dafür lieber ein mal täglich fstrim zu verwenden.

So mach ich das auf meiner Workstation in der Firma. Die läuft aber auch 24*7. Auf dem Notebook würde ich auch lieber discard nehmen.

----------

## frostschutz

Ich benutze auch kein discard. Warum auch. fstrim läuft einmal die Woche. Einmal im Monat würde auch reichen. Solange das Dateisystem nicht bis zum Anschlag voll ist, sind dann immer genug getrimmte Blöcke für wear-leveling vorhanden. Mehr braucht man nicht. Aktuelle SSD machen wear-leveling zur Not auch ganz ohne TRIM, also auch wenn alle Blöcke als belegt gelten, das ist dann zwar langsamer aber die meisten User würden den Unterschied eh nicht bemerken.

Für einen Cron-Job muss die Kiste auch nicht 24/7 laufen. Es gibt @reboot oder cron.daily/weekly/monthly die genausogut funktionieren auch wenn die Kiste nur selten läuft.

Die Performanz von discard (also das Problem das du ansprichst) soll nebenbei auch verbessert werden, da gabs/gibts kürzlich/bald? in 3.x noch Verbesserungen. Ich verfolge das aber nicht so genau da ich es ja sowieso nicht nutze.

Laut http://www.thomas-krenn.com/de/wiki/Neuerungen_im_Linux_Kernel#Kernel_3.1 merkt sich ext4 nebenbei was schon getrimmt wurde, wodurch fstrim performanter arbeiten sollte. Das kann natürlich auf der anderen Seite den Nachteil haben, daß nach einer Kopieraktion (nach einem dd) die Dateisystem-Information falsch ist. Da ich kein ext4 verwende kann ich das aber nicht ausprobieren...

----------

