Salix Forums

Ich schrieb gerade an einer Antwort zu Deinen letzten Texten, als ich laß, dass Du Begabung zum Zerstörer hast.

In dem Beitrag "Salix Xfce 14.2RC1 (32-bit) and 14.2RC2 (64-bit)" ist zu lesen, dass Lilosetup nicht mehr enthalten sei. Das wird wahrscheinlich auch auf die SalixLive-14.2-Variante zutreffen.

Die beiden zitierten Artikel aus dem Salix-Wiki sind veraltet. Einfach vergessen.

Beim Booten von Installations-CD oder SalixLive-CD muss nicht der selbe Kernel auf der Platte installiert sein, wie er auf CD ist. Es gibt kein Booten von CD in eine bestehende Installation hinein. Man kann auch nichts, absolut nichts, in eine bestehende ISO-Datei "hineinaktualisieren". Falls ein ISO-Image geändert werden muss, dann geschieht das in der Vorlage, aus der dann mittels speziellem Werkzeug ein neues Image erzeugt wird.

Man kann das gebootete SalixLive oder auch das System, das bereits ganz am Anfang beim Booten von Installations-CD entsteht, benutzen, um eine Reparatur am Dateisystem des bereits installierten Salix durchzuführen. Auch die UBCD ist für Reparaturversuche geeignet, denn darauf sind viele Werkzeuge genau für diesen Zweck.

Zu erst will ich einem Verdacht nachgehen.

Hast Du den "Speedtest" auf der neuen SSD durchführen wollen? Wenn ja, dann besteht die gute Wahrscheinlichkeit, dass diese nun als /dev/sda firmiert. Alte sda und die sdb sind nun sdb und sdc. Wo ist denn der MBR mit Bootloader für das Booten des Kernel /dev/sdb1 ? Bisherige sda oder sdb? Nach Deinem Auszug aus lilo.conf ist es sda (boot = /dev/sda). Es könnte sein, dass die beiden Lilo-Bootloader-Stufen auf die falschen Platten zugreifen. Wenn der Verdacht trifft, dann die neue SSD wieder elektrisch ausbauen. Dann erneut booten und dabei darauf achten, dass das Bios den Bootloader von der richtigen "Platte" laden will. Die Datei fstab muss zuvor wiederhergestellt werden.

War bei Auftreten des Fehlers keine Boot-Meldung zu sehen? Wenigsten ein oder zwei Zeichen der Lilo-Bootmeldung? Absolut nichts?

Welche lilo.conf und fstab kannst Du aus dem laufenden SalixLive heraus editieren? Sind das diejenigen im SalixLive-Dateisystem oder sind es tatsächlich die Dateien auf den SCSI-/SSD-Geräten? Letzteres deutet auf eine geringe Wahrscheinlichkeit hin, dass die Partitionstabelle(n) beschädigt ist/sind. Die Dateien lilo.conf und vor allem aber fstab müssen wiederhergestellt werden.



Wenn mein Verdacht nicht trifft, ist nun die Frage, was denn dieses UBCD verändert hat. Du musst mehr getan haben, als nur von der CD zu booten. Was war es denn genau?

Wenn dabei der MBR auf /dev/sda verändert wurde, dann lässt sich dieser vielleicht wieder herstellen. Wichtig ist zuerst, die Wiederherstellung des MBR auf /dev/sda, sofern er beschädigt wurde, damit der Kernel von /dev/sdb1 geladen werden kann. Dazu müsstest Du entweder einen Backup des MBR haben. Oder es existiert eine genaue Notiz der Aufteilung in Partitionen (Anfangssektoren, Endsektoren, Partitiontyp,...) in Datei oder auf Papier, wowie die aktuelle lilo.conf. Hast Du? Daraus ließe sich der MBR rekonstruieren. Wenn nur der Bootloader im MBR überschrieben wurde, dann lässt sich dieser auch getrennt wiederherstellen.

Wenn mehr auf /dev/sda verändert wurde, also die Inhalte der Partitionen überschrieben wurden, dann ist der Inhalt dieser SDD nun unbrauchbar. Das lässt sich nur durch neupartitionieren und einspielen der Datensicherung wiederherstellen.


Wenn die Partitiontabelle in /dev/sdb verändert wurde, dann lässt sich diese mit oben genannten Mitteln, nun aber für /dev/sdb, reparieren. Wurde der Inhalt von /dev/sdb sonstwie verändert, dann hat das die selben Folgen, wie bei /dev/sda.

Man kann den Bootloader von Lilo in den MBR und /boot schreiben lassen, ohne dafür chroot einzusetzen.

Es gibt noch einiges zur alternativen Strategie zu schreiben, aber nicht mehr heute Abend. Ich werde jetzt meinen Monatsvorrat an Kartoffeleintopf kochen.

Keine Panik und bitte keinen weiteren Aktionismus. Der Schaden wird sonst noch größer.

Gute Nacht

Moinsen,

Danke für die ausführliche Antwort und deine Gedanken.

Einige deiner Ausführung mögen richtig sein, basieren aber auf der unzutreffenden Annahme, dass die neue SSD bereits eingebaut sei.
Dem ist nicht so! Das hatte ich so auch nicht von mir gegeben.

Also, es gib noch keine neue SSD im System. Den Speedtest kann ich ja auch über ein LiveSystem abbilden oder die neue SSD dann einfach "hinten dran hängen" bis ich weiß was ich damit mache

Ich beschäftige mich ja bislang nur mit dem "alten" System (so wie es ist) und der Vorbereitung zum Einbau und Umzug.

Was die UBCD geändert hat, bleibt mir verschlossen. Ich habe wirklich keine Idee was ich angestellt haben könnte, das der mbr zerstört war.
Als ich versuchte die SCSI-Platte zu starten, wurden mir nur einige Zeilen mit Zahlen (überwiegend 0 und 9) angezeigt. Sonst ging nix.
Beim Versuch die (alte) SSD zu booten hatte ich lediglich einen blinkenden Cursor (soweit ich das noch erinnern kann).

Aber jetzt gehts ja zum Glück wieder.

Das die LiveSysteme nicht den gleichen Kernel haben müssen, ist mir geläufig. Würde sonst auch wenig Sinn machen. Die Knoppix-RettungsCD funktionierte ja auch auf allen möglichen Systemen.
Was die InstallationsCD angeht, mag ich womöglich tatsächlich daneben liegen, jedoch erschien es mir soweit logisch

So, alles weitere erst, wenn die neue Platte eingebaut und ausgetestet ist. Erst dann weiß ich was wohin kopiert/verschoben/installiert.... werden soll.

Bis dahin, viel Vergnügen beim Kartoffeln kochen und verspeisen der Eintopfportionen

Danke soweit.

So, die neue SSD ist drin.
Aber ich bin noch nicht so viel weiter.
Natürlich war die Bootreihenfolge wieder dahin, also SalixLive starten und lilo fixen.

Der Speedtest (mit dd) zeigt bei großen Dateien (1G) tatsächlich etwas bessere Transferraten als die "alte" Platte (250 <> 210MB/s)
allerdings sinkt die Rate bei kleineren Dateien dramatisch ab. Da muss ich nochmal wegen der Block/Clustergröße schauen.
Blockgröße 512Byte physisch ist ok, aber ob die Clustergröße auf 4k gesetzt ist muss ich noch prüfen und ggf. nochmal messen.
Die "alte" SSD zeigte da ein deutlich besseres Verhalten.

Ein Dateitransfer zwischen beiden Platten (Verzeichnisse mit vielen Dateien in unterschiedlicher Größe) lag jeweils um 80-90MB/s, egal welche
Richtung.

Danach werde ich erst entscheiden ob das System umzieht oder doch nur die Daten.

Tests dieser Art halte ich in diesem Fall für sinnlos.
Das Mainboard schein schon sehr alt zu sein. Ältere Hardware ist nicht so leistungsfähig, wie neuere. Auf dem Mainboard sind CPU und vor allem der Chipsatz schwach im Vergleich zu aktueller Hardware. Mit altem Chipsatz wird kein aussagefähiger Test zur Übertragungsgeschwindigkeit moderner Massenspeicher möglich sein.

Wenn die SSD unpartioniert und damit wahrscheinlich kein Dateisystem aufgebracht ist, dann erfolgen Schreiboperationen mit dd in anderer Weise, als auf ein Dateisystem. Zwischen den verschiedenen Dateisystemen gibt es auch noch deutliche Performance-Unterschiede.

Ein sinnvoller Test ist, auf tatsächliche Kapazität gegenüber dem Werbeversprechen zu prüfen.
Geeigent ist F3 (Fight Flash Fraud), ein Integritätstest für Flash-Speicher und andere Datenträger. http://oss.digirati.com.br/f3/ Ursprünglich zum Test auf betrügerische SD-Karten und USB-Speicherstäbchen gedacht, können damit selbstverständich auch SSDs getestet werden. Diese Tests geben auch Auskunft über mittlere Zugriffsgeschwindigkeiten. Benötigt werden nur die beiden Programme f3write und f3read. Auf dem zu testenden Datenträger muss ein Dateisystem angelegt sein.

Von Interesse sind noch die vollständige Bezeichnung der neuen und der älteren SSD, sowie die genaue Bezeichnung des SATA-Kontrollers.

N'Abend,

also Chipsatz ist ein Intel H55, mit Sata-II-Schnittstelle.

Die "alte" SSD ist eine OCZ Vertex-II, 60GB, SATA-II
die "neue" SSD ist eine Samsung EVO 750, 250GB, SATA-III

Im Grunde gehe ich aber davon aus, dass die von mir gemessenen Werte im Rahmen liegen.

Dateisystem ist XFS, wie bei Salix im Standard.

jpg153 wrote:also Chipsatz ist ein Intel H55, mit Sata-II-Schnittstelle.

Die "alte" SSD ist eine OCZ Vertex-II, 60GB, SATA-II
die "neue" SSD ist eine Samsung EVO 750, 250GB, SATA-III

Guten Morgen,

danke für die Informationen.

Meine Gerätschaften sind allesamt älter.

Eine SATA-III-SSD an einem SATA-II-Kontroller ist in Ordnung. Bitte einmal im Datenblatt prüfen, ob die SSD auf SATA-II-Betrieb gejumpert werden kann. Ggf. dann auch die Brücke stecken. Manche HDD/SSD bemerken den Betrieb an älteren Kontrollern nicht. Sie passen deshalb die Übertragungsgeschwindigkeit nicht an und verwenden in der Kommunikation Elemente, die nicht zum älteren Standard gehören. Das kann den Ablauf verlangsamen bis unmöglich machen. Hersteller bauen deshalb Steckmöglichkeiten zur Konfiguration ein. Einige Samsung-Laufwerke müssen über spezielle Hersteller-Software auf die gewünschte Betriebsart (z.B. 1,5-GBit/s-Modus) eingestellt werden.

Eine zweite Ursache für geringen Durchsatz sind beschädigte Anschlussleitungen. Enges biegen oder gar abknicken, wie häufig direkt hinter dem Stecker erfolgt, beschädigen die Symetrie der Adernpaare in der Leitung. Dieser Symetrieverlust hat bei der differenziellen Signalübertragung erhöhten Einfluss des "Störnebels" auf das Nutzsignal und verschlechtert so die Datenintegrität. Wenn der "üble" Einfluss dabei gering genug ist, kann man damit durchaus booten und das OS läuft. Wundert man sich dann über die Zähigkeit der Abläufe und kommt auf die Idee, die Protokollierungen (/var/log) anzusehen, dann findet man dort megabyteweise Protokollfehler und Wiederholungen verzeichnet. Wiedergeradebiegen kann die Situation noch weiter verschlechtern. Manche Datenleitungen werden schon stark gebogen geliefert. Die muss man, wenn sie verwendet werden, in Beobachtung halten.

Für beengte Verhältnisse existieren auch Anschlussleitungen mit abgewinkelten Steckern (nach oben, unten, rechts und links). Die Anschlussleitungen sollen in großzügigen Bögen verlegt werden (nicht übertreiben).

Der Chipsatz Intel H55 stellt sechs SATA-II-Schnittstellen bereit. Wenn genügend Anschlüsse herausgeführt sind und das CD-Laufwerk kein SCSI-Gerät ist, dann gibt es, vorbehaltlich anderer SCSI-Geräte, eigentlich keinen Grund mehr, den SCSI-Kontroller beizubehalten.

70 GByte (SCSI) + 60 GByte (SATA-II) + 250 GByte (SATA-III) = 380 GByte (gesamt)

Falls die SCSI wegfallen würde, blieben noch 310 GByte übrig. Ausgehend von vorherigen 130 GByte, eine gute Kapazitätssteigerung auf das 2,38-fache. Was soll ich sagen? Wenn der Geiz nicht so übergroß wäre, dann hätte es eine Samsung EVO 750 mit 500 GByte für ca. 50 % Preisaufschlag werden können , und weg duck!


In der aktuellen c't ist ein Vergleichstest von fünf Billig-SSDs enthalten. Schreibraten von 154 MByte/s bis 472 MByte/s. Leseraten von 524 MByte/s bis 562 MByte/s. Wahrscheinlich an aktuellen Chipsätzen/SATA-Kontrollern getestet. Durch die Preissteigerungen in den letzten Wochen, sei der Kaufanreiz gegenüber den SSD-Einsteigermodellen nicht mehr so groß, so die Redaktion. Übrigens, in der vorherigen Ausgabe war ein Vergleichstest von sieben magnetischen Festplatten mit Kapazitäten von zwei bis zehn TByte enthalten.

Seit Ende Juni 2016 läuft/lief in der Redaktion ein Test zur Lebensdauer von SSDs. Es sind/waren 12 SSDs im Dauereinsatz. Der Artikel erschien in der Ausgabe 1/2017 vom 24.12.2016. Eine Samsung SSD 750 EVO war auch im Test. Nach Artikel verträgt sie garantiert 60 Terabyte Written (TBW). Geschrieben wurden 1203 TByte. Höchste Schreibleistung erreichte eine Samsung SSD 850 Pro, mit 4623 TByte, 150 TBW. Diese war bis zum Redaktionsschluss für den Artikel nicht ausgefallen. Alle getesteten SSDs hielten weit länger als vom Hersteller zugesagt. Ein Rechner ist während des Tests gestorben und hat zwei im Test befindliche SSDs mitgerissen, die aber mit anderen Exemplaren im Dauertest enthalten waren.

jpg153 wrote:Dateisystem ist XFS, wie bei Salix im Standard.

Für mich nicht! Es kann sein, dass für den Einen oder Anderen im Slackware-Team und im Salix-Team es das Standard-Dateisystem ist. Vielleicht ist es deshalb sogar im Installationsablauf in der Auswahl der Dateisysteme vorgegeben (keine Erinnerung daran). Mehr aber nicht. Ich habe keine besonderen Anforderungen und verwende deshalb Ext4 auf Festplatten und Ext2 auf USB-Flash-Speicher und SD-Karten. SSDs werden gerade noch ausreichend unterstützt (TRIM-Befehl). Der Einsatz von XFS kann sich für große Dateien lohnen, wenn gut konfiguriert und nur wenige kleine Dateien enthalten sind. Überprüfe einmal, ob XFS TRIM-Unterstützung bietet. Ein Dateisystem ohne TRIM-Unterstützung kommt für SSD nicht in Frage.

http://www.pro-linux.de/artikel/2/1634/6,fazit.html
https://www.thomas-krenn.com/de/wiki/Linux_Dateisysteme
https://de.wikipedia.org/wiki/XFS_%28Dateisystem%29
https://de.wikipedia.org/wiki/Ext4
http://www.linuxquestions.org/questions ... ollid=2015
https://www.unixmen.com/review-ext4-vs-btrfs-vs-xfs/
http://arstechnica.com/civis/viewtopic.php?t=1169535

Das hier fand ich interessant und so fühlt es sich bislang auch an:

http://www.tomshardware.de/ssd-upgrade- ... 41243.html

Dateisysteme sind glaube ich fast philosophisch zu diskutieren.
In meinen Augen eine berechtigte Frage: Braucht der Privatmann ein "Journaling" Dateisystem?
Vorher ging es auch ohne.
Ich hatte schon überlegt auf ext2 umzustellen, bin aber bei XFS geblieben.

Ich werde mal die logs checken.

Danke soweit.

hatte auch wegen 500GB überlegt, aber schlichtweg "kein Geld" und die 250GB halten schon ne Ewigkeit

Schönen Dank für den Hypertextlink.

Hatte vergessen, Du kannst noch überprüfen, of die Platte/der Kontroller/der Hostadapter über UDMA betrieben wird. Die Change ist gering, dass es anders ist, aber ...
Wenn nicht, muss unbedingt darauf umgestellt werden, möglichst bei abmontiertem Dateisystem. Ein Beispiel für die Überprüfung: Hdparm kann auch auf SCSI-Laufwerke angewendet werden, wobei nicht alle Optionen funktionieren müssen.

Mit Hdparm kann auch ein Benchmark erfolgen.
Zu einer magnetischen Festplatte Samsung SpinPoint SP2504C, SATA-II 3,0 Gbit/s, DRAM-Puffergröße 8 MByte,
enthält das Datenblatt leider nur:

• Data Transfer Rate
  Media to/from Buffer (max.) 973 Mbits/sec
  Buffer to/from Host (max.) 133 Mbytes/sec

Mit einem Hdparm-Test erreiche ich: Der Test läuft ca. 10 Sekunden und sollte mehrmals nacheinander ausgeführt werden, wobei weitere Belastungen vermieden werden sollen. Kann nicht mehr sagen, ob hdparm von mir nachinstalliert wurde.

Die Daten auf SATA-Datenleitungen werden kodiert mit 10 Bit je Byte übertragen. 973 MBit/s aus dem Datenblatt bedeuten also 778,4 MBit/s netto, gleich max. 97,3 MByte/s netto. In dem Test werden also 59 % der maximalen (gepufferten) Leserate erreicht. Der Chipsatz ist mit Unterstützung nach SATA-I 1,5 GBit/s ausgestattet, also bis zu 150 MByte/s Datentransferrate. Die erreichten 57,82 MByte/s stellen also 38 % der Kapazität eines Kanals des Chipsatzes dar. Nicht gut.

Zum Spaß und zum Vergleich mit einem (P)ATA-DVD-Laufwerk HL-DT-ST DVDRAM GSA-H10N,
mit DVD+R: mit DVD-RAM und UDF-Dateisystem: Gutes Gelingen!

So,

fettich

Nachdem die lilo/boot-Problematik mit dem PARTUUID-Ansatz gelöst werden konnte, habe ich mit die Daten auf die neue SSD geschoben.
Ich hatte mich entschlossen die neue SSD nur als Datenlaufwerk einzusetzen, da die Leistungsunterschiede zwischen der OCZ-SSD und der Samsung-SSD
aufgrund der recht betagten System-Architektur einen kompletten Systemumzug nicht wirklich rechtfertigte.

Im Grunde musste ich zwischendurch nur immer wieder drauf achten die fstab zu aktualisieren.

Ich habe, bis auf eine Ausnahme, alle Partitionen mit XFS formatiert. Was in dem Zusammenhang auffiel,
löschen von vielen kleinen Dateien ist kreuzlahm.

Nachdem ich die Daten von der SCSI-HD auf die SSD verschoben hatte, habe ich die Inhalte der Datenpartition von der alten SSD
auf die neue SSD kopiert.
Danach habe ich die alte Datenpartition gelöscht, die alte Systempartition erweitert, eine neu primäre Partition für das
32-Bit Salix und eine neue Datenpartition angelegt.
Danach musste ich von einem Live-System starten, da Gparted im laufenden Betrieb die erweitere Systempartition nicht ordnungsgemäß
vorbereiten konnte.
Im Live-System habe ich dann die alte 32-bit Umgebung von der SCSI-HD auf die (alte) SSD kopiert.

Die fstab musste natürlich mit den neuen Partitionsangaben versorgt werden.

Nach einer Funktionsprüfung des Systems mit 1xSCSI und 2xSATA-SSD habe ich dann die SCSI-HD samt Hostadapter entfernt.
Zusätzlich habe ich die Reihenfolge der SSD getauscht, sodass die OCZ-SSD mit dem Linuxsystem als erste gebootet wird.
Danach habe ich mich wieder mit den beiden Live-Systemen (OBCD und Salix Live) gequält um Lilo-Setup zum schreiben des
Bootsektors zu bewegen.
Aus mir unbekannten Gründen erlaubt mir Lilo-Setup manchmal nicht die Option "Bootloader installieren" auszuwählen.
Letztlich hat es aber funktioniert und das neue System 2xSSD (nur) lief auf Anhieb.

Neben Lilo-Setup und den Live-Systemen nervte mich eigentlich nur, dass ich immer wieder "sudo"en musste, aber häufig nicht daran
gedacht hatte.
Auch gelegentliche Episoden mit tar-bzip u.a.m. haben Nerven und Zeit gekostet, aber
Ende gut, Alles gut!