UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Jo, war auch so besprochen, dass alle zum gleichen Zeitpunkt die Baustelle verlassen. Das hat ramnit auch so abgenickt. UbuntuFlo schrieb: Zwischenfrage: Wenn der nun aus der Baustelle rauskommt und die anderen SSD-Artikel drin bleiben, fände ich es besser, wenn die schon fertigen noch nicht in den neuen Artikeln benannt würden. Vor allem, weil noch viele Deadlinks auftauchen. Dann lieber gesammelt überstellen, wenn auch der letzte ready ist? Oder ist das Vorgehen suboptimal?
Liebe Grüße, Flo
|
ramnit
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2009
Beiträge: 922
Wohnort: /dev/tty7
|
Genau das war der Plan. Deswegen ja auch die Sandkastentabelle, aber wir entwickeln uns schon wieder vom Thema weg. 😉
|
ramnit
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2009
Beiträge: 922
Wohnort: /dev/tty7
|
Der Artikel ist durchkontrolliert und wird voraussichtlich in den nächsten Tagen ins Wiki verschoben, wenn bis dahin keine Nachforderungen mehr kommen.
|
ramnit
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2009
Beiträge: 922
Wohnort: /dev/tty7
|
Der Artikel ist im Wiki. Mein Dank an alle Beteiligten für die konstruktive Zusammenarbeit. ☺ Liebe Grüße martin
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Für die Intel 320-serises SSD's gibt's ein Firmware-Update (wird allemein empfohlen). Ich habe das Posting dazu versehentlich unter der "Sammelbeitrag-Diskussion" geschrieben, Details siehe hier. Viele Grüße, Ingo
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Huhu! Ändert sich was am Vorgehen, um das Update zu installieren? Wenn ja, dann bitte in de Artikel. Liebe Grüße, Flo
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
UbuntuFlo schrieb:
Ändert sich was am Vorgehen, um das Update zu installieren?
No, ein ca 4MB großes ISO downloaden, ... alles wie gehabt. Sonst hätte ich das schon upgedatet 😉 Viele Grüße, Ingo P.S.: Ist schon erstaunlich, wenn man bedenkt, daß Intel hier sogar DOS-Treiber (für Dr-DOS) für alle gängigen SATA-Controller programmiert hat!
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
Hey. Im Wiki steht bei kopieren mit dd SSD/Grundlagen (Abschnitt „Inbetriebnahme“): Auch das für die Geschwindigkeit der SSD so wichtige Alignment wird damit ad absurdum geführt.
Was hat das Alignment mit dd zu tun? Das wird ja dadurch nicht verändert. Allgemein finde ich auch, dass in den SSD-Artikeln eine richtige Angstmache vor Schreibvorgängen gefahren wird. z.B.
Man füllt also auch unbenutzte und leere Sektoren/Blöcke mit Nullen, so dass keine für die SSD essenzielle Spare-Area mehr frei bleibt
Die Spare-Area kann man garnicht beschreiben, sie bleibt also immer frei. Und: Des Weiteren wird die Anzahl der (endlichen) Schreibvorgänge massiv „verbraucht“
Von einmal Vollschreiben der SSD werden ein paar Schreibzyklen verbraucht, klar. Aber unter "massiv" verstehe ich: 10 Mal gemacht und die SSD ist futsch. Ich würde sowas eher so formulieren: "Dies erzeugt viele unnötige Schreibvorgänge." Genauso in SSD/Auslagerung, wo mal eben verschwiegen wird, dass die meisten Schreibvorgänge sowieso im write-cache passieren. Und der Nachteil von beschränkter /tmp Größe wird auch verschwiegen (Programme die mehr Platz brauchen stürzen ab oder geben Fehlermeldung). Zumal bei ein paar Logdateien die Schreibbelastung auch nicht so riesig ist. Aber gut, das gehört dann wohl auch in die Diskussion des anderen Artikels.
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
stfischr schrieb: Hey. Im Wiki steht bei kopieren mit dd SSD/Grundlagen (Abschnitt „Inbetriebnahme“): Auch das für die Geschwindigkeit der SSD so wichtige Alignment wird damit ad absurdum geführt.
Was hat das Alignment mit dd zu tun? Das wird ja dadurch nicht verändert.
Genau darum geht es. Vollständig wäre:
man checke das Alignment der Quell-HD. falls das schon MiB-aligned ist, entstehen natürlich keine Nachteile bezüglich Alignment. Dennoch verursacht das Kopieren mit dd unnötige Schreibvorgänge, da auch leere bzw. unbenutzte Blöcke kopiert/geschrieben werden. falls die Quell-HD nicht MiB-aligned ist, sollte das Kopieren nicht mit dd durchgeführt werden, da es zu erheblichen Geschwindigkeits-Einbußen der SSD führen kann.
Allgemein finde ich auch, dass in den SSD-Artikeln eine richtige Angstmache vor Schreibvorgängen gefahren wird. z.B.
Im Gegenteil: es werden sogar Beispiele genannt, daß z.B. nach 1 Jahr normalen Gebrauchs nur 1% des "media wearout" verbraucht sind. Ebenso werden die 5 Jahre Garantie bei neueren Intesl SSD's zitiert.
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
ingo2 schrieb: Genau darum geht es. Vollständig wäre:
Wie wäre es mit: Auch das für die Geschwindigkeit der SSD so wichtige Alignment ist so vom Quell-Laufwerk abhängig und damit eventuell fehlerhaft.
Allgemein finde ich auch, dass in den SSD-Artikeln eine richtige Angstmache vor Schreibvorgängen gefahren wird. z.B.
Im Gegenteil: es werden sogar Beispiele genannt, daß z.B. nach 1 Jahr normalen Gebrauchs nur 1% des "media wearout" verbraucht sind. Ebenso werden die 5 Jahre Garantie bei neueren Intesl SSD's zitiert.
Dann widerspricht sich der Artikel aber, siehe meine Zitate "massiv" und die Fehlinformation zur Spare-area
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
stfischr schrieb: ingo2 schrieb: Genau darum geht es. Vollständig wäre:
Wie wäre es mit: Auch das für die Geschwindigkeit der SSD so wichtige Alignment ist so vom Quell-Laufwerk abhängig und damit eventuell fehlerhaft.
Warum in aller Welt liegt dir dd so am Herzen? Es gibt unter Linux mehrere Möglichkeiten, den Kopiervorgang sauber und ohne Nachteile zu bewerkstelligen:
Und wenn jemand ausschließlich dd kennt, ist das auch kein Beinbruch - die SSD geht davon ja nicht kaputt und ohne Alignment tut sie auch. Nur, wenn man schon viel Geld für so ein Stück ausgibt, warum dann nicht ein paar Dinge beachten, um auch das Optimum herauszuholen? Allgemein finde ich auch, dass in den SSD-Artikeln eine richtige Angstmache vor Schreibvorgängen gefahren wird. z.B.
Im Gegenteil: es werden sogar Beispiele genannt, daß z.B. nach 1 Jahr normalen Gebrauchs nur 1% des "media wearout" verbraucht sind. Ebenso werden die 5 Jahre Garantie bei neueren Intesl SSD's zitiert.
Dann widerspricht sich der Artikel aber, siehe meine Zitate "massiv" und die Fehlinformation zur Spare-area
Im Artikel "Grundlagen" gibt's einen ganzen Abschitt, der von Märchen und Wahrheiten zum Thema Haltbarkeit handelt. Und dort ist mE alles korrekt und belegt dargestellt! Und sinnvoll ist eine komplette Neupartitionierung eine SSD allemal:
man schreibt ein neues, ggf. anderes Dateisystem (ext4, btrfs) und kopiert die Daten unfragmentiert darauf (nicht mit dd 😉 man läßt einen Teil der SSD unpartitioniert, dann benutzt den die Firmware als "erweiterte" spare area für wear levelling und Müllabfuhr (Deutsch: garbage collection). Kann man natürlich auch vor der Partitionierung mit hdparm permanent machen. Wie diese spare area detailliert genutzt wird, ist und bleibt ein gehütetes Geheimnis der SSD- bzw. Firmware-Hersteller
Ich persönlich finde, daß alles sachlich und korrekt und vollständig dargestellt ist. Beste Grüße, Ingo
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
ingo2 schrieb: Warum in aller Welt liegt dir dd so am Herzen? Es gibt unter Linux mehrere Möglichkeiten, den Kopiervorgang sauber und ohne Nachteile zu bewerkstelligen:
Mir liegt eigentlich am Herzen, das das Wiki keine Halbwahrheiten verbreitet. Ich würde auch in jedem Fall von dd abraten. Schon alleine weil es ewig dauert. Und wenn jemand ausschließlich dd kennt, ist das auch kein Beinbruch - die SSD geht davon ja nicht kaputt und ohne Alignment tut sie auch.
Eben nur im Wiki hört sich das eher andersherum an.
Im Artikel "Grundlagen" gibt's einen ganzen Abschitt, der von Märchen und Wahrheiten zum Thema Haltbarkeit handelt. Und dort ist mE alles korrekt und belegt dargestellt!
Die Statements im Grundlagenartikel (Haltbarkeit, Wearleveling) finde ich auch völlig in Ordnung, nur sollte diese Meinung dann auch konsequent in den Folgeartikeln beibehalten werden. Und sinnvoll ist eine komplette Neupartitionierung eine SSD allemal:
Auf jeden Fall, das wird ja auch ausdrücklich im Wiki empfohlen und das finde ich auch richtig. Das ist z.B. wieder so eine Halbwahrheit. Es ist natürlich richtig, dass nicht genutzter Platz für das Wearleveling genutzt wird, aber zumindest bei aktuellen Platten werden auch bereits belegte Blöcke für das Wearleveling genutzt. Außerdem ist es nicht nötig einen Bereich unpartitioniert zu lassen, man kann genauso gut einfach dafür sorgen, dass das Dateisystem nie ganz voll läuft, den Rest machen Trim und der GC. Letzteres hat den Vorteil, dass man auch mal kurzzeitig mehr Daten auf die SSD schreiben kann und diese später wieder freigeben kann und das die Dateisystemgröße nicht so knapp bemessen ist was wiederum Fragmentierung vermindert.
Ich persönlich finde, daß alles sachlich und korrekt und vollständig dargestellt ist.
Ich finde halt, dass es bei der Vollständigkeit an einigen Details fehlt, die dem User etwas Gelassenheit und Komfort zurückgeben würden. PS: Ich weiß, dass du zusammen mit ramnit und UbuntuFlo die Artikel mit viel Zeitaufwand erstellt hast. Dafür habt ihr auch meine Anerkennung. Ich bin ja zu 99% mit ihnen zufrieden, es ist nur hier und da eine kleine Umformulierung, die dem User etwas Angst vor Schreibvorgängen nehmen würden. Ich habe auch extra nix einfach im Wiki geändert, sondern hier nachgefragt um euch nicht zu übergehen. Wenn ich euch nicht überzeugen kann, dann bleibt von mir aus alles wie es jetzt ist. Schaden wird man so sicherlich Niemandem. Aber mir wäre es lieber, wenn man auch die Details nicht verschweigt.
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
stfischr schrieb: ingo2 schrieb: Das ist z.B. wieder so eine Halbwahrheit. Es ist natürlich richtig, dass nicht genutzter Platz für das Wearleveling genutzt wird, aber zumindest bei aktuellen Platten werden auch bereits belegte Blöcke für das Wearleveling genutzt. Außerdem ist es nicht nötig einen Bereich unpartitioniert zu lassen, man kann genauso gut einfach dafür sorgen, dass das Dateisystem nie ganz voll läuft, den Rest machen Trim und der GC. Letzteres hat den Vorteil, dass man auch mal kurzzeitig mehr Daten auf die SSD schreiben kann und diese später wieder freigeben kann und das die Dateisystemgröße nicht so knapp bemessen ist was wiederum Fragmentierung vermindert.
Deiner Antwort ist genauso unvollständig: in der spare area hält die SSD normalerweise unbenutzte Blöcke vor, die als Ersatz dienen, wenn später mal "normale" Flashzellen totgeschrieben oder defekt sind. Ist genauso wie bei rotierenden HD's. Dazu ist die Bezeichnung "reallocated sectors" gebnräuchlich. Bei SSD's ist das alles Bestandteil des wear levelling. Nicht jeder der eine SSD hat, benutzt sie ausschließlich unter Linux mit ausschließlich ext4 oder btrfs - z.B. ich. WinXP auf NTFS und ext3 unterstützen kein trim, da erfährt die SSD vom Dateisystem nie, welche Blöcke jetzt noch frei sind oder frei geworden sind Die SSD nutzt intern auch garbage collection, kann aber so nur halb volle Blöcke zusammenfassen. Wie sie die Information dazu bekommt (vor allem ohne trim) ???
Natürlich können wir die Artikel noch erweitern und alle möglichen und unmöglichen Umstände berücksichtigen, dann werden die 3x so umfangreich und letzlich liest es niemand mehr durch, weil zu langatmig. Und, wer sich ein paar Gedanken im Vorfeld über SSD's gemacht hat, findet doch hier alles was er braucht (außer "Verschlüsselung", da kenne ich noch keine optimale Lösung). Und wer sich eine SSD blind kauft, sie ohne Überlegung einbaut und seine alte HD mit dd darauf klont, bekommt auch ein funktionierendes System - halt nur nicht die ganzen Goodies und Lebensdauer 😉 Warten wir mal ab, was Flo dazu sagt.
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Huhu Jungs! Was hat das Alignment mit dd zu tun? Das wird ja dadurch nicht verändert.
Das könnte man vielleicht noch etwas klarer ausdrücken. Gemeint war eine alte 512-B-Ausrichtung an der jetzt neuen 4-KB-Ausrichtung. Sprich: dd einer alten 512 B-HDD auf eine 4 KB-SSD. Dann ist das Alignment natürlich nicht korrekt. Allgemein finde ich auch, dass in den SSD-Artikeln eine richtige Angstmache vor Schreibvorgängen gefahren wird. Von einmal Vollschreiben der SSD werden ein paar Schreibzyklen verbraucht, klar. Aber unter "massiv" verstehe ich: 10 Mal gemacht und die SSD ist futsch. Ich würde sowas eher so formulieren: "Dies erzeugt viele unnötige Schreibvorgänge."
Das ist u. a. der langen Schreibzeit der Artikel geschuldet. Bei neueren SSD stimmt das natürlich nicht mehr. Früher™, als ich mit den Artikel begann (vor Lucid), war das durchaus noch ein Thema. Und der Nachteil von beschränkter /tmp Größe wird auch verschwiegen (Programme die mehr Platz brauchen stürzen ab oder geben Fehlermeldung). Zumal bei ein paar Logdateien die Schreibbelastung auch nicht so riesig ist.
Das steht im Hinweiskasten des betreffenden Artikels: „Verlagert man Dateien und Ordner von /tmp ins RAM, so sollte man sich darüber im Klaren sein, dass diese nach einem Neustart nicht mehr verfügbar sind. Auch sollte man die Auslastung des RAM im Auge behalten, so dass dieses nicht überläuft.“ Wie gesagt: Vieles ist der langen Entstehungszeit geschuldet. Mit aktuellen SSD/Kernel ist vieles besser und einfacher. Damit komme ich aber gleich zum nächsten Punkt: (…) aber zumindest bei aktuellen Platten (…). Wie definiert man aktuelle SSD/Kernel? Immerhin passt der Artikel ja sowohl mit 10.04 (Kernel 2.6.32) als auch mit Precise (Kernel 3.2). Einfacher wird es erst, wenn Lucid und Maverick EOL haben. Das dauert aber noch bis 2015 😬 Wenn Ihr also gute Vorschläge habt, wie man alte (aufwändige) und neue (komfortable, automatische) Konfigurationen unter einen Hut bringen kann, wäre ich dankbar für Vorschläge. Des Weiteren warte ich nur noch auf ein bisschen Zeit meinerseits, um dann die Artikel aus der aktuellen Linux-c't in die Artikel einzuarbeiten. Ich habe die entsprechenden Passagen schon ausgearbeitet. Liebe Grüße, Flo PS: Die SSD-Artikel bergen einen Haufen Wartung und Pflege. Einerseits sind sie sehr umfangreich, um auch wirklich alles für den Anfänger/Umsteiger parat zu haben, andererseits ist so vieles zurecht im Wandel (Technik, Kernel, Treiber, Dateisystem (Stichwort btrfs) usw), dass ich mich über jede helfende Hand freue. Daher auch Danke an Euch, ingo2 und stfischr, für konstruktive Kritik und Diskussionen 👍
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
UbuntuFlo schrieb: Huhu Jungs!
Wie gesagt: Vieles ist der langen Entstehungszeit geschuldet. Mit aktuellen SSD/Kernel ist vieles besser und einfacher. Damit komme ich aber gleich zum nächsten Punkt: (…) aber zumindest bei aktuellen Platten (…). Wie definiert man aktuelle SSD/Kernel? Immerhin passt der Artikel ja sowohl mit 10.04 (Kernel 2.6.32) als auch mit Precise (Kernel 3.2). Einfacher wird es erst, wenn Lucid und Maverick EOL haben. Das dauert aber noch bis 2015 😬 Wenn Ihr also gute Vorschläge habt, wie man alte (aufwändige) und neue (komfortable, automatische) Konfigurationen unter einen Hut bringen kann, wäre ich dankbar für Vorschläge.
Meine persönliche Meinung zu dem Problem: Ich fände es sehr schade, wenn die im Moment in den Artikeln zusammengefaßten Informationen durch "update" verloren gingen. Sie geben für interessierte User doch einen Einblick in die ganze Problematik und helfen "Hardware zu verstehen". Das heute vielleicht einige Ratschläge oberflächlich gesehen überflüssig sind, ist normal bei so junger Technologie. Zu der Frage: Wie definiert man aktuelle SSD/Kernel?
die Antwort: es gibt keine SSD-Kernel. Du kannst eine SSD auch unter Hardy mit 2.6.24 nutzen - wenn man o.g. berücksichtigt. Ein Vorschlag zur Lösung des Problems: in den aktuellen Artikeln "Verweismarken" setzen zu sogenannten "Updates", in denen dann beschrieben wird, was mit welchem Kernel, Dateisystem, SSD-Type, ... überflüssig geworden ist? sorry, ich weiß daß das der Haoor fürs Wiki-Tim wäre Ingo
|