Der leise Tod einer SSD...?...

[Volker Bartheld]

On Thu, 16 Dec 2021 23:21:13 +0100, Sieghard Schicktanz wrote:

Du schriebst am Thu, 16 Dec 2021 11:32:15 +0100:
anderes) alle paar Monate einem vollen Verify.
Womit bzw. gegen welche Referenz? Dein in Betrieb befindliches OS (und
darum ging es bei mir konkret) hat sich natürlich bereits vom Backup
wegentwickelt. Updates, temporäre Dateien, Logs, usw. Ähnlich wird es
Deswegen macht man Backups ja _regelmäßig_, wenn sich was verändert
hat oder verändert haben könnte.

Ahso. Ich sag Dir mal was. Folgendes hat sich verändert: Umstellung auf
AHCI, Chrome, Inkscape, Audacity, MS Security Essentials, Lightworks,
Einträge im Event Log, die Registry, irgendwelche sonstigen Dateien,
deren genaue Bedeutung nur Microsoft kennt.

Was genau hat sich also nun rechtmäßigerweise verändert, was hat die
Samsung SSD zerhackstückt?

bei archivierten Backups zu unterschiedlichen Zeitpunkten sein. Also
mußt Du irgendwelche Prüfsummen für Dateien erstellen und
verifizieren. Ich vertraue dabei auf mein NAS und die Macht von

Prüfsummen sind für Verfikation eigentlich nicht geeignet. Das sollte
Dir mathematisch eigentlich klar sein, eine Prüfsumme kann nur soviele
unterschiedliche Zustände haben wie die Anzahl ihrer Bits hergibt.
Schon jede kleine Datei ist üblicherweise um ein vielfaches größer,
hat also um Myriaden mehr möglich - vor allem fehlerhafte - Zustände,
von denen jeweils wieder Myriaden auf dieselbe Prüfsumme abgebildet
werden.

Melodien für Myriaden. Äh. Melonen. Äh. Millionen. Wie hoch ist denn die
Kollisionswahrscheinlichkeit von SHA256 so? Vielleicht im Vergleich mit
der Rate an unkorrigierbaren, unbemerkten Fehlern einer SSD? Das sollte
Dir mathematisch eigentlich klar sein.

Ja, in den \"meisten Fällen\" wird eine Änderung am Dateiinhalt
auch eine andere Prüfsumme ergeben - aber eben nicht immer. Die einzig
wirklich zuverlässige Methode ist halt doch der vollständige Vergleich.

Ahja. Die ist wirklich zuverlässig. Weil BTRFS (oder halt ext4) ja
wirklich zuverlässig ist und das RAID aus zwei - Tusch! - 8TB
Drehplatten ebenfalls, wir raten es schon, wirklich zuverlässig. Oder
etwa doch nicht? Sollte es da etwa auch Controllerfehler und
Datendegradation geben? Fragen über Fragen...

BTRFS. Natürlich werden die Volumes das NAS regelmäßig auf externe
Ja, BTRFS. Das Dateisystem, das sich jahrelang mimosenhaft verhalten
und in vielen \"unüblichen\" Fällen gerne selber zerlegt hat. Ich bin
bisher bei ext(4) geblieben

Prima! Dazu gibt es ja nur gut 100 offene Bugs statt reichlich 500, wie
bei BTRFS.

Dann befass\' Dich besser nicht mit den Speichermethoden irgendwelcher
Datenträger - Du würdest lieber wieder alles auf Papierzettel notieren

Genau. Aber *Du* befaßt *mich* mit Speichermethoden und erklärst, daß
eine Stichprobe ja garnienicht geeignet sei, auf die Integrität zu
schließen. Und am Ende ist doch eh wieder alles wurscht.

Danach mit der Runtime-CD die Daten auf
diese Partition zurückspielen. Sodann (leider) nochmal die
Windows-Wiederherstellungs-CD booten und irgendwas reparieren, denn
Windows beschwert sich aus unerfindlichen Gründen über ein nicht
existentes Bootmedium. Vermutlich war irgendwo eine Device-ID

Das ist ein weithin bekannter \"Effekt\" bei Windows, weil sich der
Boot-Lader \"merkt\", wo auf der Platte er den Kernel finden soll. Wenn
der wegen \"Umzug\" dann woanders liegt, findet er ihn nicht mehr und
jammert.

Mei, DISK 0 PARTITION 1 SECTOR 1024 wäre offenbar zu kompliziert
gewesen.

Die neue 860 Pro hält 250MB/s über Transfers mit zweistelligen GB, so
Na dann, viel Spaß damit!

Mir reichts, wenn sie einfach wieder 8 Jahre unauffällig im Hintergrund
ihren Dienst tut. Bin ja kein Frickler.

Volker

 

[Michael Schwingen]

On 2021-12-17, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:

Die fragliche SSD habe ich noch, aber inzwischen meldet sie sich gar
nicht mehr. Hatten die vielleicht die eigene Firmware auch im Flash?

Wo denn sonst?

In einem dedizierten NOR-Flash anstatt dem NAND-Flash für die
Benutzerdaten. Also die Art von Flash die man auch beim PC für das BIOS
benutzt.

Sowas kostet Geld.

Ich hatte mal eine ältere OCZ (120GB Vertex 2) zerlegt, weil die ihre
Firmware vergessen hatte (Serienproblem). Ich kann mich nicht an ein
dediziertes NOR-Flash erinnern.

Mit den auf dubiosen Internetseiten zu findenden Herstellertools liess die
sich wiederbeleben - man musste die genauen Daten der verbauten NAND-Flashes
und diverse andere Parameter eingeben, und im 5. Anlauf ging es dann. Läuft
seitdem problemlos, aber natürlich nur für unwichtige Daten (SMART meint,
die Flashes seien brandneu, die Zähler waren natürlich auch weg). Als
Bootmedium für ein embedded Linux während der Entwicklung ist die aber nett
- selbst USB3-Sticke der Mittelklasse sind bei dem Szenario schnarchlangsam.

Will sagen: es ist heute bei diversen Embedded-CPUs Standard, daß ein
On-Chip-Bootloader die Firmware aus einem NAND-Flash ins RAM umkopiert
(incl. Fehlerkorrektur).

cu
Michael

 

[Hanno Foest]

On 17.12.21 17:34, Volker Bartheld wrote:

Haste das nachgeprüft oder vermuteste das bloß?
Anhand einer Stichprobe.
Also nicht.

Wie hättest Du es denn gemacht, die Integritätsprüfung einer
inkrementell-chronologischen Liste von Backups der 120GB-Bootpartition?
Erzähl!

Output von rsync -an und rsync -acn vergleichen. Bei der zweiten
Variante des Befehls sollten keine weiteren Dateiübertragungen
dazukommen, dann sind die laut timestamp und Größe unveränderten Dateien
auch wirklich inhaltlich unverändert.

Klappt vermutlich nur, wenn die Backups auch schon mit rsync -a
entstanden sind.

Ich erinnere mich an einen Job so um 2003, wo Windows es beim Schreiben
auf den Fileserver geschafft hat, Dateien inhaltlich zu verändern, ohne
timestamp und Größe anzufassen... ganz toll sowas.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Sieghard Schicktanz]

Hallo Gerrit Heitsch,

Du schriebst am Fri, 17 Dec 2021 06:52:57 +0100:

Das ist ein weithin bekannter \"Effekt\" bei Windows, weil sich der
Boot-Lader \"merkt\", wo auf der Platte er den Kernel finden soll.
Wenn der wegen \"Umzug\" dann woanders liegt, findet er ihn nicht
....
Das gleiche Problem hast du bei jedem OS. Irgendwie muss es das mit
dem Boot hinbekommen. Die Daten dazu stehen alle im Filesystem, aber
der Bootcode ist viel zu klein um einem kompletten Filesystemtreiber

Das konnte sogar schon der uraltte Boot-Lader im PC-BIOS der ersten
IBM-Kompatiblen PCs. Der hat halt erstmal die nächsten Sektoren
nachgezogen, wo dann ein erweiterter Lader stand, der dann schon mehr
Information über seine Aufgabe hatte, und damit ging\'s dann weiter,
entweder gleich zum Kernel oder zu einem menübasierten System-Lader.
(So einen Boot-Sektor-Lader habe ich mir damals auch mal selber gebaut.)

zu enthalten, muss sich also mit Tricks behelfen bis genug geladen
wurde um korrekt mit dem Filesystem arbeiten zu können.

Je nachdem wie die Daten im File-System liegen reicht da evtl. schon
die Angabe des Startsektors (bei konsekutiver Speicherung) oder muß
eine \"Block-Liste\" vorhanden sein, die der Reihe nach die von der
Platte zu ladenden Blöcke enthält. Dazu reichen schon ein paar
Sektoren, von denen früher sogar auf Floppies immer welche frei waren,
weil die Daten üblicherweise erst ab der zweiten Spur (Spur 1) lagen.
Bei Festplatten war noch mehr Platz, 62 Sektoren, und heute werden ja
sowieso erst ab Sektor 4096 \"richtige\" Daten abgelegt, bzw. die
Partitionierung begonnen.
Nee, daß Windows da - immer noch - eine \"Reparatur\" nach einem Umzug
braucht, ist lediglich der primmitiven Struktur des Laders geschuldet.
Aber ein Windows \"kann\" ja auch nicht legal umziehen, das verhindert ja
schon die Politik der Firma mit ihren Lizensierungen und Aktivierungen
und was noch allem.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Volker Bartheld,

Du schriebst am Fri, 17 Dec 2021 17:46:41 +0100:

Deswegen macht man Backups ja _regelmäßig_, wenn sich was verändert
hat oder verändert haben könnte.

Ahso. Ich sag Dir mal was. Folgendes hat sich verändert: Umstellung
auf AHCI, Chrome, Inkscape, Audacity, MS Security Essentials,
Lightworks, Einträge im Event Log, die Registry, irgendwelche
sonstigen Dateien, deren genaue Bedeutung nur Microsoft kennt.

Was genau hat sich also nun rechtmäßigerweise verändert, was hat die

Na, _der_ Beschreibung nach so ziemlich alles. Und neu partitioniert
haste möglicherweise auch noch.

> Samsung SSD zerhackstückt?

Wahrscheinlich ist ihr halt der Reserveplatz ausgegangen, der noch
nicht völlig verbrauchte Speicherstellen enthielt. War doch schon ein
\"älteres Semester\", Deiner Angaben nach?

[Prüfsummen]

Melodien für Myriaden. Äh. Melonen. Äh. Millionen. Wie hoch ist denn
die Kollisionswahrscheinlichkeit von SHA256 so? Vielleicht im

Rechne\'s selber aus, kannst es ja wohl.

Vergleich mit der Rate an unkorrigierbaren, unbemerkten Fehlern einer
SSD? Das sollte Dir mathematisch eigentlich klar sein.

Im Gegensatz zu einer Liste von Prüfsummen sind die Fehlerkorrekturdaten
aber _redundant_, für optimale Erkennung und Korrigierbarkeit von
Fehlern ausgelegt und inzwischen schon bald umfangreicher als das, was
als \"Nutzdaten\" vorgegeben wird. (Eine echte Unterscheidung zwischen
denen und den Korrekturdaten ist auf der Speicherebene eh nicht mehr
möglich.)

....

Drehplatten ebenfalls, wir raten es schon, wirklich zuverlässig. Oder
etwa doch nicht? Sollte es da etwa auch Controllerfehler und
Datendegradation geben? Fragen über Fragen...

Wo sind da die Fragen? Allenfalls eine: Was ist \"wirklich zuverlässig\"?

....

bisher bei ext(4) geblieben

Prima! Dazu gibt es ja nur gut 100 offene Bugs statt reichlich 500,
wie bei BTRFS.

Ich will Dich ja nicht überreden. 20% soviel Fehler seh\' ich zwar als
weniger an, und deren Schwere ist dabei auch unberücksichtigt, aber
kaputtgehen kann da auch mal was. Hatte ich letztens sogar mal, aber
das war wohl eher wegen eines Kernel-Problems, von dem ich sogar schon
vorher was gelesen hatte. Backup, alten Kernel wieder drauf, läuft.

....
> eine Stichprobe ja garnienicht geeignet sei, auf die Integrität zu

Ist sie auch nicht, oder, so gesagt, etwa so gut wie ein
Umfrageergebnis für einen Wahlausgang.

> schließen. Und am Ende ist doch eh wieder alles wurscht.

Dafür reicht\'s dann schon.

....

Mir reichts, wenn sie einfach wieder 8 Jahre unauffällig im
Hintergrund ihren Dienst tut. Bin ja kein Frickler.

Naschön, mußte ja auch nich. Ich bin halt beruflich nicht ganz
unbelastet mit solchen G\'schichterln.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Volker Bartheld]

On Fri, 17 Dec 2021 22:50:46 +0100, Hanno Foest wrote:

On 17.12.21 17:34, Volker Bartheld wrote:
Haste das nachgeprüft oder vermuteste das bloß?
Anhand einer Stichprobe.
Also nicht.
Wie hättest Du es denn gemacht, die Integritätsprüfung einer
inkrementell-chronologischen Liste von Backups der 120GB-Bootpartition?
Erzähl!
Output von rsync -an und rsync -acn vergleichen.

Ich glaube, wir mißverstehen uns. Es exisitieren auf den NAS Backups
einer Bootpartition zum Zeitpunkt t_1, t_2, ... t_i. Die spiegeln
natürlich alle unterschiedliche Zustände der Bootpartition und des
Betriebssystems wider, sonst wären sie ja unnötig. Wir kann ich also nun
angesichts einer lokal auf dem PC vorhandenen Bootpartition t_n im
Vergleich mit t_1, ... t_i feststellen, welche noch OK ist und welche
von einer maladen SSD zerhackstückt wurde, angesichts der Möglichkeit,
daß auch t_n zerhackstückt wurde?

Wie ich zwei Datensätze auf Identität überprüfe, ist mir klar. Da gibt
es 1001 Möglichkeiten, rsync -acn ist genauso gut wie irgendwelche
SHA-Hashes.

Meine \"Stichprobe\" bezog sich auf die Untermenge der Windows-Dateien,
die mutmaßlich keinen Veränderungen im Betrieb unterliegen. Diese
Untermenge war binäridentisch. Das reicht mir als Indiz, daß die SSD
keine Dateien inhaltlich verändert hat, auch wenn es natürlich
ausgerechnet im HKLM-Hive der Registry, dem Eventlog, den
Installationsdateien von Google Chrome (nach Update) oder irgendwelchen
Virussignaturen hätte passieren können.

Klappt vermutlich nur, wenn die Backups auch schon mit rsync -a
entstanden sind.

Klappt nur, wenn die Referenz nach dem Backup nicht verändert wurde.

Volker

 

[Volker Bartheld]

On Fri, 17 Dec 2021 23:17:03 +0100, Sieghard Schicktanz wrote:

[Binärer Verify besser als SHAxxx, wegen \"Kollisionsgefahr\"]
Rechne\'s selber aus, kannst es ja wohl.

Das ist Quatsch und Du lenkst ab.

Vergleich mit der Rate an unkorrigierbaren, unbemerkten Fehlern einer
SSD? Das sollte Dir mathematisch eigentlich klar sein.

Im Gegensatz zu einer Liste von Prüfsummen sind die Fehlerkorrekturdaten
aber _redundant_, für optimale Erkennung und Korrigierbarkeit von
Fehlern ausgelegt und inzwischen schon bald umfangreicher als das, was
als \"Nutzdaten\" vorgegeben wird.

Das ist irrelevant und Du lenkst ab. Es ging hier um die Möglichkeit die
Integrität eines Datensatzes anhand einer Stichprobe (warum
\"Stichprobe\" habe ich hoffentlich inzwischen hinreichend verständlich
dargelegt zu überprüfen. Da unterziehe ich nicht 40GB (bzw. 5TB, wenn
es darum geht, zu wissen, ob mein NAS auch richtig die Backupplatte
befüllt hat) einer zeitintensiven Binärverifikation, sondern schaue mir
die Quersummen an.

Drehplatten ebenfalls, wir raten es schon, wirklich zuverlässig. Oder
etwa doch nicht? Sollte es da etwa auch Controllerfehler und
Datendegradation geben? Fragen über Fragen...
Wo sind da die Fragen? Allenfalls eine: Was ist \"wirklich zuverlässig\"?

Nichts. Damit war Deine Frage...

Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance
auf sich aufmerksam zu machen und hat nicht klammheimlich meine Daten
zerhackstückelt.
Haste das nachgeprüft oder vermuteste das bloß?

.... rhetorisch und die ganze sich daran anschließende Diskussion
irrelevant. Gut, daß wir das jetzt auch geklärt haben.

bisher bei ext(4) geblieben
Prima! Dazu gibt es ja nur gut 100 offene Bugs statt reichlich 500,
wie bei BTRFS.
Ich will Dich ja nicht überreden. 20% soviel Fehler seh\' ich zwar als
weniger an, und deren Schwere ist dabei auch unberücksichtigt, aber
kaputtgehen kann da auch mal was.

Deswegen Untermenge der Daten als Arbeitskopie auf lokaler SSD, der
komplette Datensatz auf dem NAS in RAID-1 Architektur, rotierendes
Backup auf drei externen USB-Platten unterschiedlicher Hersteller bzw.
Bauserien und gelegentlich Integritätsprüfung.

Mir reichts, wenn sie einfach wieder 8 Jahre unauffällig im
Hintergrund ihren Dienst tut. Bin ja kein Frickler.
Naschön, mußte ja auch nich. Ich bin halt beruflich nicht ganz
unbelastet mit solchen G\'schichterln.

Und Du hältst mich für naiv? So kann man sich täuschen. Irgendwann siegt
eben der Pragmatismus.

Volker

 

[Volker Bartheld]

On Fri, 17 Dec 2021 22:50:46 +0100, Hanno Foest wrote:

On 17.12.21 17:34, Volker Bartheld wrote:
Haste das nachgeprüft oder vermuteste das bloß?
Anhand einer Stichprobe.
Also nicht.
Wie hättest Du es denn gemacht, die Integritätsprüfung einer
inkrementell-chronologischen Liste von Backups der 120GB-Bootpartition?
Erzähl!
Output von rsync -an und rsync -acn vergleichen.

Ich glaube, wir mißverstehen uns. Es existieren auf dem NAS Backups
einer Bootpartition zum Zeitpunkt t_1, t_2, ... t_i. Die spiegeln
natürlich alle unterschiedliche Zustände der Bootpartition und des
Betriebssystems wider, sonst wären sie ja unnötig. Wir kann ich also
nun angesichts einer lokal auf dem PC vorhandenen Bootpartition t_n im
Vergleich mit t_1, ... t_i feststellen, welche noch OK ist und welche
von einer maladen SSD zerhackstückt wurde, angesichts der Möglichkeit,
daß auch t_n zerhackstückt wurde?

Wie ich zwei Datensätze auf Identität überprüfe, ist mir klar. Da gibt
es 1001 Möglichkeiten, rsync -acn ist genauso gut wie irgendwelche
SHA-Hashes.

Meine \"Stichprobe\" bezog sich auf die Untermenge der Windows-Dateien,
die mutmaßlich keinen Veränderungen im Betrieb unterliegen. Diese
Untermenge war binäridentisch. Das reicht mir als Indiz, daß die SSD
keine Dateien inhaltlich verändert hat, auch wenn es natürlich
ausgerechnet im HKLM-Hive der Registry, dem Eventlog, den
Installationsdateien von Google Chrome (nach Update) oder irgendwelchen
Virussignaturen hätte passieren können.

Klappt vermutlich nur, wenn die Backups auch schon mit rsync -a
entstanden sind.

Klappt nur, wenn die Referenz nach dem Backup nicht verändert wurde.

Volker

 

[Hanno Foest]

On 18.12.21 11:40, Volker Bartheld wrote:

Wie hättest Du es denn gemacht, die Integritätsprüfung einer
inkrementell-chronologischen Liste von Backups der 120GB-Bootpartition?
Erzähl!
Output von rsync -an und rsync -acn vergleichen.

Ich glaube, wir mißverstehen uns. Es existieren auf dem NAS Backups
einer Bootpartition zum Zeitpunkt t_1, t_2, ... t_i. Die spiegeln
natürlich alle unterschiedliche Zustände der Bootpartition und des
Betriebssystems wider, sonst wären sie ja unnötig. Wir kann ich also
nun angesichts einer lokal auf dem PC vorhandenen Bootpartition t_n im
Vergleich mit t_1, ... t_i feststellen, welche noch OK ist und welche
von einer maladen SSD zerhackstückt wurde, angesichts der Möglichkeit,
daß auch t_n zerhackstückt wurde?

Ich weiß nicht, wie das bei dir ist, aber ich hab hier so 3 TB
Plattenplatz im Arbeitsrechner, und so 2 TB davon fasse ich praktisch
nie (oder nur lesend) an, und das ist mehr als 2/3 des Datenbestands,
weil das rechtliche TB eher lose gefüllt ist. Wenn ich jetzt rsync -an
und rsync -acn vergleiche, hab ich (über diverse Backupgenerationen)
eine ganze Menge Dateien, die identisch sein müssen. Ist das der Fall,
wird auch wohl der wegen Veränderung nicht testbare Teil ok sein.

Klappt vermutlich nur, wenn die Backups auch schon mit rsync -a
entstanden sind.

Klappt nur, wenn die Referenz nach dem Backup nicht verändert wurde.

Was du gelöscht hast:

\"Bei der zweiten Variante des Befehls sollten keine weiteren
Dateiübertragungen dazukommen, dann sind die laut timestamp und Größe
unveränderten Dateien auch wirklich inhaltlich unverändert.\"

Damit überprüfst du natürlich nur die unveränderten Dateien. Wenn du
keine nennenswerten Mengen unveränderter Dateien hast, mag das nicht
aussagekräftig sein, aber wenn sich eh immer alles ändert, ist auch der
Nutzen eines Backups fraglich...

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Gerrit Heitsch]

On 12/17/21 7:56 PM, Michael Schwingen wrote:

On 2021-12-17, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
Die fragliche SSD habe ich noch, aber inzwischen meldet sie sich gar
nicht mehr. Hatten die vielleicht die eigene Firmware auch im Flash?

Wo denn sonst?

In einem dedizierten NOR-Flash anstatt dem NAND-Flash für die
Benutzerdaten. Also die Art von Flash die man auch beim PC für das BIOS
benutzt.

Sowas kostet Geld.

Ich hatte mal eine ältere OCZ (120GB Vertex 2) zerlegt, weil die ihre
Firmware vergessen hatte (Serienproblem). Ich kann mich nicht an ein
dediziertes NOR-Flash erinnern.

So etwas kann man heute in den Controller selbst integrieren. Vor Jahren
hatte ich einen Promise-Controller mit 2 x IDE133. Da war genau ein Chip
auf dem Board, der Controller eben. Trotzdem konnte man seine Firmware
updaten. Legt den Schluss nahe, daß das Flash mit im Controller war.

Wenn da beim SSD-Controller aber nur ein kleiner Bootloader steht und
die eigentliche Firmware im NAND-Flash, dann hat man bei vergesslichem
NAND-Flash natürlich verloren.

Gerrit

 

[Gerrit Heitsch]

On 12/17/21 11:00 PM, Sieghard Schicktanz wrote:

Hallo Gerrit Heitsch,

Du schriebst am Fri, 17 Dec 2021 06:52:57 +0100:

Das ist ein weithin bekannter \"Effekt\" bei Windows, weil sich der
Boot-Lader \"merkt\", wo auf der Platte er den Kernel finden soll.
Wenn der wegen \"Umzug\" dann woanders liegt, findet er ihn nicht
...
Das gleiche Problem hast du bei jedem OS. Irgendwie muss es das mit
dem Boot hinbekommen. Die Daten dazu stehen alle im Filesystem, aber
der Bootcode ist viel zu klein um einem kompletten Filesystemtreiber

Das konnte sogar schon der uraltte Boot-Lader im PC-BIOS der ersten
IBM-Kompatiblen PCs. Der hat halt erstmal die nächsten Sektoren
nachgezogen, wo dann ein erweiterter Lader stand, der dann schon mehr
Information über seine Aufgabe hatte, und damit ging\'s dann weiter,
entweder gleich zum Kernel oder zu einem menübasierten System-Lader.
(So einen Boot-Sektor-Lader habe ich mir damals auch mal selber gebaut.)

Natürlich ist das machbar, jeder Computer beweist das bei jedem Boot.
Aber es geht eben nicht ohne Tricks wie feste Sektoren zu laden die in
einem Filesystem liegen wo das eigentlich nicht der Fall ist.

Linux hat dazu noch das Problem, daß es viele Filesysteme beherrscht,
der Loader also deutlich intelligenter sein muss als der von Windows
oder MacOS.

Nee, daß Windows da - immer noch - eine \"Reparatur\" nach einem Umzug
braucht, ist lediglich der primmitiven Struktur des Laders geschuldet.

Eher der Tatsache, daß nach einer reinen Kopie auf Filesystemebene die
Sektoren die der Loader an Position <X> erwartet dort nicht mehr liegen
sondern beim Kopiervorgang nach <Y> umgezogen sind. Das muss man ihm
sagen, dann bootet Windows auch wieder.

Gerrit

 

[Sieghard Schicktanz]

Hallo Gerrit Heitsch,

Du schriebst am Sat, 18 Dec 2021 18:24:58 +0100:

Das konnte sogar schon der uraltte Boot-Lader im PC-BIOS der ersten
IBM-Kompatiblen PCs. Der hat halt erstmal die nächsten Sektoren
nachgezogen, wo dann ein erweiterter Lader stand, der dann schon
....
Natürlich ist das machbar, jeder Computer beweist das bei jedem Boot.
Aber es geht eben nicht ohne Tricks wie feste Sektoren zu laden die
in einem Filesystem liegen wo das eigentlich nicht der Fall ist.

Oft liegen die nichtmal in einem Dateisystem, so macht das oft z.B.
der grub für seine Zwischenstufe.

Linux hat dazu noch das Problem, daß es viele Filesysteme beherrscht,
der Loader also deutlich intelligenter sein muss als der von Windows
oder MacOS.

Wobei der Lader \"grub\" schon selber ein kleines Betriebssystem mit
mehreren Treibern für Dateisysteme darstellt. Der kann auch durchaus
seine Dateien aus einer FAT-Partition holen, anscheinend geht sogar
NTFS, und einige ander eauch.

Nee, daß Windows da - immer noch - eine \"Reparatur\" nach einem Umzug
braucht, ist lediglich der primmitiven Struktur des Laders
geschuldet.

Eher der Tatsache, daß nach einer reinen Kopie auf Filesystemebene
die Sektoren die der Loader an Position <X> erwartet dort nicht mehr
liegen sondern beim Kopiervorgang nach <Y> umgezogen sind. Das muss
man ihm sagen, dann bootet Windows auch wieder.

Ja, genau das hatte ich ja geschrieben. Das kommt halt davon, daß die
Voraussetzungen, von denen MS ausgeht, eine solche Veränderung garnicht
vorsehen. Immerhin _gibt_ es ja eine Reparaturfunktion dafür.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Volker Bartheld,

Du schriebst am Sat, 18 Dec 2021 11:36:16 +0100:

Drehplatten ebenfalls, wir raten es schon, wirklich zuverlässig.
Oder etwa doch nicht? Sollte es da etwa auch Controllerfehler und
Datendegradation geben? Fragen über Fragen...
Wo sind da die Fragen? Allenfalls eine: Was ist \"wirklich
zuverlässig\"?

Nichts. Damit war Deine Frage...

Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance
auf sich aufmerksam zu machen und hat nicht klammheimlich meine
Daten zerhackstückelt.
Haste das nachgeprüft oder vermuteste das bloß?

... rhetorisch und die ganze sich daran anschließende Diskussion

^^^^^^^^^^
Nein. (Sorry, ich wollte das nur klargestellt haben.)

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Gerrit Heitsch]

On 12/18/21 9:50 PM, Sieghard Schicktanz wrote:

Hallo Gerrit Heitsch,

Du schriebst am Sat, 18 Dec 2021 18:24:58 +0100:

Das konnte sogar schon der uraltte Boot-Lader im PC-BIOS der ersten
IBM-Kompatiblen PCs. Der hat halt erstmal die nächsten Sektoren
nachgezogen, wo dann ein erweiterter Lader stand, der dann schon
...
Natürlich ist das machbar, jeder Computer beweist das bei jedem Boot.
Aber es geht eben nicht ohne Tricks wie feste Sektoren zu laden die
in einem Filesystem liegen wo das eigentlich nicht der Fall ist.

Oft liegen die nichtmal in einem Dateisystem, so macht das oft z.B.
der grub für seine Zwischenstufe.

Irgendwann muss auch grub ins Dateisystem wechseln, spätestens wenn der
Kernel geladen werden soll. Dazu braucht es dann mindestens einen
rudimentären Treiber für das fragliche FS oder eben feste Sektoren.

Gerrit

 

[Volker Bartheld]

On Sat, 18 Dec 2021 14:29:34 +0100, Hanno Foest wrote:

Ich weiß nicht, wie das bei dir ist, aber ich hab hier so 3 TB
Plattenplatz im Arbeitsrechner, und so 2 TB davon fasse ich praktisch
nie

Anders. Meine lokale SSD ist so klein, wie es irgend geht und enthält
nur das, was ich aktuell brauche. Ist der Job erledigt, fliegt der Kram
runter. Wofür habe ich ein schnelles NAS?

Klappt vermutlich nur, wenn die Backups auch schon mit rsync -a
entstanden sind.
Klappt nur, wenn die Referenz nach dem Backup nicht verändert wurde.
Was du gelöscht hast: \"Bei der zweiten Variante des Befehls sollten
keine weiteren Dateiübertragungen dazukommen, dann sind die laut
timestamp und Größe unveränderten Dateien auch wirklich inhaltlich
unverändert.\" Damit überprüfst du natürlich nur die unveränderten
Dateien.

Nenne ich eine Stichprobe. Die war unauffällig.

Volker

 

[Axel Berger]

Volker Bartheld wrote:
> Wofür habe ich ein schnelles NAS?

Ist das nicht reine Ablenkung? Du machst Backups natürlich von der
Platte, auf der die Daten liegen. Wo die Platte physisch tatsächlich
eingebaut ist, ist für die Frage vollkommen irrelevant.


--
/¯\\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \\ Mail | -- No unannounced, large, binary attachments, please! --

 

[Thorsten Böttcher]

Am 13.12.2021 um 15:52 schrieb Gerrit Heitsch:

Ich habe eine ähnlich alte von Crucial mit 128 GB. Bis zum Ausbau aus
der Linux-Kiste 2018 hatte ich damit keine Probleme. Jetzt hängt sie
schon eine Weile via USB3 an einem Pi4 welcher davon bootet.

Mit welchem Adapter hast Du die SSD angeschlossen?
Ich wollte das so machen, hab aber tatsächlich Probleme bekommen dass
die Platte nicht sauber lief.
Teilweise hat es garnicht gebootet, manchmal lief es einige Zeit, dann
war die Platte plötzlich weg, und alle so Sachen. Die SSD kann ich
ausschließen, die funktioniert am PC problemlos.

Deswegen läuft das jetzt noch Problemlos mit USB2 und einer alten HDD.

 

[Gerrit Heitsch]

On 12/20/21 11:13 AM, Thorsten Böttcher wrote:

Am 13.12.2021 um 15:52 schrieb Gerrit Heitsch:


Ich habe eine ähnlich alte von Crucial mit 128 GB. Bis zum Ausbau aus
der Linux-Kiste 2018 hatte ich damit keine Probleme. Jetzt hängt sie
schon eine Weile via USB3 an einem Pi4 welcher davon bootet.

Mit welchem Adapter hast Du die SSD angeschlossen?

ICY BOX

IB-AC704-6G

Funktioniert gut. Aber man darf diesen Adapter nur direkt anschliessen,
nicht mit Verlängerungen arbeiten, das scheint er nicht zu mögen. Auf
der anderen Seite passt das kurze Kabel sehr gut zum Pi wenn man die SSD
direkt darunter montiert.

Ich wollte das so machen, hab aber tatsächlich Probleme bekommen dass
die Platte nicht sauber lief.

Ansonsten gibts für manche solche Fälle einen Workaround. Details hier:

https://www.raspberrypi.org/forums/viewtopic.php?t=245931

Gerrit

 

[Thorsten Böttcher]

Am 20.12.2021 um 11:36 schrieb Gerrit Heitsch:

On 12/20/21 11:13 AM, Thorsten Böttcher wrote:
Am 13.12.2021 um 15:52 schrieb Gerrit Heitsch:


Ich habe eine ähnlich alte von Crucial mit 128 GB. Bis zum Ausbau aus
der Linux-Kiste 2018 hatte ich damit keine Probleme. Jetzt hängt sie
schon eine Weile via USB3 an einem Pi4 welcher davon bootet.

Mit welchem Adapter hast Du die SSD angeschlossen?

ICY BOX

IB-AC704-6G

Danke, schaue ich mir mal an.

Funktioniert gut. Aber man darf diesen Adapter nur direkt anschliessen,
nicht mit Verlängerungen arbeiten, das scheint er nicht zu mögen. Auf
der anderen Seite passt das kurze Kabel sehr gut zum Pi wenn man die SSD
direkt darunter montiert.

Das Kabel passt gut, die Platte soll nicht weit weg.

Ich wollte das so machen, hab aber tatsächlich Probleme bekommen dass
die Platte nicht sauber lief.

Ansonsten gibts für manche solche Fälle einen Workaround. Details hier:

https://www.raspberrypi.org/forums/viewtopic.php?t=245931

Danke, das hatte ich probiert, hat aber auch nichts gebracht.

 

[Arno Welzel]

Volker Bartheld:

[...]

Habe ich. Ergebnis von fstrim war, daß (erwartungsgemäß) irgendwas um
die 60GB \"getrimmt\" wurden, d. h. der freie Bereich. Dann wieder Win7
gebootet, klappte einwandfrei. Beim ersten Kopierversuch irgendwas im
Bereich von 250MB/s, was ich bei der Platte an SATA-2 auch erwarte.
Beim zweiten Versuch dann wieder das altbekannte Verhalten, nach
schnellem Start Einbruch der Transferrate auf deutlich unter 100MB/s
bis hin zu 60MB/s.

Und Windows 7 benutzt TRIM nachweislich? Wenn man nur eine HDD
nachträglich durch eine SSD ersetzt, ist das nämlich nicht so.

Prüfen:

fsutil behavior query disabledeletenotify

Da muss dann für die SSDs jeweils zurückkommen:

DisableDeleteNotify = 0

Bei Bedarf kann man TRIM-Unterstützung manuell auch einschalten:

fsutil behavior set DisableDeleteNotify 0

Und ja - das \"0\" für \"TRIM ist aktiv\" steht, ist korrekt so.


--
Arno Welzel
https://arnowelzel.de