Re: Raid 3 vs. 5

On Mon, Apr 09, 2007 at 09:32:39PM +1000, Peter Ross wrote:
> On Sun, 8 Apr 2007, Bernd Walter wrote:
>
> > Dafür haben R4/5 halt andere neue Probleme durch die Differentielle
> > Parität, was das schreiben verlangsamt und etwas unsicherer macht.
>
> Nach genauem Lesen, wie die Paritaet gebildet wird, ist mir das jetzt auch
> wieder klar
> (http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5_parity_handling)
>
> Sorry, ich glaube, das wusst ich schon mal..
>
> > Bei ZFS gibt es das Loch auf Plattenebene auch, aber nicht darüber,
> > weil der inkonsistente Block nach einem Stromausfall keine Anwendung
> > finded, da er innerhalb dieses Zeitraumes nicht verlinkt wurde.
>
> Was dann wohl voraussetzt, dass dieses Verlinken atomar - also nur auf
> einer Platte - stattfindet, sonst hat man das Problem nur vom
> Datenschreiben aufs Linkwechsel "verschoben".

Genau kenne ich den Mechanismus nicht, aber atomar ginge das auch mit
Prüfsummen, die eine Generationsnummer enthalten und dann tut das auch
mit mehr als einer Platte.
Das Geheimniss liegt wohl im Intentlog.
Diverse Metadaten sollen wohl auch bei einer oder mehreren Einzel-
platten redundant vorliegen.

> > Zudem hat ZFS noch Prüfsummen, die eventuelle Fehler erkennen und
> > mittels Redundanz eine automatische Korektur ermöglichenm, während
> > ein RAID selber keine Fehler erkennt.
>
> Das koennte dabei auch helfen.. sicher nicht trivial.

Schluckt ein wenig Performance.
Man kann es auch abschalten, aber das ist eigendlich ein schönes
Feature.
IBM hat sowas früher schon auf AS400 gemacht - die haben 520 Byte
Blöcke auf den Platten gespeichert.
Aber die meisten Platten können nur 2^n Byte pro Block speichern,
viele sogar nur 512 Byte, von daher erfordert sowas schon ein
spezielles Filesystem, ansonsten hätte man das auch mit klassischem
RAID als Basis nutzen können.
Leider mag es kaum ein traditionelles Filesystem wenn das virtuelle
Laufwerk nachher nur noch 504 Byte große Blöcke liefert.
Aus DMA Gesichtspunkten ist was anderes als 2^n eh ungünstig.
ZFS nimmt dafür nach Möglichkeit sehr große Blöcke, um das zu
kompensieren.

> Entschuldigt, dass mir noch eine Frage auf der Zunge liegt, im
> Zusammenhang mit ZFS:
>
> Wozu dienen eigentlich Partitionstypen und wozu braucht man Disklabel,
> wenn man das ganze Slice haben will?

Partitionstypen können helfen swap von UFS zu unterscheiden, etc.
Ansonsten gab es mal eine historische Abhängigkeit, die seit GEOM
erledigt ist.
Der bootloader braucht wohl eine bekannte Strucktur, ebenso das Rechner
BIOS, also die Bootplatte muss zwangsläufig sowas enthalten.

> Der Gedanke kommt mir, wenn ich die Einrichtung von Platten fuer ZFS
> durchlese. Da wird mit FreeBSD-Slices gespielt, obwohl ZFS mit UFS gar
> nichts am Hut hat.

Wo hast du das her?
Ich habe ZFS unpartitionierte Platten vorgeworfen.
Das ist auch die Empfehlung.
Natürlich ist es notwendig Partitionen zu verwenden, wenn man nur eine
Platte hat, da man ja auch andere Filesysteme und Bootrecord, etc..
unterbringen muss.

> Kompatibel mit Suns ZFS ist es bestimmt auch nicht..

Doch - der Source kommt von Sun.
Es gibt wohl noch ein paar kleinere Dialekte, die auftauchen, wenn die
Platten partitioniert sind.

> Wenn Volumemanagement und Filesystemoperationen sowie RAID auf ZFS-Ebene
> stattfinden, scheint mir, dass es moeglich sein muesste, dass alles in die
> Firmware eines RAID-Controllers zu legen.
>
> Das OS braucht dann nur noch einen Treiber, der die VFS-Operationen und
> natuerlich die administrativen ZFS-Kommandos an den Controller
> weitergibt..
>
> Ist die Aussicht realistisch?

Ich denke nicht, das schränkt gewaltig ein.
Man muss z.B. alle Platten des Pools an dem gleichen Controller haben.
RAID Controller sind in der Regel auch ziemlich lahme Biester, da die
bislang ja nur XOR machen mussen.

> Anyway, mein Upgrade war gerade erfolgreich. Zeit, ums System zu
> panicken;-) Gut, dass ich gerade alte Audiotapes digitalisieren will, das
> erzeugt schoen viel Datenmuell.

Viel Spaß :)

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd(at)bwct.de           info(at)bwct.de            support(at)fizon.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message