SCSI RAID noch was zu retten?

Chregu schrieb:
> WIE BITTE ?!?!?!?
>
> Dieser Heini gehört standesrechlich erschossen!

Nö. Er hat nur die Rechnung des Datenrettungsunternehmens zu bezahlen.

Chregu schrieb:

> Dieser Heini gehört standesrechlich erschossen!

Vor dem Todesurteil würde ich zunächst die Umstände abklären. 
Besteht/bestand ein Wartungsvertrag? Wer ist für die Datensicherung 
verantwortlich, der Dienstleister oder die Firma selbst? Wurde der 
Dienstleister beauftragt, die Platte zu tauschen oder hat man vielleicht 
aus Kostengründen nur gesagt "Stell den Lärm ab."?

Zum Thema:
Sofern die Platten als RAID1 verschaltet waren, lassen sie sich auch 
einzeln auslesen. Sofern der Controller noch i.O. ist, in einen 
funktionierenden PC stecken, Platte anstöpseln und schauen, was noch 
drauf ist. Sollte das Dateisystem Fehler haben, dann UNBEDINGT VOR 
jeglichen Reparaturversuchen eine sektorgetreue Kopie auf eine zweite 
Platte oder in ein Image anfertigen.

Peter II schrieb:

> lassen sich mit jeden andere Kontroller aber auch auslesen.

Nicht unbedingt. Bei SCSI-Controllern anderer Hersteller werden u.U. 
abweichende Plattengeometrien verwendet und dann funktioniert das nicht. 
Wenn Ersatz, dann möglichst baugleich, mindestens aber auch ein Adaptec.

Peter II schrieb:

> scsi ist doch schon Blockorigentiert - der controller hat doch gar
> keinen einfluss auf die Goemetrie wie bei IDE.

Er hat keinen Einfluß auf die interne Geometrie der Platte, richtig. 
Aber es ist dem Controller überlassen, wie er die Blöcke mappt. Und da 
gibt es sehr wohl Unterschiede. Die gibt es sogar bei IDE/SATA. Bestes 
Beispiel sind die IBM Thinkpads, die abweichend vom Rest der Welt mit 
240 statt 255 Köpfen arbeiten. Eine im Thinkpad formatierte Platte 
funktioniert nicht im normalen PC oder umgekehrt. Alles praktisch 
erlebt.

http://www.dawicontrol.de/index.php?cmd=faqdet&id=1#a39

3. Frage von unten "Ich hatte vorher einen anderen Hostadapter in meinem 
Rechner"

Peter II schrieb:

> Ich kann mir immer noch nicht vorstellen wie das überhaupt gehen soll,

Unabhängig von deiner Vorstellungskraft ist es eine praktische Tatsache, 
daß nach einem Controllerwechsel u.U. nicht mehr auf die Daten 
zugegriffen werden kann. Warum genau, kann ich dir auch nicht sagen, da 
mußt du die Hersteller und Treiberprogrammierer fragen, die schreiben 
das ja nicht ohne Grund in ihre FAQ. Mir ist es als frischgebackenem 
Servicetechniker selbst passiert. Novell-Server, Futuredomain-Controller 
raus, Adaptec rein. Zunächst scheinbar alles OK. Beim Speichern der 
ersten Datei Fehlermeldung und Volume korrupt. Datensicherung vorhanden, 
die Rücksicherung dauerte dank der damals üblichen Floppystreamer aber 
die halbe Nacht.

Icke ®. schrieb:
> Mir ist es als frischgebackenem
> Servicetechniker selbst passiert.

Wobei ich mir nicht sicher bin, ob diese Probleme heute noch aktuell 
sind. Die von dir beschriebenen Systeme könnten noch von der früher 
systemweit teilweise üblichen CHS-Adressierung geprägt sein, auch wenn 
das SCSI Protokoll seit jeher mit LBA arbeitete, während heute anfangend 
mit dem BIOS und der Partitionierung ziemlich durchgängig auch bei SATA 
die LBA-Adressierung vorherrscht.

Peter II schrieb:

> also wenn das system noch bootet dann stimmem die Festplattensektoren.

Es bootet auch, wenn Partitionsanfang, Bootsektor und Systemdateien noch 
da liegen, wo sie erwartet werden. Das Ende der Boot-Partition bzw. 
Anfang/Ende anderer Partitionen kann aber dennoch wo ganz anders sein. 
Novell 3.x startet von einer DOS-Partition, das Datenvolume hat eine 
eigene.

A. K. schrieb:

> Wobei ich mir nicht sicher bin, ob diese Probleme heute noch aktuell
> sind. Die von dir beschriebenen Systeme könnten noch von der früher
> systemweit teilweise üblichen CHS-Adressierung geprägt sein, auch wenn
> das SCSI Protokoll seit jeher mit LBA arbeitete

Genau. Das Blockmapping wurde schon immer (und wird noch) vom 
Controller-BIOS bzw. vom Treiber verwaltet.
Ich habe mir seitdem jegliche Experimente verkniffen, aber da die 
Problematik in den aktuellen FAQ enthalten ist, scheint das Problem 
durchaus noch existent.

Peter II schrieb:

> nein ebend nicht. Es gibt kein Mapping mehr weil gar nicht mehr
> umgerechnet werden muss.
>
> Ich habe SCSCI platten an den verschiendensten kontroller und dabei
> konnte ich immer alle Daten lesen.

http://www.heise.de/ct/hotline/Mapping-bei-SCSI-Platten-303570.html

Kann gut sein, daß es zwischenzeitlich funktioniert. Ich würde dennoch 
keinen Controller eines anderen Herstellers verwenden, weil man bei 
Lesefehlern nicht nachvollziehen kann, ob das Problem nun von einem 
defekten Dateisystem oder vielleicht doch vom Controller verursacht 
wird.

> Bei SATA Festpatte sind durch eSATA eh zu jeden PC kompatibel.
>
> Deine Problem kann also nur bei IDE und der CHS Adressesierung auftreten
> die aber seit viele Jahren nicht mehr verwendert wird.

Solange sich die Hersteller an de facto Standards halten, was fast alle 
tun, gibt es kein Problem. Die Thinkpads machen da eine Ausnahme. 
Praktisches Beispiel: Kunde möchte eine größere Festplatte. Übliches 
Vorgehen, neue Platte mittels USB-Adapter angesteckt, mit Acronis 
geklont, alte Platte raus, neue rein. Funktioniert sonst immer. Nicht im 
Fall eines Thinkpad R61. Gerät bootet mit der geklonten neuen Platte 
nicht. Nach ausgiebiger Recherche erweist sich die vom Thinkpad benutzte 
Geometrie mit 240 Heads als Ursache, weil bei Anschluß über den 
USB-Adapter mit 255 adressiert wird. Abhilfe brachte der Zwischenschritt 
über ein Image, also alte Platte -> Image, neue Platte rein, Image -> 
neue Platte. Siehe auch:

http://forum.thinkpads.com/viewtopic.php?f=5&t=91802

Peter II schrieb:
> Icke ®. schrieb:
>> Siehe auch:
>>
>> http://forum.thinkpads.com/viewtopic.php?f=5&t=91802
>
> Samsung HM160HC (160GB 2.5" PATA).
>
> genau was wir gesagt haben: IDE -Festplatte, dort wurde CHS
> andressierung gemacht (konnte man bei einigen im Bios manuell
> einstellen)
>
> Bei SCSCI und SATA gibt es das aber nicht mehr.

Der Link ist nur ein Beispiel. Bei dem von mir beschriebenen Fall 
handelte es sich um ein Thinkpad R61 mit S-ATA Platten.

Im Anhang ein Screenshot von meinem R60 mit OCZ Vertex SDD (S-ATA). Auch 
Testdisk kommt mit den 240 Heads nicht klar, sondern erwartet 255. Das 
Notebook und Win7 laufen aber problemlos damit, das kann ich dir 
versichern.

Sorry für die miese Bildqualität, Handyfoto.

Peter II schrieb:
> dann verwendest du zu alte Tools

Testdisk V6.12, also fast neu.

- bei SATA gibt ein keine Heads mehr.

S-ATA an sich beschreibt zunächst nur die physikalische Schnittstelle, 
welche sich von parallelem Bus auf seriell Punkt-zu-Punkt geändert hat. 
Mit der Adressierung hat das erst mal nix zu tun. Im Gegensatz zu P-ATA 
kann S-ATA aber im Enhanced Mode betrieben werden, wodurch es sich 
gegenüber dem OS nicht als ATAPI-Device, sondern ähnlich wie SCSI als 
Massenspeicher-Controller zu erkennen gibt. Im Compatible-Mode verhält 
es sich wie ein klassisches IDE-Device. Irgendetwas ist bei den 
Thinkpads definitiv anders, denn sowohl das R61 als auch mein R60 sind 
auf AHCI eingestellt. Das Phänomen ist mit bisher auch ausschließlich 
bei Thinkpads untergekommen.

Peter II schrieb:

> Die Festplatte ist 64Gbyte gross, also auf jeden fall kein aktuelles
> modell. Eventuell haben sie einen IDE-SATA adapter verbaut.

Die Festplatte ist eine ~1,5 Jahre alte SSD OCZ Vertex2. Sie steckt 
direkt in MEINEM Thinkpad R60. Typ und Größe der Festplatte spielen auch 
keine Rolle, mit jeder beliebigen anderen sähe es genauso aus (die neue 
im R61 war eine klassische 320GB Hitachi).

Wenn Icke nicht mit etlichen Aliasnamen in diversen Foren unterwegs ist, 
dann scheint seine Aussage zuzutreffen, dass Festplattenklone unabhängig 
vom verwendeten Programm bei Thinkpads nur dann funktionieren, wenn das 
Ziel des Klons im Thinkpad steckt. Immerhin ist es kein Problem, einen 
BIOS-Bootloader so zu schreiben, dass er nur mit 240-er Disks 
funktioniert. Ob das nun ein Fehler, steinzeitliche BIOS-Schnipsel oder 
Absicht ist darf sich jeder selber ausmalen.

Obwohl CHS-Adressierung aus der Mode gekommen ist stecken Restbestände 
davon bis heute in der althergebrachten Partitionierungsinformation 
drin. Man muss die nicht nutzen, da auch LBA-Info dort steht, aber man 
kann.

Was aber, wenn sich Lenovo/IBM nicht an diese Konvention gehalten haben?

Wo ist diese Konvention so festgeschrieben, dass daraus ein 
Rechtsanspruch des Kunden entsteht? Wikipedia wird dazu kaum ausreichen.

Peter II schrieb:
> dann ist das gerät fehlerhaft

Warum?  Weil sie nicht der "Spec" des deutschen Wikipedia-Eintrags
entsprechen?

Wiederum laut Wikipedia scheint Intel das in EFI reingeschrieben zu 
haben. Was freilich erst relevant wird, wenn der Hersteller ebendies 
oder UEFI auch verwendet.

Die 128GB Grenze besteht zwischen LBA28 und LBA48. Die ist hier nicht 
relevant. Das klassische CHS war bereits bei 8GB am Ende.

Sicher nicht, denn LBA kam erst mit ATA auf und damit hatte IBM nichts 
zu tun.

In S-ATA 1.0 habe ich auf die Schnelle nichts dazu gefunden.

Eine ATA Referenz von 2000 (Draft) enthält zwar einige Seiten über die 
CHS/LBA-Translation, schreibt aber kein bestimmtes Rechenschema vor.

Ich tippe eher darauf, dass eine konkrete LBA/CHS-Translation vor EFI 
nicht formal vorgeschrieben ist, sondern dass es sich lediglich um eine 
verbreitete weil naheliegende Konvention handelt.

Yep, das wäre möglich. Bisschen fies, aber zulässig.

Peter II schrieb:
> zeigt doch mal bitte fdisk von linux von der Festplatte

Bitteschön. Sorry again for poor quality.

Peter II schrieb:

> Bei deinem Testdisk steht bei Head 255 da, bei linux 240. Da linux keine
> Fehler anzeigt wird es wohl ein Problem bei dem Testdisk sein, er
> ermittel die falsche anzahl von Heads.

Sag ich doch, siehe oben. Testdisk erkennt zwar, daß da 240 Köpfe sind, 
hält das aber für falsch.

Peter II schrieb:

> nein andersrum. Testdisk behauptet das die Festplatte 255 Heads hat.
> (CHS 7783 255 63)

Meinetwegen. Egal wie rum, es sollte ohnehin nur als Beispiel dienen, 
daß die Geometrie nicht immer standardkonform sein muß. Blöd, wenn man 
dann Reparaturtools drüber laufen läßt, die das nicht mitkriegen.

Peter II schrieb:
> Laut linux hat sie aber nur 240.

Und real vermutlich nur 2. :-)

Peter II schrieb:
> Jörg Wunsch schrieb:
>> Und real vermutlich nur 2. :-)
>
> Nee 0 - ist eine SSD

5 Punkte für dich. ;-)

huz schrieb:
> Toller screenshot von fdisk.
> Kann man das nicht in eine Datei umleiten?

'türlich kann man. Da hätte ich in der live-Shell aber erst wieder einen 
Stick mounten und mir die Syntaxen man-en müssen usw. =:P

testdisk versteht die Parameter /log und /debug.

abc schrieb:

> Wozu brauchst du für eine Umlenkung mit ">" in eine Datei eine man-page?

Wie leitet man innerhalb von fdisk die mit "p" erzeugte Ausgabe in eine 
Datei um? Reicht da ein simples ">"?

Wie ist die korrekte Syntax, um in der Shell einen USB-Stick writeable 
zu mounten (Linux von einfacher Debian CD gestartet, kein GUI)?

Wenn man nicht jeden Tag mit Linux umgeht, muß man schon in die 
man-Files schauen. Und nein, ich werde mich dafür weder schämen, noch 
rechtfertigen.

Icke ®. schrieb:

> Wie leitet man innerhalb von fdisk die mit "p" erzeugte Ausgabe in eine
> Datei um? Reicht da ein simples ">"?

sfdisk -Ggl /dev/unsinn >suchsesdiraus
-G: Geometrie aus Partitionstabelle
-g: Geometrie laut Kernel
-l: Partitionstabelle

> Wie ist die korrekte Syntax, um in der Shell einen USB-Stick writeable
> zu mounten (Linux von einfacher Debian CD gestartet, kein GUI)?

Nicht partitionierter Stick:
mount /dev/sde /mnt

Partitionierter Stick:
mount /dev/sde1 /mnt

Danke. Um das herauszufinden, hätte ich bestimmt 10 Minuten gebraucht. 
Abfotografiert wars in einer.

Icke ®. schrieb:
> Danke. Um das herauszufinden, hätte ich bestimmt 10 Minuten gebraucht.

Merk dir fürs nächste Mal das T-Stück: "tee".

1

fdisk | tee logfile

Danach kannst du dein fdisk ganz normal interaktiv bedienen, aber
das T-Stück zweigt vom Rohr (also der Pipe) noch eine Kopie nach
"logfile" ab.

Jörg Wunsch schrieb:

> Merk dir fürs nächste Mal das T-Stück: "tee".

Mach ich, das ist nützlich.