Mal ne Frage am Rande - finde dazu leider widersprüchliche Aussagen im Netz.
Wenn man Platten als JBOD zusammenklatscht um ein übergreifendes Volume zu erstellen, fällt dann das ganze Volum aus wenn eine Platte verschwindet oder "fehlen" einfach die Daten der einen Platte?Vg.
Nach meinem Verständnis passiert erst zweiteres, was dann widerum zu ersteren führt. Aber ausprobiert habe ich es noch nie.
Wenn man Platten als JBOD zusammenklatscht um ein übergreifendes Volume zu erstellen, fällt dann das ganze Volum aus wenn eine Platte verschwindet oder "fehlen" einfach die Daten der einen Platte?
Wenn das verwendete Dateisystem nicht irgendeine spezielle Logik für so einen Fall hat, wird wahrscheinlich das Dateisystem irreparabel beschädigt sein. Würde mich wundern, wenn die üblichen Verdächtigen (NTFS, ext4, …) sowas überleben.
Teste es halt mit einem vollen Volume aus und berichte dann 
Würde mich wundern, wenn die üblichen Verdächtigen (NTFS, ext4, …) sowas überleben.
ist eine Frage wie die Platten logisch bedient werden;
bei einem Volumeset und NTFS, wenn es nicht gerade die 1te Platte ist, welche futsch ist, fehlen die Daten einfach;
natürlich sind auch Daten weg, welche nur zum Teil auf der fehlenden Platte sind,
weil der verbleibende Teil auf der Platte davor od. danach auch nicht weiter hilft;
die Frage ist hier eher, wie das OS damit umgeht; ob es sowas wie einen Core Dump od. BSOD wirft, oder doch damit sauber umgehen kann;
Wenn das verwendete Dateisystem nicht irgendeine spezielle Logik für so einen Fall hat, wird wahrscheinlich das Dateisystem irreparabel beschädigt sein. Würde mich wundern, wenn die üblichen Verdächtigen (NTFS, ext4, …) sowas überleben.
Homwer Wenn ich eine 1 GiB Datei mit ext4 formatiere, mit Daten fülle und danach die letzten 512 MiB mit Nullen überschreibe, kann das Dateisystem nicht einmal mehr gemountet werden. Das lässt sich allerdings mit fsck.ext4 wieder beheben, da für den fehlenden Bereich wieder ein "Device" vorhanden ist. Danach mountet das nur noch zu 50% vorhandene Dateisystem einwandfrei und ich kann mich darin bewegen. Der Versuch Dateien zu öffnen, die genau in der zweiten Hälfte der Image-Datei liegen sollten, scheitert still und leise, weil nur Nullzeichen eingelesen werden. Interessanterweise kann ich aber sogar eine ZIP-Datei teilweise erfolgreich entpacken, obwohl ein Teil der enthaltenen Daten auf dem genullten Bereich liegt.
Fazit: ext4 ist doch nicht so blöd, wie ich gedacht habe.
Ich würde mich allerdings trotzdem nicht darauf verlassen, dass bei einem JBOD beim Ausfall einer Platte noch irgendwas lesbar ist. Die Chancen sind zwar je nach Implementierung wahrscheinlich wesentlich höher als bei einem RAID 0 (weil nichts aufgeteilt wird), aber prinzipiell gilt auch hier: Kein Backup, kein Mitleid. Würde ich ansonsten nur mit unwichtigen Testsachen machen, die weg sein dürfen.
"Dumme" JBODs sind so ziemlich die dämlichste Methode Festplatten zusammenzupacken. Man erhöht die Schadenseintrittswahrscheinlichkeit, hat aber keinen Geschwindigkeitsgewinn.
"Dumme" JBODs sind so ziemlich die dämlichste Methode Festplatten zusammenzupacken. Man erhöht die Schadenseintrittswahrscheinlichkeit, hat aber keinen Geschwindigkeitsgewinn.
Ich sehe da afaik auch nur einen Gewinn an Bequemlichkeit, weil ich meine Daten dann nicht händisch über die Platten verteilen muss (quasi dahin, wo gerade Platz ist). Dann doch eher Unraid oder so nen Kram, wenn man aus einer random Kollektion an Festplatten Storage zusammenbasteln möchte.
auf HW Ebene finde ich JBOD angenehmer, dann kann man darunter das RAID mit mdadm/zfs etc. selber machen, kann platten mixen und muss nicht bei einem Crash des Crontrollers den gleichen nochmal haben, bzw. versuchen zu bekommen.
Habe es damals in der PC schmiede heufig gesehen, dass Karten für Kunden wahllos von eBay besorgt wurden, nur damit man den gleichen Chipsatz nochmal bekommt und die Daten lesen kann.
kA ob das immer noch so ist heute, aber habe da einiges gelernt 
JBOD ist der Trick um die Platten einzeln nativ durchzustellen.
Die Controller konnte man doch damals quasi beliebig tauschen, wenn man z.B. konstant auf LSI gesetzt hat. Hab ich da was verpasst?
Habe gerade im SCP festgestellt, dass man nun die Protokolleinträge der Vorbesitzer nicht mehr sieht.
Da wurde wohl inzwischen Datenschutzmäßig nachgebessert. 
auf HW Ebene finde ich JBOD angenehmer, dann kann man darunter das RAID mit mdadm/zfs etc. selber machen, kann platten mixen und muss nicht bei einem Crash des Crontrollers den gleichen nochmal haben, bzw. versuchen zu bekommen.
Da sollten wir evtl mal genauer definieren, was wir unter JBOD verstehen wollen. Darunter kann man imho beides verstehen:
Zweiteres hab ich oben bei meiner Äußerung unter "JBOD" verstanden (quasi die dümmste aller Konfigmöglichkeiten). Ersteres ist heutzutage sogar imho eher besser als Raid Controller, die evtl. Schreibfehler bei der Größe der Festplatten nicht erkennen.
TBT ersteres hat aber mit der Terminology eines JBOD nur eines gemeinsam, dass es nicht um Käsescheiben geht
egal ob es eine Lösung ist, deren Konfig. an das OS durchgereicht wird od. nicht, bei JBOD hat man gegenüber eines Stripesets (auch Raid 0)
ein niedrigeres Risiko ALLE Daten zu verlieren; bei einem Raid 0 ist dies hingegen immer der Fall, sobald eine Platte defekt wird;
TBT ersteres hat aber mit der Terminology eines JBOD nur eines gemeinsam, dass es nicht um Käsescheiben geht
Nö, Wikipedia sieht das so wie ich: https://de.wikipedia.org/wiki/RAID#JBOD . Und dazu zählt auch die erste Definition.
egal ob es eine Lösung ist, deren Konfig. an das OS durchgereicht wird od. nicht, bei JBOD hat man gegenüber eines Stripesets (auch Raid 0)
ein niedrigeres Risiko ALLE Daten zu verlieren; bei einem Raid 0 ist dies hingegen immer der Fall, sobald eine Platte defekt wird;
Da JEGLICHES Datenverlustrisiko bei Ausfall einer HD nicht akzeptabel ist, sind beide Konfigs gleich schlecht. Bei Raid0 hat man immerhin noch hohe Geschwindigkeiten, die man z.B. bei einem Scratchspace beim Videoschnitt (die Rohdaten lagern zusätzlich noch woanders) oder anderen massenspeicherintensiven Anwendungen nutzen kann.
Sonst niemand hier seit 20:15 Probleme mit der Erreichbarkeit seiner Server? 
(Keine Wartungs-/Mail, kein Eintrag auf netcup-status.de, keine Auffälligen Statistiken)
Sonst niemand hier seit 20:15 Probleme mit der Erreichbarkeit seiner Server?
(Keine Wartungs-/Mail, kein Eintrag auf netcup-status.de, keine Auffälligen Statistiken)
Ne bei mir alles gut RS Ostern 22 und Webshoting - beide Deutschland
Nö, Wikipedia sieht das so wie ich: https://de.wikipedia.org/wiki/RAID#JBOD . Und dazu zählt auch die erste Definition.
Leider nicht; deine steht da nirgends; bitte genau sein; JBOD hat mit einem SW Raid nichts zu tun;
ein SW Raid ist nur ein "Raid Controller" f. "Arme", welcher eigentlich nur in Software, diese kann auch Firmware - BIOS, UEFI, ... - abgebildet ist;
Sonst niemand hier seit 20:15 Probleme mit der Erreichbarkeit seiner Server?
(Keine Wartungs-/Mail, kein Eintrag auf netcup-status.de, keine Auffälligen Statistiken)
Keine Ahnung. Montags um 20.15 (bzw. 21:15 hier) läuft Wer wird Millionär und in der Zeit ist das Monitoring deaktiviert :p
Leider nicht; deine steht da nirgends; bitte genau sein; JBOD hat mit einem SW Raid nichts zu tun;
Und das habe ich ja auch nicht behauptet: "Einzelne Platten, z.B. per HBA oder Raid Controller jedoch ohne jegliche Konfiguration, an das OS durchreichen." Beim Text danach gehts darum, was man dann mit diesen einzelnen Platten machen kann.
ein SW Raid ist nur ein "Raid Controller" f. "Arme", welcher eigentlich nur in Software, diese kann auch Firmware - BIOS, UEFI, ... - abgebildet ist;
Andersrum wird ein Schuh draus. Ein "Hardware Raid Controller" ist im Endeffekt auch nur eine Appliance, die im Endeffekt Software Raid auf dem eigenen Chip laufen lässt und damit die CPU (geringfügig) entlastet. Und natürlich meine ich mit Software Raid auch nicht die Fake HW Raids im Bios.
Dinge wie https://de.wikipedia.org/wiki/ZFS_(Dateisystem), lvm und heutige CPU Performance lassen einen Hardware Raid Controller entbehrlich werden und sind in manchen Dingen sogar besser.
Diesen Fehler muss man auch erst einmal finden 
PHP & MySQLi: Verbindung wird mit MYSQLI_CLIENT_SSL einwandfrei aufgebaut. Sobald allerdings mysqli_ssl_set() verwendet wird, um ein Client-Zertifikat anzugeben, wird es lustig…
PHP Warning: mysqli_real_connect(): Cannot connect to MySQL by using SSL
PHP Fatal error: Uncaught mysqli_sql_exception: (trying to connect via (null))Ursache? Der Host bei mysqli_real_connect(): Dieser enthält aus historischen Gründen eine Angabe wie z.B. p:example.net:3306. Offenbar verschluckt sich MySQLi an der Portangabe, wenn mysqli_ssl_set() verwendet wird. Ansonsten wird der Teil ganz normal verarbeitet.
Lösung: Portangabe aus dem Host extrahieren, als eigenständiges Argument übergeben und schon läuft es. 
Bei PHP 7.0 war die Fehlermeldung übrigens noch deutlich aussagekräftiger, da fällt die doppelte Portangabe sofort auf:
PHP Warning: mysqli_real_connect(): Cannot connect to MySQL by using SSL
PHP Warning: mysqli_real_connect(): [2002] (trying to connect via tcp://example.net:3306:3306)
PHP Warning: mysqli_real_connect(): (HY000/2002)Ich werde das morgen mal als Bug melden. Vorher durchstöbere ich noch ein wenig den Quellcode von PHP, wie es dazu kommen kann…
EDIT: Mit MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT funktioniert es trotz Portangabe beim Host. In Wirklichkeit kann er wohl das Zertifikat nicht verifizieren, weil example.net ungleich example.net:3306 ist. Die doppelte Portangabe (example.net:3306:3306) dürfte die MySQL-Libs offenbar gar nicht weiter stören. Leider blicke ich beim Quellcode nicht ganz durch, wo das Problem wirklich ist. Egal, nicht meine Baustelle. Ich melde es mal als Bug…
Dinge wie https://de.wikipedia.org/wiki/ZFS_(Dateisystem), lvm und heutige CPU Performance lassen einen Hardware Raid Controller entbehrlich werden und sind in manchen Dingen sogar besser.
... aber auch nur dann wenn bestimmte Voraussetzungen erfüllt sind; 
Sonst niemand hier seit 20:15 Probleme mit der Erreichbarkeit seiner Server?
Um die Uhrzeit saßen wir auf unserem Teamspeak und hatten keine Probleme Auch ANX84!
