Paritätslaufwerk zu klein trotz identischer Größe

[AndiUCG]

Guten Tag,

 

ich wollte gerade in meinen Server meine Festplatten neu ordnen und eine MX500 4TB als neue Parität einsetzten. Davor wurde eine 4 TB Seagate Ironwolf genutzt. Leider lässt er mich diese Konfiguration einfach nicht übernehmen. Angeblich die die MX500 zu klein. Wenn ich aber in die Infos gehe, haben alle Festplatten exakt 4,000,787,030,016 bytes [4.00 TB]. Ich habe schon probiert die SSD unformatiert zu hinterlegen, vorbereitet als XFS und das selbe auch mit der HDD. Ich bekomme es einfach nicht gestartet. Woran kann das liegen? Übersehe ich etwas?

Andersrum würde es funktionieren. Aber die sind doch beide gleich groß?

 

Ich wäre sehr dankbar für einen Tipp, google hilft mir auch nicht weiter. Ich habe dazu nur etwas gefunden, das die Partition bei einer SSD angeblich bei 2048 bit beginnt, und bei einer HDD bei 64. Mit diesen Infos kam ich aber auch nicht weiter.

[enJOyIT]

Vermutlich liegt das am Alignment der SSD, d.h. die Ausrichtung der Partition. Im Allgemeinen beginnt eine typische mechanische Festplatte ihre erste Partition nach 63 leeren Blöcken, während ein Solid-State-Laufwerk nach 64 leeren Blöcken beginnt. Wenn also die Festplatte nicht ausgerichtet ist, werden die physischen Sektoren und der Cluster verschoben, um genau zu sein, Sie müssen zwei physische 4K-Sektoren für eine Datei in einem Cluster lesen.

 

 

Quelle: https://www.ubackup.com/features/partition-alignment.html

 

Dadurch gehen Blöcke verloren und deshalb wird die nutzbare Größe kleiner gegenüber einer mechanischen Platte sein.

 

Edited April 1, 2023 by enJOyIT

[AndiUCG]

Danke für die Antwort, das klingt sehr plausibel.

 

Ich habe gerade auch entdeckt, dass es generell nicht empfehlenswert ist, eine SSD als Parität zu nutzen. 

 

Mein Hintergrundgedanke dazu war, die Nextcloud Daten auf einer SSD im Array zu speichern, ohne das die HDDs anspringen müssen. Deshalb dann die SSD als Parität. Davor hatte ich einen 2. Cache nur für die Nextcloud Daten, ich denke, ich stelle den Zustand wieder her und lass das array komplett ohne SSDs.

[Ford Prefect]

26 minutes ago, AndiUCG said:

Mein Hintergrundgedanke dazu war, die Nextcloud Daten auf einer SSD im Array zu speichern, ohne das die HDDs anspringen müssen. Deshalb dann die SSD als Parität.

Die Parität speichert keine Daten im eigentlichen Sinne, denn sie hat kein Dateisystem.

Sie sichert nur (eine, im Anlassfall beliebige) Daten-Disk(s) im Array gegen Ausfall, so lange bis diese wieder hergestellt worden ist.

 

29 minutes ago, AndiUCG said:

Davor hatte ich einen 2. Cache nur für die Nextcloud Daten, ich denke, ich stelle den Zustand wieder her und lass das array komplett ohne SSDs.

Das macht meehr Sinn.

Um diese Daten gegen Ausfall abzusichern, analog einer Parität auf dem Array, in dem Pool dann einen Mirror aus zwei (identischen) Disks verwenden. Gerade da machen SSDs Sinn, weil diese wenig Strom verbrauchen, schnell sind und quasi - selbst wenn mal im idle/spindown - kein Spinup Delay haben.

[DataCollector]

39 minutes ago, AndiUCG said:

Ich habe gerade auch entdeckt, dass es generell nicht empfehlenswert ist, eine SSD als Parität zu nutzen. 

Wenn man weiss worauf man sich einlaesst und die SSD dazu kompatibel ist, geht das schon.

 

39 minutes ago, AndiUCG said:

Mein Hintergrundgedanke dazu war, die Nextcloud Daten auf einer SSD im Array zu speichern,

Das würde dann aber 2 SSD im Array bedeuten.

Eine als Parität, und eine für die Daten.

Was spricht dagegen einfach einen Pool für die SSDs zu nehmen?

 

39 minutes ago, AndiUCG said:

ohne das die HDDs anspringen müssen.

Wenn Deine Nextcloud Daten auf dem Pool mit SSD liegen, kann das Array mit Festplatten in Ruhe weiter schlafen.

 

39 minutes ago, AndiUCG said:

Deshalb dann die SSD als Parität. Davor hatte ich einen 2. Cache nur für die Nextcloud Daten, ich denke, ich stelle den Zustand wieder her und lass das array komplett ohne SSDs.

Das ist in aktueller Situation anzuraten.

[AndiUCG]

Ich hatte zuvor einen Pool aus 2 1TB SSDs (eine MX500 und eine WD Blue SA510). Die SA510 scheint aber irgendwie nicht sauber zu laufen, die wirft gelegentlich SMART Fehler und bei der MX500 musste ich einen teil der Überwachung aufgrund eines vermutlichen Firmwarebugs deaktivieren. Insgesamt hatte ich also ein sehr ungutes Gefühl der der Kombination. Da ich noch eine 4TB SSD rumliegen hatte, kam ich auf die Idee, alles ins Array zu werfen und dadurch mir den 2. Pool zu sparen.

 

Ich merke aber nun, das ich vorher eigentlich ganz gut aufgestellt war. Danke nochmal für die Hilfe

 

Ich baue es nun wieder zurück, und schaue einfach mal wie sich das alles weiterhin verhält und was noch für Fehler auftreten. Mir ist z.b. auch häufig der Protokollspeicher überlaufen mit BTRFS Fehlern. Da vermute ich aber, das der RAM nicht wollte. Seitdem der auf Standard 2100Mhz läuft sind die komischerweise weg. Aber das hat nicht mehr mit dem eigentlichen Thema zu tun.

 

Edited April 2, 2023 by AndiUCG