
Fix
Threadstarter
- Dabei seit
- 04.05.2004
- Beiträge
- 989
- Alter
- 33
Hallo zusammen
Seit bald 10 Jahren setze ich zu Hause Raid 5 ein. Bis jetzt weitestgehend ohne Probleme und hauptsächlich am Intel-Controller. Lediglich ein paar Mal wurde nach einem Bios-Update das Raid plötzliche nicht mehr erkannt. Nach einer Neuerstellung des Raid-Arrays liessen sich die Daten bzw. die Partition mit einem Recovery-Tool jeweils (erstaunlicherweise) aber wieder problemlos und vollständig zurückholen. Weiss nicht mehr, wie jeweils genau.
Seit längerer Zeit hatte ich ein 2. Raid 5 an einem HighPoint RocketRaid mit 4 gemischten Festplatten. Auch das war bis anhin völlig problemlos. Jetzt gab es eine Aktion und ich wollte diese 2x 4x 2TB Raid 5 am Intel- und RR-Controller durch ein einziges mit 4x 4TB 2.5"-HDDs ersetzen. Das ging jedoch nicht annähernd so problemlos wie die letzten knapp 10 Jahre mit allen bisherigen Disks.
Die neuen Disks sind Seagate Barracuda (Compute) 4 TB 2.5" HDDs, die nach dem SMR-Verfahren arbeiten, um diese Datendichte zu erreichen. Alle stammen aus externen USB 3-Gehäusen, da diese in Aktion sogar billiger waren als vergleichbare, interne 3.5" HDDs.
Jetzt dazu einmal ein paar allgemeine Fragen:
Zuerst wollte ich eruieren, ob die Performance am Intel- oder am RR-Controller besser ist. Das hat sich relativ schnell erledigt. Die Disks sind im R5 am Intel-Controller nicht zu verwenden. Sie laufen bedeutend schlechter als einzeln und es geht sogar so weit, dass sich mehrfach das ganze "Speicher-Management" von Windows beim Datentransfer aufgehängt hat und ich nur noch den Computer neu starten konnte, um weitermachen zu können. Also habe ich sie an den RR-Controller gehängt. Dort schienen sie normal zu funktionieren.
Habe dann alle Daten von den bisherigen Disks darauf kopiert, was auch problemlos ging. Allerdings waren nach ein paar Tagen die meisten Ordner nicht mehr zugreifbar. Nach einem Reboot war das ganze Volume nicht mehr zugreifbar und auch eine Überprüfung oder Reparatur vom Dateisystem war nicht mehr möglich. Im Management wurde der Array-Status jedoch als "normal" angezeigt.
Ich habe im Event-Log per Zufall gesehen, dass da mehrfach etwas stand von "Volume F: aufgrund von Fehlern kurrzeitig offline geschaltet" und irgendetwas von "ESENT", was ich nicht weiss, ob das etwas damit zu tun hat. Mögliche mir bekannte Ursachen könnten höchstens sein, dass ich den PC das ein oder andere Mal resetten musste, weil sich GPU (-Treiber) aufgehängt hatten oder weil ich die Reihenfolge von zwei Disks einmal getauscht hatte, wobei 2. ja eigentlich kein Problem sein dürfte und 1. auch nicht, da in der Zeit ja keine Festplattenzugriffe hätten stattfinden dürfen. Oder sind diese (SMR-) Disks schlicht und einfach aus mir unbekannten Gründen für ein Raid (5) nicht zu verwenden? Das wäre sehr mühsam und schade!
Leider weiss ich nicht, wann es genau aufgehört hat zu funktionieren (in der kurzen Zeit) und bin mir auch nicht sicher, ob ich bei den vorherigen Disks die Reihenfolge auch schon getauscht hatte. Gehe schwer davon aus. Beim Intel-Controller weiss ich's, dass ich das mehrfach gemacht habe und es nie ein Problem war.
Was ich noch weiss ist, dass ich davor mal eine Prüfung und Reparatur vom FS ausgeführt hatte (nach den Resets?). Allerdings weiss ich nicht, ob auch auf dem Raid-Volume oder nur auf der System-Partition. Und das kam mir schon äusserst merkwürdig vor, da ich das System erst kürzlich mit dem Fall Creators Update frisch installieren "durfte" und der PC bis da ja nicht mehrfach abgestürzt ist wie früher teilweise.
Kann ich mich bei der Reparatur vom FS darauf verlassen, dass das danach passt und nicht mehr irgendwelche Ungereimtheiten vorhanden sind?
Auf jeden Fall habe ich die Disks danach einzeln geprüft über die Management-GUI des Controllers, was mehr als ca. 4x 1/3 Tag dauerte. Auf was (alles) genau kann ich nicht einmal sagen aber zumindest sollen keine fehlerhaften Sektoren vorhanden sein.
Gestern hatte ich beim "normalen" Raid 5 einmal auf Verify gedrückt. Da hat er sofort Inkonsistenzen auf den Disks festgestellt und mit dem Rebuild begonnen. Weiss nicht, ob ich jetzt die 200h (!) warten soll, nur um festzustellen, ob das Ganze Erfolg hat oder ob der Controller irgendwelche konkrete Fehler ausgibt oder ob es keine Fehler gibt und am Ende trotzdem nichts geht. Mir scheint, bei einem Defekt allfällige Daten vom Volume zu sichern und das Ganze dann neu zu kreieren und zurückzuspielen oder gleich neu zu kreieren und wieder drauf zu kopieren wäre ohnehin bedeutend schneller und allenfalls sicherer und aussichtsreicher als so ein ewig dauernder Rebuild.
Ich hatte früher bei den vorherigen Disks mal auf Verify gedrückt interessehalber. Ging auch lange (weiss jetzt nicht ob halb so lange wegen der Kapazität oder weniger) aber da ging alles glatt, ohne Fehler o. Ä.
Habe mir auch schon mehrfach ein SW-Raid über Windows überlegt, um Controller-unabhängig zu sein. Allerdings kenne ich mir damit 0 aus und finde bei Google auch nichts, was meine Fragen beantwortet.
Was passiert bei einer Neuinstallation des OS oder bei Umzug auf einen neuen PC? Sind da alle nötigen Infos direkt auf den Disks, so dass Windows das SW-Raid sofort wieder als solches erkennt und wie ist es da mit der Disk-Reihenfolge, Sicherheit und Zuverlässigkeit?
Danke für's Durchlesen des langen Beitrags und hoffentlich einigen hilfreichen und aufklärenden Antworten!
mfg
Seit bald 10 Jahren setze ich zu Hause Raid 5 ein. Bis jetzt weitestgehend ohne Probleme und hauptsächlich am Intel-Controller. Lediglich ein paar Mal wurde nach einem Bios-Update das Raid plötzliche nicht mehr erkannt. Nach einer Neuerstellung des Raid-Arrays liessen sich die Daten bzw. die Partition mit einem Recovery-Tool jeweils (erstaunlicherweise) aber wieder problemlos und vollständig zurückholen. Weiss nicht mehr, wie jeweils genau.
Seit längerer Zeit hatte ich ein 2. Raid 5 an einem HighPoint RocketRaid mit 4 gemischten Festplatten. Auch das war bis anhin völlig problemlos. Jetzt gab es eine Aktion und ich wollte diese 2x 4x 2TB Raid 5 am Intel- und RR-Controller durch ein einziges mit 4x 4TB 2.5"-HDDs ersetzen. Das ging jedoch nicht annähernd so problemlos wie die letzten knapp 10 Jahre mit allen bisherigen Disks.
Die neuen Disks sind Seagate Barracuda (Compute) 4 TB 2.5" HDDs, die nach dem SMR-Verfahren arbeiten, um diese Datendichte zu erreichen. Alle stammen aus externen USB 3-Gehäusen, da diese in Aktion sogar billiger waren als vergleichbare, interne 3.5" HDDs.
Jetzt dazu einmal ein paar allgemeine Fragen:
- Wieso wird bei den meisten HDDs keine Zugriffszeit mehr angegeben? Das ist doch DER Faktor, der die HDDs bei nicht sequentiellen Zugriffen so langsam macht...!?
- Write Back-Caching ist ja "gefährlich" bezüglich Stromausfall. Jetzt arbeiten die SMR-Disks intern ja neben dem eigentlichen Cache nach einem ähnlichen Verfahren: Daten werden u. U. zuerst in einen Cache-Bereich auf der Platte geschrieben und später bei Langeweile erst richtig in den Datenbereich zurückgeschrieben. Im Gegensatz zum Chip-Cache ist dieser jedoch nicht flüchtig und ich gehe davon aus, dass der Controller das handeln muss, wenn in dieser Zeit der Strom ausfällt, der PC abstürzt, ausgeschaltet oder neu gestartet wird...!?
- Haben HDDs aus einem externen Gehäuse eine manipulierte Firmware bzw. unterscheiden sie sich in irgendeiner Weise von den "normalen", internen Disks, so dass sich diese nicht problemlos intern an SATA betreiben lassen? Kann das leider nicht nachvollziehen, da sich nicht nach Modell- sondern nur nach Seriennummer nach FW-Updates suchen lässt.
Zuerst wollte ich eruieren, ob die Performance am Intel- oder am RR-Controller besser ist. Das hat sich relativ schnell erledigt. Die Disks sind im R5 am Intel-Controller nicht zu verwenden. Sie laufen bedeutend schlechter als einzeln und es geht sogar so weit, dass sich mehrfach das ganze "Speicher-Management" von Windows beim Datentransfer aufgehängt hat und ich nur noch den Computer neu starten konnte, um weitermachen zu können. Also habe ich sie an den RR-Controller gehängt. Dort schienen sie normal zu funktionieren.
Habe dann alle Daten von den bisherigen Disks darauf kopiert, was auch problemlos ging. Allerdings waren nach ein paar Tagen die meisten Ordner nicht mehr zugreifbar. Nach einem Reboot war das ganze Volume nicht mehr zugreifbar und auch eine Überprüfung oder Reparatur vom Dateisystem war nicht mehr möglich. Im Management wurde der Array-Status jedoch als "normal" angezeigt.
Ich habe im Event-Log per Zufall gesehen, dass da mehrfach etwas stand von "Volume F: aufgrund von Fehlern kurrzeitig offline geschaltet" und irgendetwas von "ESENT", was ich nicht weiss, ob das etwas damit zu tun hat. Mögliche mir bekannte Ursachen könnten höchstens sein, dass ich den PC das ein oder andere Mal resetten musste, weil sich GPU (-Treiber) aufgehängt hatten oder weil ich die Reihenfolge von zwei Disks einmal getauscht hatte, wobei 2. ja eigentlich kein Problem sein dürfte und 1. auch nicht, da in der Zeit ja keine Festplattenzugriffe hätten stattfinden dürfen. Oder sind diese (SMR-) Disks schlicht und einfach aus mir unbekannten Gründen für ein Raid (5) nicht zu verwenden? Das wäre sehr mühsam und schade!
Leider weiss ich nicht, wann es genau aufgehört hat zu funktionieren (in der kurzen Zeit) und bin mir auch nicht sicher, ob ich bei den vorherigen Disks die Reihenfolge auch schon getauscht hatte. Gehe schwer davon aus. Beim Intel-Controller weiss ich's, dass ich das mehrfach gemacht habe und es nie ein Problem war.
Was ich noch weiss ist, dass ich davor mal eine Prüfung und Reparatur vom FS ausgeführt hatte (nach den Resets?). Allerdings weiss ich nicht, ob auch auf dem Raid-Volume oder nur auf der System-Partition. Und das kam mir schon äusserst merkwürdig vor, da ich das System erst kürzlich mit dem Fall Creators Update frisch installieren "durfte" und der PC bis da ja nicht mehrfach abgestürzt ist wie früher teilweise.
Kann ich mich bei der Reparatur vom FS darauf verlassen, dass das danach passt und nicht mehr irgendwelche Ungereimtheiten vorhanden sind?
Auf jeden Fall habe ich die Disks danach einzeln geprüft über die Management-GUI des Controllers, was mehr als ca. 4x 1/3 Tag dauerte. Auf was (alles) genau kann ich nicht einmal sagen aber zumindest sollen keine fehlerhaften Sektoren vorhanden sein.
Gestern hatte ich beim "normalen" Raid 5 einmal auf Verify gedrückt. Da hat er sofort Inkonsistenzen auf den Disks festgestellt und mit dem Rebuild begonnen. Weiss nicht, ob ich jetzt die 200h (!) warten soll, nur um festzustellen, ob das Ganze Erfolg hat oder ob der Controller irgendwelche konkrete Fehler ausgibt oder ob es keine Fehler gibt und am Ende trotzdem nichts geht. Mir scheint, bei einem Defekt allfällige Daten vom Volume zu sichern und das Ganze dann neu zu kreieren und zurückzuspielen oder gleich neu zu kreieren und wieder drauf zu kopieren wäre ohnehin bedeutend schneller und allenfalls sicherer und aussichtsreicher als so ein ewig dauernder Rebuild.
Ich hatte früher bei den vorherigen Disks mal auf Verify gedrückt interessehalber. Ging auch lange (weiss jetzt nicht ob halb so lange wegen der Kapazität oder weniger) aber da ging alles glatt, ohne Fehler o. Ä.
Habe mir auch schon mehrfach ein SW-Raid über Windows überlegt, um Controller-unabhängig zu sein. Allerdings kenne ich mir damit 0 aus und finde bei Google auch nichts, was meine Fragen beantwortet.
Was passiert bei einer Neuinstallation des OS oder bei Umzug auf einen neuen PC? Sind da alle nötigen Infos direkt auf den Disks, so dass Windows das SW-Raid sofort wieder als solches erkennt und wie ist es da mit der Disk-Reihenfolge, Sicherheit und Zuverlässigkeit?
Danke für's Durchlesen des langen Beitrags und hoffentlich einigen hilfreichen und aufklärenden Antworten!
mfg