V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
eknauff schrieb: Hi, das kann aber auch daran liegen, dass die Wikis, bei aller Hochachtung vor ihren Erschaffern, gelegentlich etwas ungenau sind.
Einfache Antwort: It's a wiki! Jeder kann helfen, sie zu verbessern. Auf den Diskussionsthread zum Trim-Artikel hatte ich ja schon hingewiesen. 😉
Ich jedenfalls habe erst in diesem SSD-Wiki von einem "Online-Discard" gelesen und davon, dass es zwei Discard-Optionen gibt.
Das weist weniger auf Ungenauigkeit hin, sondern dass Du Dich vorher anscheinend noch nicht viel mit Trimmen und Discard beschäftigt hast.
Die Aussage jedenfalls, dass etwas sein "kann", wie man lesen könne, ist mir zu ungenau ebenso wie die Feststellung "mussten früher einige...!". Was ist "früher" und was dann "heute".
Erfahrungswerte der jeweiligen Autoren. Wie würdest Du es denn formulieren, wenn etwas eben nicht immer, aber auch nicht nie auftritt?
Möglicherweise ist manchmal etwas weniger (oder simpler) eben mehr. Naja, wir Deutschen mögen ja den Schilderwald.
Und Verallgemeinerungen. 😉
Nichts für ungut, ich mach jetzt das Licht aus und freue mich auf den Flieger morgen früh und zehn Tage türkische Riviera, ganz ohne unverständliche Wiki's.
Schönen Urlaub! 👍
|
eknauff
Anmeldungsdatum: 16. Februar 2011
Beiträge: 63
|
@ V for Vortex; Du hast, ich habe...
So kommt man doch nicht weiter!
Das Wiki habe ich entsprechend meiner Meinung und Sprachgefühl korrigiert.
Morgen meinte morgen, am 12ten um 05:50 ab DUS.
Trotzdem Danke...
Gidday
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Meines Erachtens ist Deine Änderung kontraproduktiv, weil sie noch viel mehr Ungenauigkeit (nebst von Dir zuvor kritisiertem „kann“) in den Kasten bringt und ihn unnötig verlängert. Du solltest vor solchen Änderungen diese im bereits zweimal erwähnten Diskussionsthread vorher vorschlagen, siehe auch das Wiki-FAQ zur Bearbeitung von Artikeln. Es soll und kann jeder mithelfen, aber bitte nach den Wiki-Richtlinien, um Chaos und „Edit-Wars“ zu vermeiden. Ich habe die nicht zum Ursprungsthread TRIM funktioniert nicht? gehörende Wiki-Diskussion zu diesem Zweck an den Artikel-Diskussionsthread angehängt und bitte alle hier um Sichtung der Änderung.
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
Ich kann den Sinn einer penetranten Wiederholung von "Online Discard gleich discard" nicht nachvollziehen, sprachlich ist das katastrophal. Ein einleitender Satz direkt zu Beginn des Abschnitts (außerhalb der Warnbox) "Online Discard wird durch die Option discard in /etc/fstab aktiviert" würde völlig ausreichen. Es gibt im gesamten Artikel nur eine Verwendung dieser Option. Die Logik der Argumentation in der Warnbox würde ich auch ändern. Sinngemäß:
Online Discard ist risikobehaftet, daher Vorsicht beim Einsatz Sich vorher schlau machen über die SSD System auf Auffälligkeiten prüfen nach Aktivierung Im Zweifel (und falls keine Kenntnisse) lieber Batched Discard
Generell von Online Discard abzuraten, halte ich nicht für ausreichend belegt (hat jetzt nichts mit eknauff's Änderung zu tun). Wenn es tatsächlich so riskant wäre, dass man es gar nicht verwenden soll, dann müßte es doch eher raus aus dem Artikel?! Die Warnbox ist auch in Teilen redundant zur Hinweisbox in der Einleitung. Gehört auch begradigt. Für den Cronjob würde ich noch ein einfaches Beispiel einbauen.
|
currock
Anmeldungsdatum: 26. Mai 2006
Beiträge: Zähle...
Wohnort: Hostenbach
|
linrunner schrieb:
Dazu die Frage: Wie machen andere Betriebssysteme das denn?
Naja, da gibt es alle Meinungen, und das für jeden SSD-Typ.
Bei mir ist die einzige Auffälligkeit, daß das Booten ca. 3 mal schneller geht und Programmstarts enorm beschleunigt werden. (discard in der fstab als mount-option angegeben, also online-Discard). Negative Auswirkungen bisher: keine.
So ein Batched Discard bremst doch während seiner Laufzeit das System heftig ab, oder?
Generell von Online Discard abzuraten, halte ich nicht für ausreichend belegt (hat jetzt nichts mit eknauff's Änderung zu tun). Wenn es tatsächlich so riskant wäre, dass man es gar nicht verwenden soll, dann müßte es doch eher raus aus dem Artikel?!
Ja, sehe ich auch so. Hier noch einmal die Frage, ob andere Betriebssysteme auch eine Art online-Discard nutzen. Gibt es da irgendwelche Infos?
Was empfehlen die SSD-Hersteller?
|
mrkramps
Anmeldungsdatum: 10. Oktober 2006
Beiträge: 5523
Wohnort: south central EL
|
currock schrieb: So ein Batched Discard bremst doch während seiner Laufzeit das System heftig ab, oder?
Wie im Artikel schon festgehalten, kann man dazu keine allgemeingültige Aussage machen. Mich selber als Fallbeispiel genommen, brauche ich fast länger zum Tippen der notwendigen Befehle samt Passworteingabe als das Batched Discard zum Durchlaufen. Das mag sich mit der Einsatzdauer und Auslastung meiner SSD aber irgendwann, irgendwie ändern. Solange Online Discard als völlig automatisierte Lösung für TRIM noch nicht sorglos zu genießen ist, stellt Batched Discard wohl die sicherste Variante dar zum gewünschten Ergebnis zu kommen und entsprechend werden sich die meisten Anwender auch daran orientieren. Der Artikel sollte also auch für unerfahrene Anwender zumindest mögliche Lösungsansätze anbieten, die über das manuelle Ausführen eines Befehls hinaus gehen. Ich wage zu behaupten, dass viele davor zurück schrecken sich selber einen entsprechenden Eintrag für Cron/Anacron zu erarbeiten - weniger wegen des Aufwands, mehr weil sie unsicher sind. Ich meine, wie häufig sollte man das ausführen? Welche Auswirkungen hat zu häufiges Ausführen auf die SSD? Cron führt die Befehle immer nur zu einem festen Zeitpunkt aus, Anacron ist dafür im Akkubetrieb auf mobilen Geräten standardmäßig deaktiviert und wie kann man Statusmeldungen beim Ausführen mitloggen lassen oder als Benachrichtigung anzeigen lassen? Danke 😬 "Online Discard gleich discard"… Was muss man denn mehr wissen, als dass Online Discard durch einen Eintrag in der fstab aktiviert wird und Batched Discard durch einen Befehl ausgeführt wird? Keine Ahnung, was daran bislang undeutlich war, aber Online Discard ist alleine vom Begriff her ungleich Batched Discard.
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Huhu! Ich habe den Abschnitt Onlice Discard jetzt ein wenig begradigt und Hinzugefügtes entfernt, da redundant bzw überflüssig. linrunner schrieb: Generell von Online Discard abzuraten, halte ich nicht für ausreichend belegt. Wenn es tatsächlich so riskant wäre, dass man es gar nicht verwenden soll, dann müßte es doch eher raus aus dem Artikel?!
Da gebe ich Dir recht (siehe unten). Und das muss u. a. wegen Lucid drinbleiben, da Batched Discard erst ab 2.6.37 nutzbar ist. Aber auch die Experten sind sich noch uneinig 🇬🇧 : The only problem is that on-the-fly trim (also called "online discard") doesn't work that well. On some devices, it slows operation considerably; there's also been some claims that excessive trimming can, itself, shorten drive life. The fact that the SATA version of trim is a non-queued operation (so all other I/O must be stopped before a trim can be sent to the drive) is also extremely unhelpful.
SCSI maintainer James Bottomley schrieb 🇬🇧 : However, I think it's time to question whether we actually still want to allow online discard at all. Most of the benchmarks show it to be a net lose to almost everything (either SSD or Thinly Provisioned arrays), so it's become an "enable this to degrade performance" option with no upside.
Ich wage noch nicht zu beurteilen, ob OD irgendwann™ komplett deaktiviert 🇬🇧 wird: So the kernel developers will probably not trim online discard support at this time. No filesystem enables it by default, though, and that seems unlikely to change.
Liebe Grüße, Flo
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
Da gibts z.B. hier einen Thread http://comments.gmane.org/gmane.comp.file-systems.xfs.general/43699 in dem jemand belegt hat daß XFS für eine Operation 40205 discard-Befehle an das Laufwerk geschickt hat wogegen ext4 nur 123 discard-Befehle gebraucht hat. Da ist es dann kein Wunder daß es zu Performanzproblemen kommt, da die TRIM-Anweisungen vom Laufwerk ja synchron abgearbeitet werden und wenn das dann gleich zehntausende Anweisungen sind braucht selbst das schnellste Laufwerk eine Weile... Das Online Discard ist dann einfach vom Dateisystem vielleicht technisch korrekt aber performanztechnisch mehr als suboptimal implementiert...
|
eknauff
Anmeldungsdatum: 16. Februar 2011
Beiträge: 63
|
Hi. wieso sollte der "TRIM"-sprich "discard"-Befehl einen Performance-Einbruch generieren?
Bei einer SSD?
Das ist doch nur noch ein ja/nein-Befehl, anders als bei einer konventionellen HDD.
Oder nein?
Die Fragen nehmen kein Ende...
E.
|
eknauff
Anmeldungsdatum: 16. Februar 2011
Beiträge: 63
|
currock schrieb: linrunner schrieb:
Dazu die Frage: Wie machen andere Betriebssysteme das denn?
Naja, da gibt es alle Meinungen, und das für jeden SSD-Typ.
Bei mir ist die einzige Auffälligkeit, daß das Booten ca. 3 mal schneller geht und Programmstarts enorm beschleunigt werden. (discard in der fstab als mount-option angegeben, also online-Discard). Negative Auswirkungen bisher: keine.
So ein Batched Discard bremst doch während seiner Laufzeit das System heftig ab, oder?
Generell von Online Discard abzuraten, halte ich nicht für ausreichend belegt (hat jetzt nichts mit eknauff's Änderung zu tun). Wenn es tatsächlich so riskant wäre, dass man es gar nicht verwenden soll, dann müßte es doch eher raus aus dem Artikel?!
Ja, sehe ich auch so. Hier noch einmal die Frage, ob andere Betriebssysteme auch eine Art online-Discard nutzen. Gibt es da irgendwelche Infos?
Was empfehlen die SSD-Hersteller?
Win7 kann ja von Haus aus mit SSD's umgehen. Ausser ein paar Abschaltungen diverser "Dienste" ist nichts weiter zu machen.
Tiefere Einblicke erlaubt Redmond dem "Normaluser" bekannterweise nicht!
|
currock
Anmeldungsdatum: 26. Mai 2006
Beiträge: 33
Wohnort: Hostenbach
|
eknauff schrieb: Hi. wieso sollte der "TRIM"-sprich "discard"-Befehl einen Performance-Einbruch generieren?
Bei einer SSD?
Das ist doch nur noch ein ja/nein-Befehl, anders als bei einer konventionellen HDD.
Oder nein?
Der discard-Befehl mag kurz sein, aber er löst Aktionen im Laufwerk aus. Wenn das Laufwerk den Befehl bekommt, alle nicht benutzten Sektoren wieder als frei zu markieren, kann das schon bremsen, wenn der Befehl 500 mal in der Sekunde kommt. Idealerweise würde das OS ja den aktuellen Status im Speicher halten und an das Laufwerk schicken, wenn es gerade nichts zu tun hat. Danach nur noch die Änderungen, das müsste dann ja schneller gehen. Leider weiß ich nicht, ob das OS dem Laufwerk auch mitteilen kann, nur einzelne Sektoren oder Blöcke als frei zu markieren, oder ob nur alles auf einmal geht.
|
currock
Anmeldungsdatum: 26. Mai 2006
Beiträge: 33
Wohnort: Hostenbach
|
eknauff schrieb:
Win7 kann ja von Haus aus mit SSD's umgehen.
Die Frage ist ja nicht ob, sondern wie.
Tiefere Einblicke erlaubt Redmond dem "Normaluser" bekannterweise nicht!
Da erwarte ich auch nichts. Wie sieht es mit den SSD-Herstellern denn aus? Da muss es doch Dokumentation geben.
|
tlu
Anmeldungsdatum: 30. Mai 2006
Beiträge: 266
|
UbuntuFlo schrieb: Huhu! Bitte mal drüberschauen. Ich habe den Artikel komplett überarbeitet, thematisch passender sortiert und aktualisiert.
...
Zu dem Punkt noch eine Frage, da er für mich nicht ganz klar ist. In dem Artikel heißt es:
Aktuelle Ubuntuversionen binden Laufwerke von Haus aus mit der Mountoption relatime (Relative Access Time) ein, was die Arbeit der SSD deutlich erleichtert. Aus diesem Grund sollte man die Option in /etc/fstab auch so belassen.
Auch im Wiki-Artikel //wiki.ubuntuusers.de/Mount#Optionen: wird zu relatime gesagt:
Modifiziertes atime um die fsync Zugriffe zu reduzieren. Standard ab Ubuntu 8.04
Das kann ich in meiner fstab nicht feststellen. mount ergibt für mein Kubuntu 12.04: /dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda2 on /home type ext4 (rw)
/dev/sdb1 on /VM type ext4 (rw)
/dev/sdb2 on /media/Multimedia type ext4 (rw) Was heißt das nun? Sind die Angaben im Wiki falsch oder wird tatsächlich standardmäßig "intern" mit relatime gemountet, ohne dass diese Option explizit in der fstab angegeben werden muss?
|
linrunner
Anmeldungsdatum: 7. August 2007
Beiträge: 3271
|
Ist dein Kubuntu 12.04 frisch installiert?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Hiernach sollte relatime Standard seit Hardy Heron sein und hiernach seit März 2009, also spätestens ab Ubuntu 9.10, das Standardverhalten des Kernels selbst, welches eine Option in der fstab überflüssig gemacht haben sollte.
|