Umzug von Hardware-RAID auf Software-RAID

[Dalai]

Wie es der Zufall (und die Hardware) so will, sind wir bei uns in der Firma dabei, einen neuen Server anzuschaffen - nach aktueller Planung auch ein AMD Epyc . Aufgrund einiger Vorkommnisse in der Vergangenheit halten wir es für sinnvoll, von Hardware-RAID auf Software-RAID umzusteigen, jedenfalls auf der neuen Maschine.

Ist-Zustand:

• Hardware-RAID durch LSI-basierten Controller (8300 XLP), 2x 2 HDDs jeweils im RAID-1
• Ubuntu 14.04
• Grub Legacy
• Root-Partition ext3

Ziel-Zustand auf der neuen Maschine:

• Software-RAID, 2x 2 SSDs mit insgesamt 4x RAID-1 (root, repos, home und daten)
• Ubuntu 14.04 - ja, es ist uns bekannt und bewusst, dass dessen Support in einigen Monaten endet, aber für die Aufgabenstellung spielt das keine Rolle (und Systemupgrade oder Neuinstallation fällt aktuell aus)
• Grub2
• Root-Partition ext4

Mein bisher ausgetüfteltes Vorgehen sieht grob so aus:

1. Auf dem bestehenden System Pakete grub2 & mdadm installieren und einstellen, damit RAID zur Verfügung steht und davon gebootet werden kann.
2. Image des bestehenden Systems erstellen mit fsarchiver, von einem Live-System aus
3. Neue Maschine mit Live-System booten
   
   1. dort die nötigen Partitionen erstellen
   2. mit mdadm die RAIDs über die erstellten Partitionen erzeugen
   3. Image des alten Systems mit fsarchiver in das RAID als ext4 wiederherstellen
   4. update-grub, grub-install in alle am RAID beteiligten Platten, mdadm.conf erzeugen, update-initramfs -u
   5. Kleinigkeiten wie UUIDs in der fstab anpassen usw.

Diese Schritte habe ich schon erfolgreich in zwei VMs nachvollzogen. Alles funktioniert soweit.

Dennoch habe ich einige Fragen, die ich im Vorfeld klären möchte:

• Gehe ich recht in der Annahme, dass ein fsck auf /dev/md/root korrekt ist, wenn das ext4 dort liegt?
  
  
• Funktioniert TRIM sauber, wenn auf den SSDs ein oder mehrere RAID-1 liegen? Bisher habe ich gelesen, dass TRIM wohl ab Kernel 3.7 oder 3.8 durch das mdadm (RAID-1) durchgereicht wird.
  
  
• Auf welches Device oder Dateisystem muss man ein fstrim anwenden? Ist dort ebenfalls /dev/md/root richtig?
  
  
• Die Nummerierung von mdadm ist ... wie formuliere ich das möglichst höflich... dämlich. Geht das irgendwie so zu gestalten, dass die Devices DETERMINISTISCH nummeriert werden? Mal ist die Root-Partition /dev/md127, dann wieder /dev/md126 (/dev/md/root ist ja nur ein Symlink, der auf eines der beiden zeigt).
  
  Warum ist das wichtig? Die Ausgaben von mount und df zeigen /dev/md127 und /dev/md126. Das an sich ist schon unschön, weil man immer erst prüfen/überlegen muss, wofür die Nummer nun aktuell grade steht. Außerdem greift Munin auf diese Ausgaben zurück, sodass nach jedem Reboot die Devices vertauscht sein können, was zu Änderungen an den Graphen führt - sowas geht gar nicht! Am liebsten wäre mir, wenn die Ausgaben von mount und df so gestaltet werden könnten, dass dort /dev/md/root und /dev/md/repos als Device/Dateisystem zu sehen sind. Wo kann/muss ich da eingreifen? mdadm, udev oder woanders?
  
  
• Gibt es noch weitere Dinge zu beachten oder bestimmte Fallstricke?

Grüße
Dalai

[tspoon]

wenn deine rstelltes rais als md126 oder 127 etc erkannt wird hast du einen wichtigen schritt nach dem erstellen vergessen.

#benötigte programme installieren
apt-get install initramfs-tools mdadm

#partitionen und raid erstellen wie angedacht, wenn die gesamte Platte genutzt werden soll empfiehlt es sich ganz auf Partitionen zu verzichten.
mdadm --create /dev/mdX --level=1 --raid-devices=2 /dev/sdX /dev/sdY

#mdadm config schreiben
mdadm --detail --scan > /etc/mdadm/mdadm.conf

#tramfs updaten damit die raidpartionen auch nach einem reboot den namen behalten
update-initramfs -u

Was die Auswertung von Munin betrifft, dort müsstest du, wenn da andere Werte auftauchen sollen, die jeweiligen Module selbst editieren bzw schauen wie diese angelegt sind.

Auch wenn du von einem Raid booten willst oder bestimmte Ordner einfach vom raid gemoiuntet werden sollen muss dies in der fstab stehen. dort sollte immer die UUID des jeweiligen raids eingetragen sein und keine namen der devices. Helfen tut dir da das programm "blkid"

Ein Eintrag sieht dann wie folgt aus:

UUID=<BLKID> /ZIELVERZEICHNIS ext4 defaults 0 1

Ein Trim musst du eigentlich nicht von Hand auslösen, da sollte sich die SSDs selbst drum kümmern.
Filesystemchecks etc immer auf der /dev/mdX anwenden nie auf den einzelnen Platten des Raids.
mdadm macht jeden ersten Sonntag eines Monats einen ausführlichen raidcheck mit resync. also nicht wundern wenn da die load oder festplattenauslastung hochgeht.

[Dalai]

Danke für deine Antwort!

wenn deine rstelltes rais als md126 oder 127 etc erkannt wird hast du einen wichtigen schritt nach dem erstellen vergessen.

Nein, vergessen habe ich das nicht. Die mdadm.conf existiert und enthält die richtigen Angaben:

ARRAY /dev/md/root metadata=1.2 UUID=blah-blub

Wie aber Doug Ledford in diesem Red Hat Bugreport erläutert, ist das wohl ein gewolltes Verhalten, wenn die RAID Arrays mit Namen erzeugt wurden:

For version 1.2 superblocks, the preferred way to create arrays is by using a name instead of a number. For example, if the array is your home partition, then creating the array with the option --name=home will cause the array to be assembled with a random device number (which is what you are seeing now, when an array doesn't have an assigned number we start at 127 and count backwards), but there will be a symlink in /dev/md/ that points to whatever number was used to assemble the array. The symlink in /dev/md/ will be whatever is in the name field of the superblock. So in this example, you would have /dev/md/home that would point to /dev/md127 and the preferred method of use would be to access the device via the /dev/md/home entry.

Was die Auswertung von Munin betrifft, dort müsstest du, wenn da andere Werte auftauchen sollen, die jeweiligen Module selbst editieren bzw schauen wie diese angelegt sind.

Das hilft mir nicht bzw. das ist gar nicht der Punkt. Momentan stelle ich mir die folgende Frage: Warum kann ich RAID Arrays Namen verpassen, wenn die nicht verwendet werden in /proc/mdstat, df, mount, lsblk und nur Bestandteil sind von mdadmin --details /dev/md/root und blkid? Warum nur in der Hälfte aller Tools/Dateien die Namen benutzen und sonst bloß die Nummern? Es braucht also doch wieder eine Zuordnung zwischen Nummer und Name, und sei es nur die im Kopf .

Und hinzu kommt noch die nicht deterministische Vergabe der Nummern beim Booten, wenn mehrere RAID Arrays vorhanden sind, wie schon erwähnt. Munin ist also nicht das einzige, was hier Probleme bekommt, sondern auch der Nutzer. Momentan sehe ich nur die Möglichkeit, die RAID Arrays mit Namen zu erstellen, sie aber als /dev/md0, /dev/md1 usw. in der mdadm.conf einzubinden. Dann sind die Namen vorhanden und die Nummern fest. Bescheuert bleibt es dennoch .


Bezüglich der Devices statt Partitionen: Nachdem ich anfing zu lesen, wie (man mit) mdadm arbeitet, hab ich mich gefragt "Warum zum Teufel verwenden die alle Partitionen und nicht gleich das ganze Device für das RAID?", aber die Antwort ist einfach: Eine Ersatzplatte muss mindestens genauso groß sein wie die im RAID. Ist das nicht der Fall, klappt der Rebuild/Resync nicht. Daher werden wir auf Verwendung ganzer Devices verzichten und stattdessen einzelne Partitionen benutzen, die eine definierbare Größe haben. Ich hab ja schon die Zahl der RAID Arrays auf die nötigen reduziert; es waren ursprünglich 6, aber es stellte sich heraus, dass 4 ausreichen.

Ein Eintrag sieht dann wie folgt aus:

UUID=<BLKID> /ZIELVERZEICHNIS ext4 defaults 0 1

Ist alles bereits passiert und kein Problem, wie ich ja bereits schrieb. fsarchiver sorgt dafür, dass auch die UUID wiederhergestellt wird, daher muss in der fstab für das Root nichts geändert werden (nur Swap und Repos).

Ein Trim musst du eigentlich nicht von Hand auslösen, da sollte sich die SSDs selbst drum kümmern.

Eine SSD macht niemals selbst ein TRIM! Sie braucht dafür die Hilfe des OS, das ihr sagt, welche Blöcke frei sind (und basierend darauf macht die SSD ihre Garbage Collection).

Filesystemchecks etc immer auf der /dev/mdX anwenden nie auf den einzelnen Platten des Raids.

OK, also lag ich schon richtig.

mdadm macht jeden ersten Sonntag eines Monats einen ausführlichen raidcheck mit resync. also nicht wundern wenn da die load oder festplattenauslastung hochgeht.

Ah, danke für den Hinweis. Mal sehen, wie sich das auswirkt und ob das so bleibt.

Grüße
Dalai

[tspoon]

achso du hast deine raids namen geben und keine nummer zB /dev/md0.
das ist natürlich etwas ungewöhnlich und macht man eigentlich nicht, dafür gibt es LABEL für die Platten oder Partitonen.
mount beherrscht auch dies. https://wiki.ubuntuusers.de/Labels/

dennoch sollte "update-initramfs -u" dafür sorgen, das linux die raidpartitions-namen Bsp: /dev/md0 nicht vergisst nach einem reboot.
was in der mdadm.cnf steht ist fast egal da mdadm ein scan beim start macht und versucht alle raids die es erkennt zustarten.
raids die es nicht eindeutig kennt, werden dann mit nummern ab /dev/md126 versehen.

mit den "trim per hand" mein ich das dies zum beispiel ubuntu von sich aus macht. es sollte sich also kümmern wenn eine ssd im system erkannt wird.

Automatisches TRIM ab Ubuntu 14.04 LTS

Mit Ubuntu 14.04 wurde ein wöchentlicher automatischer TRIM bei einigen SSD eingeführt. Dazu wird die Datei fstrim im Verzeichnis /etc/cron.weekly erstellt, die wiederum das Skript fstrim-all ausführt. Dieses durchläuft alle aktiven Dateisysteme auf der Suche nach einer SSD. Stellt es fest, dass sich ein oder mehrere Dateisysteme auf einer SSD befinden, wird fstrim automatisch gestartet.

Automatisches TRIM ab Ubuntu 14.10


Mit Ubuntu 14.10 wird ein wöchentliches, automatisches TRIM ausgeführt. Dazu gibt es das Skript fstrim im Verzeichnis /etc/cron.weekly, das wiederum /sbin/fstrim startet. Man kann dieses Skript, wie unter TRIM_per_Batched_Discard TRIM per Batched Discard beschrieben, ändern, so dass man die dort beschriebene Log-Datei erhält:

[Dalai]

achso du hast deine raids namen geben und keine nummer zB /dev/md0.

Die Namen der Arrays sind von den Nummern unabhängig. Naja, nicht ganz, denn wenn man einen "Namen" wie "1" vergibt, wird das Array automatisch als /dev/md1 erscheinen.

das ist natürlich etwas ungewöhnlich und macht man eigentlich nicht, dafür gibt es LABEL für die Platten oder Partitonen.

Die Ausreizung der vorhandenen Möglichkeiten ist nicht ungewöhnlich, finde ich. Ich fand es (am Anfang) eine klasse Sache, einfach /dev/md/root benutzen zu können statt überlegen zu müssen, ob das Root-Array nun wirklich /dev/md0 ist. Zudem ist es schon nett, wenn man in der Ausgabe von blkid anhand der Labels sieht, zu welchem Homehost und Array ein bestimmtes Device gehört. Nur rechnete ich nicht damit, dass benannte Arrays andere, nicht-deterministische Nummern bekommen und der Name /dev/md/root fast nirgendwo erscheint.

Labels der Dateisysteme sind eine andere Baustelle. Natürlich haben die Dateisysteme selbst eine Bezeichnung, aber die hat erstmal keine Beziehung zum RAID Array. Die Benennung der Arrays hilft auch sehr dabei, in einem Live-System die einzelnen Teile der Arrays zu finden, unabhängig davon, ob und welche Dateisysteme darin enthalten sind.

mount beherrscht auch dies. https://wiki.ubuntuusers.de/Labels/

Darum geht's nicht. Die Dateisysteme werden anhand der UUIDs gemountet. Ich wollte erreichen, dass in der Ausgabe z.B. des Befehls mount schon anhand des Device-Namens wie z.B. /dev/md/root die RAID Arrays erkennbar sind. Also ohne erst nachschauen zu müssen, in welchen Mountpunkt das Device eingehängt ist. Und eben auch für Munin, das auf feste Device-Namen angewiesen ist.

dennoch sollte "update-initramfs -u" dafür sorgen, das linux die raidpartitions-namen Bsp: /dev/md0 nicht vergisst nach einem reboot.

Vergessen wird da nichts! Gibt man in der mdadm.conf als Device-Pfad /dev/md0 an, bekommt das Array immer diesen Pfad, völlig egal, ob das ein benanntes Array ist oder nicht. Hat das Array einen Namen und man gibt stattdessen einen Device-Pfad wie /dev/md/root an, bekommt das Array immer eine Nummer /dev/md127 oder kleiner (und den Symlink /dev/md/root, der auf /dev/md127 zeigt). Leider bleibt die Nummer aber nur dann gleich, wenn man ein einziges Array hat; bei mehreren Arrays werden sich die Nummern hin und wieder beim Reboot ändern.

was in der mdadm.cnf steht ist fast egal da mdadm ein scan beim start macht und versucht alle raids die es erkennt zustarten.

Das stimmt zum Großteil. mdadm versucht, sinnvolle Device-Namen zu vergeben, anhand der Namen und Nummern der Arrays, wie auch in der Manpage steht. Die mdadm.conf erlaubt aber weitergehende Konfiguration und die Automatik zu überstimmen (leider nicht so, wie ich das gern hätte).

raids die es nicht eindeutig kennt, werden dann mit nummern ab /dev/md126 versehen.

Stimmt auch, ist aber nur die Hälfte der Wahrheit. Teste es doch mal, indem du einem Array einen Namen verpasst und es mit einem Pfad wie /dev/md/irgenwas in der mdadm.conf einträgst. Du wirst sehen, dass auf einmal /dev/md127 daraus wird.

mit den "trim per hand" mein ich das dies zum beispiel ubuntu von sich aus macht. es sollte sich also kümmern wenn eine ssd im system erkannt wird.

Ja, ich kenne das fstrim-all im Cron. Ich mag diesen Automatismus aber nicht.

Grüße
Dalai

[Berniyh]

[*]Image des bestehenden Systems erstellen mit fsarchiver, von einem Live-System aus[*]Neue Maschine mit Live-System booten
[LIST=1][*]dort die nötigen Partitionen erstellen[*]mit mdadm die RAIDs über die erstellten Partitionen erzeugen[*]Image des alten Systems mit fsarchiver in das RAID als ext4 wiederherstellen

Im Grunde hättest du hier statt fsarchiver auch einfach rsync nehmen können, genauer gesagt rsync -av.
Wenn du dein root als bind irgendwo mountest, dann kannst du das sogar aus dem laufenden System heraus machen, also z.B.

mount / /mnt/oldroot -o bind
rsync -av --exclude=lost+found /mnt/oldroot/ /mnt/newroot

(Achtung, der / nach oldroot ist wichtig.)

[*]update-grub, grub-install in alle am RAID beteiligten Platten, mdadm.conf erzeugen, update-initramfs -u

Hier musst du sicherstellen, dass die Treiber für den software raid auch in der initrd drin sind. Leider kann ich dir da bei Ubuntu nichts dazu sagen, wie man das macht.
Wenn sie dracut nutzen, dann vermutlich über /etc/dracut.conf oder /etc/dracut.conf.d oder evtl. auch /etc/default/

[*]Gehe ich recht in der Annahme, dass ein fsck auf /dev/md/root korrekt ist, wenn das ext4 dort liegt?

Ja, das Dateisystem liegt auf einem md device. Wenn /dev/md/root das md device ist, welches du definiert hast, ist das der Pfad zu deinem ext4.

[*]Funktioniert TRIM sauber, wenn auf den SSDs ein oder mehrere RAID-1 liegen? Bisher habe ich gelesen, dass TRIM wohl ab Kernel 3.7 oder 3.8 durch das mdadm (RAID-1) durchgereicht wird.

Sollte passen.

[*]Auf welches Device oder Dateisystem muss man ein fstrim anwenden? Ist dort ebenfalls /dev/md/root richtig?

Eigentlich ist das nichts, was du selbst machen solltest, vielmehr ist das Aufgabe des Dateisystems und kann über die Mountoptionen eingestellt werden. Für ext4 (siehe man 5 ext4):

       discard/nodiscard
              Controls whether ext4 should issue discard/TRIM commands to the underlying block device when blocks are freed.  This is useful for SSD devices and sparse/thinly-provisioned LUNs, but it is off by default until sufficient  testing
              has been done.

[*]Die Nummerierung von mdadm ist ... wie formuliere ich das möglichst höflich... dämlich. Geht das irgendwie so zu gestalten, dass die Devices DETERMINISTISCH nummeriert werden? Mal ist die Root-Partition /dev/md127, dann wieder /dev/md126 (/dev/md/root ist ja nur ein Symlink, der auf eines der beiden zeigt).

Wenn du fixe Nummern haben willst musst du das in der mdadm.conf eintragen. So hängt es halt davon ab welches von mdadm zuerst geladen wird.
Aber ja, ein bisschen unschön ist das schon, war auch einer der Gründe, weshalb ich von mdadm auf btrfs gewechselt bin (aber bei weitem nicht der wichtigste).

[*]Gibt es noch weitere Dinge zu beachten oder bestimmte Fallstricke?

Eigentlich nicht, wobei eben bei Distributionskerneln gerne die initrd ein Problem ist, weil irgendwelche Treiber nicht geladen sind.
Zudem unbedingt bei grub die geladenen Module überprüfen sowie die ids, die in der cmdline stehen.

[Dalai]

Im Grunde hättest du hier statt fsarchiver auch einfach rsync nehmen können, genauer gesagt rsync -av.
Wenn du dein root als bind irgendwo mountest, dann kannst du das sogar aus dem laufenden System heraus machen, also z.B.

mount / /mnt/oldroot -o bind
rsync -av --exclude=lost+found /mnt/oldroot/ /mnt/newroot

(Achtung, der / nach oldroot ist wichtig.)

Theoretisch. Praktisch leider nicht so einfach möglich. Das vorhandene System nutzt wie schon gesagt einen 8300 XLP, was ein PCI-X Controller ist. Laut megacli unterstüzt der Controller keine SSDs. Situation ist also, dass der Controller nicht einfach in den neuen Server mitgenommen werden kann, da der kein PCI-X hat (Risiko mal außen vor gelassen) und die SSDs des neuen nicht einfach im alten System benutzt werden können.

Also muss das System irgendwie übers Netzwerk übertragen werden. Ja, rsyncd wäre noch ein Weg, aber auf die kurze Downtime für die Erzeugung des Image (30 Min oder sowas) kommt's auch nicht mehr an, zumal fsarchiver sowieso der bisher benutzte Weg zur Sicherung der Linux-Systeme ist.

Hier musst du sicherstellen, dass die Treiber für den software raid auch in der initrd drin sind. Leider kann ich dir da bei Ubuntu nichts dazu sagen, wie man das macht.
Wenn sie dracut nutzen, dann vermutlich über /etc/dracut.conf oder /etc/dracut.conf.d oder evtl. auch /etc/default/

Das funktioniert automatisch. Nachdem das Paket mdadm installiert wurde, steht das Modul zur Verfügung und kann mit in die initrd eingebaut werden (weiß jetzt nicht, ob die sogar automatisch neu gebaut wird).

Eigentlich ist das nichts, was du selbst machen solltest, vielmehr ist das Aufgabe des Dateisystems und kann über die Mountoptionen eingestellt werden.

Ja, ich kenne die Mount-Option discard. Da ich sie aber nicht benutzen möchte, weil sie mir zu unsicher ist (wie die Manpage und das UU Wiki sagen), und weil auf dem Server permanent viele sehr kleine Dateien geschrieben werden, wird das vermutlich zu einem Leistungseinbruch führen. Auf einem Desktop oder Laptop wäre es wohl egal. Auf dem existierenden NAS mit SSD (ist nicht der alte Server aus dem OP) habe ich damals in Ubuntu 12.04 das fstrim so in den Cron eingetragen, dass die Ausgabe davon in einem Log landet. Das möchte ich auf dem neuen Server auch haben. Deswegen meine Frage nach dem "Ziel" des fstrim.

Wenn du fixe Nummern haben willst musst du das in der mdadm.conf eintragen. So hängt es halt davon ab welches von mdadm zuerst geladen wird.

Jep, sieht wohl so aus, als wenn ich die als md0 bis md3 oder sowas festlegen muss, wenn die Arrays benannt sind.

Zudem unbedingt bei grub die geladenen Module überprüfen sowie die ids, die in der cmdline stehen.

Das passt soweit im Testsystem. Sonst hätte es auch nicht sauber gebootet .

Grüße
Dalai

[Berniyh]

Theoretisch. Praktisch leider nicht so einfach möglich. Das vorhandene System nutzt wie schon gesagt einen 8300 XLP, was ein PCI-X Controller ist. Laut megacli unterstüzt der Controller keine SSDs. Situation ist also, dass der Controller nicht einfach in den neuen Server mitgenommen werden kann, da der kein PCI-X hat (Risiko mal außen vor gelassen) und die SSDs des neuen nicht einfach im alten System benutzt werden können.

Ok, wenn du die SSD nicht anschließen kannst geht es natürlich nicht. Davon bin ich eigentlich erst mal ausgegangen. Aber ist auch egal.

Das funktioniert automatisch. Nachdem das Paket mdadm installiert wurde, steht das Modul zur Verfügung und kann mit in die initrd eingebaut werden (weiß jetzt nicht, ob die sogar automatisch neu gebaut wird).

Hängt von der Distribution ab. Ich habe nur dracut installiert und da passiert das nicht automatisch.
Wenn deine Distribution das alles so eingerichtet hat, dann ist das gut möglich, dass es automatisch und korrekt umgesetzt wurde, aber sicher kann man da nicht sein (es sei denn man hat es schon mal ausprobiert).
Ich erinnere mich auch an einen Fall, ich glaube da habe ich eine root Partition für Fedora ausgetauscht, da musste ich das auch manuell einstellen, weil er neue Treiber nicht automatisch eingebunden hat.

Ja, ich kenne die Mount-Option discard. Da ich sie aber nicht benutzen möchte, weil sie mir zu unsicher ist (wie die Manpage und das UU Wiki sagen), und weil auf dem Server permanent viele sehr kleine Dateien geschrieben werden, wird das vermutlich zu einem Leistungseinbruch führen. Auf einem Desktop oder Laptop wäre es wohl egal. Auf dem existierenden NAS mit SSD (ist nicht der alte Server aus dem OP) habe ich damals in Ubuntu 12.04 das fstrim so in den Cron eingetragen, dass die Ausgabe davon in einem Log landet. Das möchte ich auf dem neuen Server auch haben. Deswegen meine Frage nach dem "Ziel" des fstrim.

hm, da sehe ich jetzt den Vorteil nicht. Wenn dir discard zu unsicher ist, dann darfst du eigentlich gar kein trim verwenden, auch nicht per cron job.
Oder geht es dur nur um Fehleranfälligkeit?
gut, da kann ich zu ext4 nichts sagen, aber mit btrfs nutze ich discard inzwischen seit 6 oder 7 Jahren ohne Probleme und ext4 ist ja eigentlich deutlich älter als btrfs.
Generell bin ich mit ext4 nie wirklich grün geworden. Zu oft hatte ich Datenverlust auf den Datenträgern auf denen ich es eingesetzt habe (meist externe Festplatten).

[Dalai]

[...] aber sicher kann man da nicht sein (es sei denn man hat es schon mal ausprobiert).

Deswegen mach ich bei solchen großen Dingen, mit denen ich bisher nichts zu tun hatte, vorher Tests, um mich einerseits damit vertraut zu machen und andererseits eine Anleitung für mich zusammenzuschreiben, die ich dann am Produktivsystem benutzen kann.

hm, da sehe ich jetzt den Vorteil nicht. Wenn dir discard zu unsicher ist, dann darfst du eigentlich gar kein trim verwenden, auch nicht per cron job.

Der Vorteil ist, dass es einerseits ein Protokoll dessen gibt, was fstrim gemacht hat und andererseits nicht permanent TRIM-Befehle abgesetzt werden für jede noch so kleine gelöschte Datei. Ja, ich weiß, dass Windows das so macht, aber ich denke mir einfach, dass es einen Grund hat, warum unter Linux discard standardmäßig nicht zum Mounten benutzt wird.

Ich bin in vielerlei Hinsicht konservativ, jedenfalls was Software, Hardware, Dateisysteme und das Zusammenspiel von Hard- & Software angeht. Denn wenn es Probleme gibt, will ich etwas zu dem Problem finden können und nicht einer der ersten sein, der damit konfrontiert ist und schnell eine Lösung finden muss (die fast nie schnell umgesetzt werden kann).

Grüße
Dalai

[Berniyh]

aber ich denke mir einfach, dass es einen Grund hat, warum unter Linux discard standardmäßig nicht zum Mounten benutzt wird.

Wenn der trim Befehl genutzt wird, dann kann ein Verschlüsselungslayer in der Ebene über dem Dateisystem kompromittiert werden. Ein entsprechender Proof-of-Concept existiert.
Aus dem Schema, welches durch das Trimmen auf der Festplatte entsteht können mindestens Rückschlüsse auf das verwendete Dateisystem, ggf. aber auch mehr geschlossen werden.
Es besteht also ggf. ein Sicherheitsrisiko, weshalb meines Wissens der trim Befehl nur eingeschränkt empfohlen wird.

Dazu kommt, dass es Performanceprobleme geben kann, wenn eben – wie von dir befürchtet – der trim Befehl immer sofort ausgeführt wird.
Allerdings würde es mich wurdern, wenn die SSDs das einfach so ausführen würden. Wahrscheinlicher ist, dass die trim Befehle gesammelt und dann irgendwann in einem ausgeführt werden. d.h. nicht so anders als mit fstrim.
Insbesondere vor dem Hintergrund, dass Windows ja scheinbar auch trim Befehle schickt und viele SSDs mit Windows betrieben werden.