Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #223335 > unrolled thread

Nochmal RAIDereien. Oder eher NASen?

Back to article view | Back to ger.ct

Contents

  Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-28 15:56 +0200
    Re: Nochmal RAIDereien. Oder eher NASen? Matthias Eißing <meissing@gmx.de> - 2015-09-28 17:36 +0200
      Re: Nochmal RAIDereien. Oder eher NASen? Günter Frenz <usenet-01@guefz.de> - 2015-09-28 19:08 +0200
        Re: Nochmal RAIDereien. Oder eher NASen? "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-29 05:57 +0000
          Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 10:04 +0200
            Re: Nochmal RAIDereien. Oder eher NASen? "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-29 08:28 +0000
            Re: Nochmal RAIDereien. Oder eher NASen? Matthias Eißing <meissing@gmx.de> - 2015-09-29 11:17 +0200
              Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 11:34 +0200
                Re: Nochmal RAIDereien. Oder eher NASen? Matthias Eißing <meissing@gmx.de> - 2015-09-29 12:05 +0200
                  Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 13:47 +0200
              Re: Nochmal RAIDereien. Oder eher NASen? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-29 16:27 +0200
                Re: Nochmal RAIDereien. Oder eher NASen? Matthias Eißing <meissing@gmx.de> - 2015-09-29 17:20 +0200
                  Re: Nochmal RAIDereien. Oder eher NASen? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-29 19:06 +0200
                    Re: Nochmal RAIDereien. Oder eher NASen? Matthias Eißing <meissing@gmx.de> - 2015-09-30 07:56 +0200
                      Re: Nochmal RAIDereien. Oder eher NASen? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-30 18:00 +0200
                        Re: Nochmal RAIDereien. Oder eher NASen? spamfalle2@arcor.de (Marc Stibane) - 2015-10-02 20:26 +0200
                          Re: Nochmal RAIDereien. Oder eher NASen? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-10-02 20:39 +0200
                          Re: Nochmal RAIDereien. Oder eher NASen? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-10-03 18:05 +0200
                            Re: Nochmal RAIDereien. Oder eher NASen? spamfalle2@arcor.de (Marc Stibane) - 2015-10-03 20:20 +0200
                              Re: Nochmal RAIDereien. Oder eher NASen? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2015-10-03 20:26 +0200
                                Re: Nochmal RAIDereien. Oder eher NASen? spamfalle2@arcor.de (Marc Stibane) - 2015-10-04 08:27 +0200
              Re: Nochmal RAIDereien. Oder eher NASen? Mike Grantz <beatclubs@stoiseland.de> - 2015-09-30 05:57 +0200
        Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 09:17 +0200
          Re: Nochmal RAIDereien. Oder eher NASen? Günter Frenz <usenet-01@guefz.de> - 2015-09-29 20:17 +0200
            Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-30 09:17 +0200
              Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-30 10:37 +0200
                Re: Nochmal RAIDereien. Oder eher NASen? Günter Frenz <usenet-01@guefz.de> - 2015-09-30 16:48 +0200
                  Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-10-01 09:35 +0200
                    Re: Nochmal RAIDereien. Oder eher NASen? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-10-01 12:26 +0200
              Re: Nochmal RAIDereien. Oder eher NASen? Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2015-09-30 18:26 +0200
      Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 08:58 +0200
    Re: Nochmal RAIDereien. Oder eher NASen? "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-29 05:44 +0000
      Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 08:39 +0200
        Re: Nochmal RAIDereien. Oder eher NASen? "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-29 08:11 +0000
          Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 10:30 +0200
      Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 10:23 +0200
        Re: Nochmal RAIDereien. Oder eher NASen? Shinji Ikari <shinji@gmx.net> - 2015-09-29 13:04 +0200
          Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 13:37 +0200
    Re: Nochmal RAIDereien. Oder eher NASen? Shinji Ikari <shinji@gmx.net> - 2015-09-29 08:31 +0200
      Re: Nochmal RAIDereien. Oder eher NASen? "Juergen P. Meier" <nospam-1984@jors.net> - 2015-09-29 08:23 +0000
      Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 10:17 +0200
      Re: Nochmal RAIDereien. Oder eher NASen? Shinji Ikari <shinji@gmx.net> - 2015-09-29 13:09 +0200
        Re: Nochmal RAIDereien. Oder eher NASen? "Ulrich F. Heidenreich" <from!not-for-mail@tremornet.de> - 2015-09-29 13:39 +0200

Page 1 of 3  [1] 2 3  Next page →

#223335 — Nochmal RAIDereien. Oder eher NASen?

Guten Morgen!

Derweil sind meine beiden 8-Bay-NASen eingetroffen, das nichtleere
bestückt übrigens mit Toshiba statt wie vermutet Seagate. Der Aufbau 
des RAID6 war in einer guten Stunde erledigt; wie lahm mögen dann die
Seagate Archives sein, wenn es laut unserer japanischer Comicfigur bei
ihm eine Woche dauerte, ein RAID aufzubauen?

Interessant sind jetzt auch noch die Kopierzeiten: 
4-Bay-RAID5 -> 8-Bay-RAID6: Eine gute Woche.   
8-Bay-RAID6 -> 8-Bay-RAID6: Gut zwei Tage.

Da dachte ich mir immer, bei NAS spielte die Nettzwergschnittstelle 
und die Plattengeschwindigkeit die tragenden Rolle. Offensichtlich
(augenscheinlich?) aber wohl eher Prozessorleistung und Speicher:

Das 4-Bay-NAS hat eine Marvell 6281 CPU mit 1.2 GHz und 256 MB RAM;
im 8-Bay-NAS läuft ein Intel Celeron mit 2.4 GHz und 4 GByte RAM im
Rücken.

Bei NAS der Flaschenhals die Systemleistung und weniger Platten
/Schnittstelle?

CU!
Ulrich
-- 
Newton ist tot, Einstein ist tot 
und mir wird auch schon ganz schlecht ... 

[toc] | [next] | [standalone]

#223350

Am 28.09.15 um 15:56 schrieb Ulrich F. Heidenreich:
> Bei NAS der Flaschenhals die Systemleistung und weniger Platten
> /Schnittstelle?

Ja

RAID 5/6 sind rechenintensiv.... das geht die Performance bei 
Marvell-Chips schnell in den Keller.

-- 
cu://Matthias.Eißing.de

[toc] | [prev] | [next] | [standalone]

#223364

Am Mon, 28 Sep 2015 17:36:57 +0200 schrieb Matthias Eißing:

> Am 28.09.15 um 15:56 schrieb Ulrich F. Heidenreich:
> > Bei NAS der Flaschenhals die Systemleistung und weniger Platten
> > /Schnittstelle?
> 
> Ja
> 
> RAID 5/6 sind rechenintensiv.... 

beim Lesen von vermutlich intakten Daten?

Günter

[toc] | [prev] | [next] | [standalone]

#223425

to Günter Frenz <usenet-01@guefz.de>:
> Am Mon, 28 Sep 2015 17:36:57 +0200 schrieb Matthias Eißing:
>
>> Am 28.09.15 um 15:56 schrieb Ulrich F. Heidenreich:
>> > Bei NAS der Flaschenhals die Systemleistung und weniger Platten
>> > /Schnittstelle?
>> 
>> Ja
>> 
>> RAID 5/6 sind rechenintensiv.... 
>
> beim Lesen von vermutlich intakten Daten?

*sigh*.

Noch jemand, der das mit der Datensicherheit bei RAID nicht verstanden
hat.

Ein RAID-Controller darf nicht einfach vermuten, dass die Daten
intakt sind.

Er muss es *kontrollieren*. Am besten Regelmaessig. Das kostet
performance, das kostet Zeit und das will kein dummer Pfennigfuchser
der sich das billigste Soho-NAS vom Mediamarktwuehltisch geschnappt
hat.

Sonst hast du auch bei RAID-6 nach einem schleichenden Tripple-Fehler
alle Daten verloren.

[toc] | [prev] | [next] | [standalone]

#223442

Juergen P. Meier in <news:34664.2284.1443506238@news.jors.net>:

>to Günter Frenz <usenet-01@guefz.de>:
>> Am Mon, 28 Sep 2015 17:36:57 +0200 schrieb Matthias Eißing:
>
>>> RAID 5/6 sind rechenintensiv.... 
>>
>> beim Lesen von vermutlich intakten Daten?
>
>*sigh*.
>
>Noch jemand, der das mit der Datensicherheit bei RAID nicht verstanden
>hat.

Du laberst mal wieder. Was hat das mit der vorgeblich(?) 
vom RAID verschuldeten Leseperformanz vom Quell-NAS zu tun?

CU!
Ulrich

[toc] | [prev] | [next] | [standalone]

#223444

begin 1 followup to Ulrich F. Heidenreich <from!not-for-mail@tremornet.de>:
> Juergen P. Meier in <news:34664.2284.1443506238@news.jors.net>:
>
>>to Günter Frenz <usenet-01@guefz.de>:
>>> Am Mon, 28 Sep 2015 17:36:57 +0200 schrieb Matthias Eißing:
>>
>>>> RAID 5/6 sind rechenintensiv.... 
>>>
>>> beim Lesen von vermutlich intakten Daten?
                   ^^^^^^^^^^
>>*sigh*.
>>
>>Noch jemand, der das mit der Datensicherheit bei RAID nicht verstanden
>>hat.
>
> Du laberst mal wieder. Was hat das mit der vorgeblich(?) 
> vom RAID verschuldeten Leseperformanz vom Quell-NAS zu tun?

s.O

[toc] | [prev] | [next] | [standalone]

#223453

Am 29.09.15 um 10:04 schrieb Ulrich F. Heidenreich:

> Du laberst mal wieder. Was hat das mit der vorgeblich(?)
> vom RAID verschuldeten Leseperformanz vom Quell-NAS zu tun?

Beispiel:
Du hast ein RAID-5 mit n Festplatten.

Jetzt hast du eine Datei, die davon gelesen werden soll.... aufgrund der 
Natur eines RAIDs müssen dafür wie viele Festplatten angeschmissen 
werden/von wievielen Festplatten mussen Teile dieser einen Datei gelesen 
werden?

Wer sagt, daß die Datei in Ordnung ist? Tipp: Das geht über die Parität. 
Also noch eine Festplatte...

Jetzt muss die Datei zusammengefügt werden....

-- 
cu://Matthias.Eißing.de

[toc] | [prev] | [next] | [standalone]

#223454

Matthias Eißing in <news:mudkvt$ov9$1@solani.org>:

>Am 29.09.15 um 10:04 schrieb Ulrich F. Heidenreich:
>
>> Du laberst mal wieder. Was hat das 

Mit das == "vermutlich intakte".

>> mit der vorgeblich(?) vom RAID verschuldeten Leseperformanz vom 
>> Quell-NAS zu tun?
>
>Beispiel:
>Du hast ein RAID-5 mit n Festplatten.

Mit einmal n==4, wenn vom 4-Bay gelesen wird.

>Jetzt hast du eine Datei, die davon gelesen werden soll.... aufgrund der 
>Natur eines RAIDs müssen dafür wie viele Festplatten angeschmissen 
>werden/von wievielen Festplatten mussen Teile dieser einen Datei gelesen 
>werden?

4

Mit andermal n==8 und RAID6: 8

Warum geht das Lesen ab 4 Platten signifikant langsamer als ab 8?

Ich schieb's nachwievor auf CPU/RAM, die das Lesen so unerwarteterweise
beschleunigten. Eine Woche habe ich warten müssen, bis daß rund 10TB
Daten von alten 4-Bay-NAS aufs neue 8-Bay drüben waren. Bei 8-Bay auf
8-Bay-"Backup" hatte ich in etwa die gleiche Zeit veranschlagt. Fertig
war das aber bereits nach gut zwei Tagen.

CU!
Ulrich
-- 
de.talk.jokes, de.alt.gruppenkasper, de.soc.netzkultur.umgangsformen,
de.admin.news.* -- je nachdem, welchen Humor man bevorzugt.

Uwe Sinha zur Frage, "Wohin mit dem Traffic aus abg.witziges?"

[toc] | [prev] | [next] | [standalone]

#223455

Am 29.09.15 um 11:34 schrieb Ulrich F. Heidenreich:
> Ich schieb's nachwievor auf CPU/RAM

Mein Reden.

-- 
cu://Matthias.Eißing.de

[toc] | [prev] | [next] | [standalone]

#223470

Matthias Eißing in <news:mudnoe$3bg$1@solani.org>:

>Am 29.09.15 um 11:34 schrieb Ulrich F. Heidenreich:
>> Ich schieb's nachwievor auf CPU/RAM
>
>Mein Reden.

Und nachwievor mein Reden, daß ich zuvor nicht daran glaubte, 
daß die CPU-Leistung/RAM-Ausstattung einen dermaßen Schub für 
die Lesegeschwindigkeit bedeutet; die sei eher von den Platten 
und dem Netzwerk abhängig. 

Auf 4 GByte aufrüsten lassen habe ich es primär, weil ich mir 
davon Vorteile für den Serverbetrieb erhoffte. Wie es auch JPM
so korrekt anmerkte.

Was dieses ominöse "Scrubbing" angeht, scheint es QNAP in der Tat 
nicht vorgesehen/implementiert zu haben. Machte es deswegen Sinn, 
mal zu versuchen, dem im NAS wohnenden Pinguin - so möglich -
diesbezüglich an die Wäsche zu gehen:

Also ein "dd if=/dev/sda of=/dev/null" anstoßen und es per crontab
alle ~14 Tage mal laufen zu lassen? Und löste das das gewünschte 
Remappen von defekten Sektoren aus, was sich wiederum ja in den
SMART-Werten wiederspiegeln sollte?

CU!
Ulrich
-- 
>Beigelegt ist das "Intelligent Desaster Recovery" ...
Da ergibt sich fuer mich unmittelbar die Frage, was Seagate
unter einem "intelligent desaster" versteht... :-)
                     [Dialog zu "Seagate Backup" in ger.ct]

[toc] | [prev] | [next] | [standalone]

#223473

Matthias Eißing meinte:

> Du hast ein RAID-5 mit n Festplatten.
> 
> Jetzt hast du eine Datei, die davon gelesen werden soll.... aufgrund der
> Natur eines RAIDs müssen dafür wie viele Festplatten angeschmissen
> werden/von wievielen Festplatten mussen Teile dieser einen Datei gelesen
> werden?
> 
> Wer sagt, daß die Datei in Ordnung ist? Tipp: Das geht über die Parität.
> Also noch eine Festplatte...
> 
> Jetzt muss die Datei zusammengefügt werden....

Nein. Jedenfalls arbeiten weder Hardware-RAIDcontroller noch Software-
RAID-Implementierungen so. RAID ist nicht gedacht als Möglichkeit zur 
Überprüfung, ob von der Plattenelektronik unentdeckte lesefehler 
auftreten, und schon gar nicht zur Korrektur solcher Fehler (denn selbst 
wenn die parity nicht stimmt, kann daraus nicht errechnet werden, welche 
Platte nun einen unentdeckten Lesefehler hatte, eine Datenplatte oder 
vielleicht doch die Parityplatte. Das für RAID5 n+1 verwendete XOR-
Verfahren gestattet, die Daten einer ausgefallenen Festplatte zu 
rekonstruieren aus den Daten aller anderen n verbliebenen Platten des 
Verbunds (solange davon keine weitere ausfällt).  Das Ergebnis jeder 
einzelnen von der Platte als OK zurückgemeldeten Leseoperation wird aber 
als korrekt angesehen und nicht weiter überprüft (es sei denn, der ganze 
Block selber habe noch eine Quersumme; manche professionellen Raidysteme 
machen sowas und schreiben nicht 512Byte, sondern 520 Bytes pro Block). 
Die kann die Plattenelektronik  dann benutzen, um Datebnverfäschungen zu 
bemerken (und dann eben an den auftraggeber "Lesefehler" zu melden; das 
hat aber nichts mehr mit RAID zu tun). 

Ergebnis ist: solange alle Platten heil sind und keine derartigen 
Lesefehler bemerken, geht eine Leseoperation bei Raid-x (x aus 1, 
1_0,3,4,5,6,5_0 etc.pp.) immer nur auf eine Platte. Overhead entsteht nur 
beim Schreiben.

Diedrich
-- 
 pgp-Key (RSA) 1024/09B8C0BD 
 fingerprint = 2C 49 FF B2 C4 66 2D 93  6F A1 FF 10 16 59 96 F3 
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#223475

Am 29.09.15 um 16:27 schrieb Diedrich Ehlerding:
> Ergebnis ist: solange alle Platten heil sind und keine derartigen
> Lesefehler bemerken, geht eine Leseoperation bei Raid-x (x aus 1,
> 1_0,3,4,5,6,5_0 etc.pp.) immer nur auf eine Platte. Overhead entsteht nur
> beim Schreiben.

...solange die Datei in einen Block reinpasst.

-- 
cu://Matthias.Eißing.de

[toc] | [prev] | [next] | [standalone]

#223484

Matthias Eißing meinte:

>> Ergebnis ist: solange alle Platten heil sind und keine derartigen
>> Lesefehler bemerken, geht eine Leseoperation bei Raid-x (x aus 1,
>> 1_0,3,4,5,6,5_0 etc.pp.) immer nur auf eine Platte. Overhead entsteht
>> nur beim Schreiben.
> 
> ...solange die Datei in einen Block reinpasst.

Lies doch einfach erstmal, was ich geschrieben habe. Da steht "geht eine 
Leseoperation ... auf eine Platte". Es war die Betrachtung für einen 
einzelnen Block - für *jeden* einzelnen Block. 

Und wenn eine Datei nicht in einen Block passt, dann werden eben so viele 
gelesen, wie gebraucht werden. Jeder mit einer einzelnen Leseoperation. 
Aber für keinen von denen wird irgendeine RAID-Partityprüfung 
durchgeführt, sondern jeder wird genau einmal von der einen Platte des 
Verbunds gelsen, wo er eben steht. Die zugehörigen Parityblöcke werden 
beim Lesen nicht angefasst, und auch nicht die möglicherweise gar nicht zu 
dieser Datei gehörenden Blöcke der Platte, die aber mit einem der 
Dateiblöcke zu einer gemeinsamen opartity verwurstet sind. Jeder 
Lesezugriff auf einen Dateiblock aus anwendungssicht führt zu genau einem 
Lesezugriff aus sicht der Physik, solange keine Platte einen Fehler 
meldet. Dann (und nur dann) führt ein Lesezugriff auf einen Block auf der 
kaputten Platte bei Raid5 n+1 zu n Lesezugriffen, damit der kaputte Block 
rekonstrueirt werden kann, d.h. im Mittel verdoppelt sich die Leselast auf 
der Physik ungefähr. Hinzu kommt in dieser Situation der IO-aufwand für 
den Raid-rebuild-Vorgang.

In summe hat Raid5 beim Lesen keinen Overhead - alle Platten werden 
genutzt, es werden keine zusätzlichen IOs gegenüber dem Betrieb mit 
ungeschützten Platten verursacht. Insbesondere werden, anders als du es 
weiter oben behauptet hast, *keine* Parityprüfungen beim Lesen eingefügt. 
Mehraufwand entsteht nur Defekt- und rebuioldim rebuild-Fall (aber der ist 
einem normalerweise lieber als der Datenverlust) und beim Schreiben. 

Diedrich
-- 
 pgp-Key (RSA) 1024/09B8C0BD 
 fingerprint = 2C 49 FF B2 C4 66 2D 93  6F A1 FF 10 16 59 96 F3 
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#223508

Am 29.09.15 um 19:06 schrieb Diedrich Ehlerding:
> Lies doch einfach erstmal, was ich geschrieben habe. Da steht "geht eine
> Leseoperation ... auf eine Platte". Es war die Betrachtung für einen
> einzelnen Block - für*jeden*  einzelnen Block.

Nur soviel sei bemerkt:

Meine Betrachtung ging von Dateien aus.... Insbesondere dann, wenn eine 
Datei (ich wiederhole: Datei) über mehrere Blöcke verteilt ist, ergo auf 
mehreren Festplatten verteilt ist, müssen mehrere HDDs angesprochen 
werden. Das gibt einen Overhead. Vor allem in der CPU/im 
RAID-Controller. RAID-5 kann iA schneller lesen, als von einer 
Single-Disk. Bei SOHO-Controllern mit schwacher CPU (Marvell!) trifft 
das aber häufig nicht zu.

Es gibt auch RAID-Controller mit parity-check-on-read....

-- 
cu://Matthias.Eißing.de

[toc] | [prev] | [next] | [standalone]

#223545

Matthias Eißing meinte:

> Nur soviel sei bemerkt:
> 
> Meine Betrachtung ging von Dateien aus.... Insbesondere dann, wenn eine
> Datei (ich wiederhole: Datei) über mehrere Blöcke verteilt ist, ergo auf
> mehreren Festplatten verteilt ist, müssen mehrere HDDs angesprochen
> werden. Das gibt einen Overhead. Vor allem in der CPU/im
> RAID-Controller. 

Egal ob Raid5, Raid6, Raid10 oder Raid-garnichts, also ungeschützte 
Platte: jeder Block muss genau einmal gelesen werden. Ob die Blöcke einer 
Dartei auf einundderselben Platte liegen oder auf mehreren, ist für den 
CPU-aufwand egal; beim random-Zugriff um so egaler - die Nummer des Blocks 
relativ zum Dateianfang muss umgerechnet werden (anhand der Filesystem-
Metadaten) in eine Blockadresse. Der Rechenaufwand, daraus dann noch die 
passende Platte zu bestimmen, ist demgegenüber minimal. 

> RAID-5 kann iA schneller lesen, als von einer
> Single-Disk.

Eben. Und das wird nicht dadurch erreicht, dass, wie du weiter oben 
fälschlicherweise behauptet hast, die Parity bei jedem Zugriff überprüft 
wird, sondern dadurch, dass insbesondere für mehrere parallele Threads 
immer alle Platten in Betrieb sind. 

> Bei SOHO-Controllern mit schwacher CPU (Marvell!) trifft
> das aber häufig nicht zu.
> 
> Es gibt auch RAID-Controller mit parity-check-on-read....#

Mag sein, dass es Controller gibt, die entsprechende Befehle ausführen 
können. Aber parity-check durch den  Controller dient dazu, die Integrität 
des gesamten Raidbverbunds zu prüfen; nicht aber zur Korrektur von 
Lesefehlern.  Denn was ist die Konsequenz, wenn die parity nicht stimmt? 
Daraus kann man dann nur schließen, dass eine Platte falsche Daten 
geliefert hat - aber welche das ist, weiß man nicht, und wie die Daten 
korrekt sind, weiß man auch nicht. Raid ist eben *kein* Verfahren, um noch 
unentdeckte Lesefehler zu entdecken oder gar zu korrigieren, sondern um 
entdeckte Fehler zu überleben. Um Bitkipper auf der Platte zu entdecken, 
eigent sich eine Quersumme über den ganzen BLock - was, wie gesagt, 
professionelle Raidcontroller auch tun, da stehen auf der Platte dann 520 
Bytes, und davon sind 8 Bytes Quersumme über den Block (damit kann man 
schon gnz gut Bitkipper entdecken).

Rein theoretisch könnte man natürlich auch mehrere Parityplatten mit 
fehlerkorrigierenden Codes erzeugen. Dann allerdings wird der Aufwand 
gigantisch. Mir ist nicht bekannt, dass irgendwelche Controller bei jedem 
normalen  Lesezugriff die parity derganzen Gruppe von Blocks prüfen.

Diedrich
-- 
 pgp-Key (RSA) 1024/09B8C0BD 
 fingerprint = 2C 49 FF B2 C4 66 2D 93  6F A1 FF 10 16 59 96 F3 
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#223642

Diedrich Ehlerding <diedrich.ehlerding@t-online.de> wrote:

> Rein theoretisch könnte man natürlich auch mehrere Parityplatten mit 
> fehlerkorrigierenden Codes erzeugen. Dann allerdings wird der Aufwand
> gigantisch. Mir ist nicht bekannt, dass irgendwelche Controller bei jedem
> normalen  Lesezugriff die parity derganzen Gruppe von Blocks prüfen.

ZFS macht genau das. Jeder Block hat eine Checksumme, und die wird bei
jedem Lesen des Blocks überprüft. Wenn ein Fehler auftritt kann dieser
Block aus den Daten der anderen Platten neu berechnet werden und somit
korrigiert werden.
Deswegen laufen auf ZFS-Systemen regelmäßig Scrub-Jobs (typischerweise
1mal pro Monat) welche jeden einzelnen Block jeder Platte lesen - und
ggf korrigieren.

Das funktioniert bereits bei raid-z1 (entspricht RAID-5, also einfache
Parität). Mein HP-Microserver läuft unter FreeNAS 9.3 als raid-z2
(entspricht RAID-6, also doppelte Parität) mit 6 Platten brutto, ergibt
4 Platten netto. Dafür dürfen sogar 2 der 6 Platten gleichzeitig
ausfallen und die Daten sind immer noch da.

-- 
In a world without walls and fences,
   who needs windows and gates?

[toc] | [prev] | [next] | [standalone]

#223648

Marc Stibane meinte:

> ZFS macht genau das. Jeder Block hat eine Checksumme, und die wird bei
> jedem Lesen des Blocks überprüft. Wenn ein Fehler auftritt kann dieser
> Block aus den Daten der anderen Platten neu berechnet werden und somit
> korrigiert werden.

Ja, schon - aber meines Vorredners Behauptung war, bei jedem Lesezugriff 
würden die Daten aller Platten gelesen. Was ZFS da macht, ist letztlich 
die Software-Implementierung von dem, was manche Raidcontroller auch 
machen - der Block selber hat eine Quersumme, mit der man Bitkipper 
entdecken kann. Und wenn ein Bitkipper entdeckt wird, (aber auch nur dann) 
wird er korrigiert.

Diedrich
-- 
 pgp-Key (RSA) 1024/09B8C0BD 
 fingerprint = 2C 49 FF B2 C4 66 2D 93  6F A1 FF 10 16 59 96 F3 
 HTML-Mail wird ungeleſen entſorgt.

[toc] | [prev] | [next] | [standalone]

#223700

On 10/02/2015 08:26 PM, Marc Stibane wrote:
> Diedrich Ehlerding <diedrich.ehlerding@t-online.de> wrote:
>
>> Rein theoretisch könnte man natürlich auch mehrere Parityplatten mit
>> fehlerkorrigierenden Codes erzeugen. Dann allerdings wird der Aufwand
>> gigantisch. Mir ist nicht bekannt, dass irgendwelche Controller bei jedem
>> normalen  Lesezugriff die parity derganzen Gruppe von Blocks prüfen.
>
> ZFS macht genau das. Jeder Block hat eine Checksumme, und die wird bei
> jedem Lesen des Blocks überprüft. Wenn ein Fehler auftritt kann dieser
> Block aus den Daten der anderen Platten neu berechnet werden und somit
> korrigiert werden.
> Deswegen laufen auf ZFS-Systemen regelmäßig Scrub-Jobs (typischerweise
> 1mal pro Monat) welche jeden einzelnen Block jeder Platte lesen - und
> ggf korrigieren.

Die muss man aber selbst über die crontab implementieren.


> Das funktioniert bereits bei raid-z1 (entspricht RAID-5, also einfache
> Parität). Mein HP-Microserver läuft unter FreeNAS 9.3 als raid-z2
> (entspricht RAID-6, also doppelte Parität) mit 6 Platten brutto, ergibt
> 4 Platten netto. Dafür dürfen sogar 2 der 6 Platten gleichzeitig
> ausfallen und die Daten sind immer noch da.

Du hast da hoffentlich ECC-RAM drin... Sonst kann dir das Scrubbing im 
Falle eines Falles korrekte Daten mit fehlerhaften überschreiben.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#223712

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 10/02/2015 08:26 PM, Marc Stibane wrote:

>> Deswegen laufen auf ZFS-Systemen regelmäßig Scrub-Jobs
>> (typischerweise 1mal pro Monat) welche jeden einzelnen Block jeder
>> Platte lesen - und ggf korrigieren.
> Die muss man aber selbst über die crontab implementieren.

Bei FreeNAS reicht dazu ein Klick im Web-Interface...


>> Mein HP-Microserver läuft unter FreeNAS 9.3 als raid-z2 (entspricht
>> RAID-6, also doppelte Parität) mit 6 Platten brutto, ergibt 4 Platten
>> netto. Dafür dürfen sogar 2 der 6 Platten gleichzeitig ausfallen und
>> die Daten sind immer noch da.
> Du hast da hoffentlich ECC-RAM drin...

Latürnich

> Sonst kann dir das Scrubbing im Falle eines Falles korrekte Daten mit
> fehlerhaften überschreiben.

Jupp, bekannt. Dass der N54L ECC kann war ein kräftiges Plus bei der
Auswahl.

-- 
In a world without walls and fences,
   who needs windows and gates?

[toc] | [prev] | [next] | [standalone]

#223713

On 10/03/2015 08:20 PM, Marc Stibane wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> On 10/02/2015 08:26 PM, Marc Stibane wrote:
>
>>> Deswegen laufen auf ZFS-Systemen regelmäßig Scrub-Jobs
>>> (typischerweise 1mal pro Monat) welche jeden einzelnen Block jeder
>>> Platte lesen - und ggf korrigieren.
>> Die muss man aber selbst über die crontab implementieren.
>
> Bei FreeNAS reicht dazu ein Klick im Web-Interface...

Der auch nichts anderes macht als einen Eintrag in der Crontab zu 
generieren.

  Gerrit

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | ger.ct

csiph-web