Re: Vinum, RAID-5, 3HDs

From: Bernd Walter <ticso(at)cicely8.cicely.de>
Date: Mon, 30 Dec 2002 03:59:53 +0100

On Mon, Dec 30, 2002 at 12:42:59PM +1030, Greg 'groggy' Lehey wrote:
> On Monday, 30 December 2002 at 2:59:02 +0100, Bernd Walter wrote:
> > Angenommen wir haben folgende Aufteilung:
> >
> > Plex0 Plex1
> > HDD1.a HDD2.a
> > HDD3.a HDD2.b
> > HDD3.b HDD1.b
>
> Hmm. Das würde funktionieren, dafür braucht man aber nur vier
> Subdisks, zwei kleine und zwei große:
>
> Plex0 Plex1
> HDD1.a HDD2.a
> HDD3.a ...
> .... HDD1.b
>
> Besser wäre wohl:
>
> Plex0 Plex1
> HDD1.a HDD2.a
> HDD3.a HDD3.b
> HDD2.b HDD1.b

Ich meinte, das die oberste Zeile das erste drittel bilded, usw.
In deinem Fall wird das mittlere Volumedrittel nur von HDD3 gebilded.
Vermutlich haben wir uns da mit der Tabelle missverstanden.

> > Jetzt haben wir im Datenbereich der HDD1 einen künstlichen Bruch
> > erzeugt.
>
> Was meinst Du da? Mit einem Hammer?

Der Übergang auf eine andere Spindel.

> > Ein Übergang auf eine andere Spindel bedeutet aber grundsätzlich ein
> > Performanceeinbruch, weil der Preread der Platte nicht mehr greift
> > und die volle Zugriffszeit anfällt.
>
> Irgendwie komme ich hier nicht mit. Meinst Du den Fall, wo ein
> Zugriff über die Grenzen der Subdisks? Das kannst Du nicht ganz
> vermeiden. Mit concatenated Plexes ist das aber vernachlässigbar.
> Mit striped Plexes ist es ein Grund dafür, große Streifen zu nehmen.

Ich benutze stripes nur gezwungenermassen wenn ich R5 mache.
Das ist auch einer der Gründe, warum ich auch selten R5 verwende.
Vermutlich übertreibe ich in dem ursprünglichen Fall, da es ja nur
eine vermeidbare Ansatzstelle ist.

> > In einigen Fällen ist dieser Effekt sogar derart störend, das ich
> > sogar gezwungen war die Lesestrategie von Vinum auf ein Plex zu
> > fixieren.
>
> Das muss in fast jedem Fall zu Performanceeinbüßen führen.

Nein - das festhalten auf einem plex bringt in einigen Fällen echte
Vorteile.
Eine Platte liest Statistisch wenigstens eine halbe Spur als preread,
weil die Daten schlicht und ergreifend bei der Positionierung
schon am Kopf vorbeirauschen.
Wenn ich jetzt 64k lese und die Spur 256k hat, dann macht es einfach
keinen Sinn die folgenden 64k von einem anderen Plex zu lesen, wo
die Platte des ursprünglichen Plexes die geforderten Daten bereits mit
fast 100%iger Sicherheit im Cache hat.
Und lineare Zugriffe sind selbst per gleichzeitigen Zugriffen auf
unterschiedliche Files nicht gerade selten.
Das einzig bessere wäre die Verteilung nicht per Round-Robin, sondern
mit Hilfe einer Abhängigkeit auf vorangegange Zugriffe zu machen -
sicherlich nicht einfach zu implementieren.

> > Wie schnell man das Problem sogar noch verschärfen kann siehst du an
> > Olivers Beispielkonfiguration, die sogar bewirkt, daß die zweite
> > Hälfte einer Platte gar vor der ersten kommt.
>
> Einer von uns blickt überhaupt nicht mehr durch.

Evtl erklärt sich das aus dem Problem mit der Tabelle.

> >>> Ist nur dumm, daß man beim Lesen noch mal Speicher allocieren muß,
> >>> das birgt wieder ein neues Deadlock Risiko.
> >>
> >> Nur mit Swap. Auch dann sehe ich keine Risiken, befürchte sie aber.
> >
> > swap ist überall - ein mmap File hat exact die gleiche Charakteristik
> > und die Filesystembuffer sind ebenfalls vergleichbar.
>
> Nein, das ist etwas anderes. Das Problem das ich sehe, ist, dass man
> beim (Aus-)Swappen Speicher zuordnen will, dafür aber erst den alten
> Inhalt retten muss.

Wenn das System Platz braucht, dann schreibt es Speicher auf das
zugehörige Storagedevice - dabei gibt es kein Unterschied, ob es Swap
für anonymen Speicher oder ein File für mmap'ed Speicher ist.
Hat aber erst mal nichts mit lesen zu tun.

Fürs schreiben mußt du Speicher allocieren, weil du wissen musst welche
Zugriffe noch ausstehen.
Wenn du jetzt aber fürs Lesen Speicher aus dem gleichen Pool entnimmst,
dann sorgst du für ein größeres Risiko, das die Sicherheitsreserven
fürs Schreiben ausgehen.
Die Sicherheitsreserven sind aber die einzige zuverlässige Maßnahme,
die FreeBSD zu bieten hat um Deadlocks aufgrund von Speichermangel
entgegenzuwirken.
Aber da Vinum an diese Sicherheitsreserve nicht drangeht ist das
ein bereits bestehendes Problem.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 30 Dec 2002 - 04:00:10 CET

search this site