| View previous topic :: View next topic |
| Author |
Message |
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
 Posted: Mon Nov 25, 2013 6:40 am Post subject: SSD Systemlaufwerk mit LUKS, LVM und EXT4 + TRIM |
 |
|
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 | Code: | 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 |
...
| Code: | 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.
...
| Code: | emerge -av lvm2 cryptsetup genkernel
genkernel --lvm --luks --install initramfs |
...
/etc/fstab | Code: | /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 | Code: | 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 |
|
| Back to top |
|
 |
Fijoldar
Apprentice
Joined: 10 Apr 2013
Posts: 248
|
| Posted: Mon Nov 25, 2013 8:26 am Post subject: |
|
|
Hallo,
für die Trim Funktion reicht es, in der fstab die discard Funktion zu aktivieren: Bei mir sieht es so aus
| Code: | | /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
| Code: | devices {
[...]
issue_discards = 1
} |
LUKS
Datei /etc/default/grub
| Code: | | 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. |
|
| Back to top |
|
|
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
| Posted: Mon Nov 25, 2013 8:40 am Post subject: |
|
|
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  |
|
| Back to top |
|
|
Fijoldar
Apprentice
Joined: 10 Apr 2013
Posts: 248
|
| Posted: Mon Nov 25, 2013 8:52 am Post subject: |
|
|
| Quote: | | This page was last modified on 30 September 2013, at 18:13 |
Die Anleitung sollte also noch stimmen
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
| Code: | | fdisk -l -u /dev/sda |
Entscheidend ist dann der Wert Anfangssektor, welcher durch 2048 teilbar sein solle. Die Ausgabe sollte also so etwas liefern:
| Code: |
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
|
|
|
| Back to top |
|
|
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
| Posted: Mon Nov 25, 2013 9:41 am Post subject: |
|
|
OK, da hätte ich mal bis ganz unten, und nicht nur bis dreiviertel lessen sollen
Ob ich nun "fdisk -lu /dev/sda" oder "fdisk -l /dev/sda" mache, die Ausgabe ist bei mir immer die gleiche.
| Code: | 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? |
|
| Back to top |
|
|
Fijoldar
Apprentice
Joined: 10 Apr 2013
Posts: 248
|
| Posted: Mon Nov 25, 2013 9:55 am Post subject: |
|
|
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) |
|
| Back to top |
|
|
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
| Posted: Wed Nov 27, 2013 8:20 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
Fijoldar
Apprentice
Joined: 10 Apr 2013
Posts: 248
|
| Posted: Wed Nov 27, 2013 9:54 pm Post subject: |
|
|
Das geht z.B. mit
| Code: | | 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. |
|
| Back to top |
|
|
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
| Posted: Wed Nov 27, 2013 10:36 pm Post subject: |
|
|
| Code: | tune2fs -l /dev/sda1 | grep "Block size"
Block size: 4096 |
OK, das sieht dann wohl gut so aus ....
....
grub.conf
| Code: | 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
| Code: | devices {
[...]
issue_discards = 1
} |
/etc/fstab
| Code: | | /dev/mapper/vg01-root / ext4 noatime,discard 0 1 |
/etc/conf.d/local
| Code: | | 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
| Code: | | 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:
| Code: | 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 |
|
| Back to top |
|
|
Fijoldar
Apprentice
Joined: 10 Apr 2013
Posts: 248
|
| Posted: Wed Nov 27, 2013 10:49 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Thu Nov 28, 2013 1:05 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
| Posted: Thu Nov 28, 2013 9:59 pm Post subject: |
|
|
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? |
|
| Back to top |
|
|
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
| Posted: Fri Nov 29, 2013 7:12 pm Post subject: |
|
|
fstrim -v / | Code: | | /: 231580737536 bytes were trimmed |
Das sind über 200gb?!? Ist sowas normal? |
|
| Back to top |
|
|
Fijoldar
Apprentice
Joined: 10 Apr 2013
Posts: 248
|
| Posted: Sat Nov 30, 2013 10:30 am Post subject: |
|
|
| 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 . |
|
| Back to top |
|
|
SarahS93
l33t
Joined: 21 Nov 2013
Posts: 730
|
| Posted: Sat Nov 30, 2013 11:40 am Post subject: |
|
|
| Wenn ein fstrim -v / was trimmt, heisst es doch das die discard option nicht richtig greif? |
|
| Back to top |
|
|
Fijoldar
Apprentice
Joined: 10 Apr 2013
Posts: 248
|
| Posted: Sat Nov 30, 2013 12:25 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Sat Nov 30, 2013 2:34 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
tazinblack
Veteran
Joined: 23 Jan 2005
Posts: 1146
Location: Baden / Germany
|
| Posted: Sun Dec 01, 2013 8:23 pm Post subject: |
|
|
| 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.
_________________
Gruß / Regards
tazinblack
_______________________________________________________
what's the point in being grown up if you can't be childish sometimes |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Mon Dec 02, 2013 2:28 pm Post subject: |
|
|
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... |
|
| Back to top |
|
|
|
Deutsches Forum (German)
