Re: Vinum, RAID-5, 3HDs

On Mon, Dec 30, 2002 at 11:37:46AM +1030, Greg 'groggy' Lehey wrote:
> On Monday, 30 December 2002 at 1:35:28 +0100, Bernd Walter wrote:
> > On Mon, Dec 30, 2002 at 01:14:32AM +0100, Oliver Fromme wrote:
> >> Bernd Walter <ticso(at)cicely8.cicely.de> wrote:
> >>> On Mon, Dec 30, 2002 at 09:34:10AM +1030, Greg 'groggy' Lehey wrote:
> >>>> On Sunday, 29 December 2002 at 21:10:20 +0100, Bernd Walter wrote:
> >>>>> Nicht zuletzt besteht ein einfach gespiegeltes R1 aus einer geraden
> >>>>> Anzahl Plexe - da muß man dann unabhängige Datenbereiche auf die
> >>>>> gleichen Spindeln legen.
> >>>>
> >>>> Die Anzahl braucht nicht gerade zu sein, nur mehr als eins.
> >>>
> >>> Ich bezog mich auf ein einfach gespiegeltes System.
> >>> Natürlich kann man ein 80'er Plex und ein concat mit 2x40 Plex nehmen.
> >>> Aber im Falle von gleich großen Platten kann ich mir keine Sinnvolle
> >>> Variante mit Raid1 vorstellen.
> >>
> >> Doch, durchaus. Es muß ja nur sichergestellt sein, daß
> >> jeder Schreibzugriff auf zwei unterschiedlichen physika-
> >> lischen Festplatten landet. Wieso sollte das bei drei
> >> Festplatten nicht genauso möglich sein wie bei zweien?
> >>
> >> Du kannst zum Beispiel, wenn Du drei gleichgroße Platten
> >> (A, B, C) hast, diese jeweils in zwei Hälften (1 und 2)
> >> aufteilen und über Kreuz mirrorn: A1 <-> B2, B1 <-> C2,
> >> C1 <-> A2.
> >
> > Das entspricht nicht der Performanceverteilung, die UFS von einer
> > Platte erwartet.
>
> Wieso?

Angenommen wir haben folgende Aufteilung:

Plex0 Plex1
HDD1.a HDD2.a
HDD3.a HDD2.b
HDD3.b HDD1.b

Jetzt haben wir im Datenbereich der HDD1 einen künstlichen Bruch
erzeugt.
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.
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.
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.

> > Mag sein, daß es keine Auswirkungen hat, aber so Pauschal würde ich
> > das nicht behaupten.
>
> Na, das tust Du aber :-) Ich kenne keine Probleme mit dieser Methode.

Nein - ich schreibe nur von einem Risiko, welches man erst mal
ausschliessen sollte, bevor man solche Konstruktionen in Betracht
zieht.

> >> Bei IDE kann man eigentlich nicht paranoid genug sein.
> >> Genaugenommen sollte man dabei immer Mirror aus drei Teilen
> >> machen, bei jedem Lesezugriff alle drei Teile lesen und die
> >> Daten per Mehrheitsentscheid liefern. ;-)
> >
> > Hört sich nach einer neuen Lesestrategie für Vinum an :)
>
> Ist aber ziemlich paranoid.

Rettet einem aber bei IDE verdammt oft Daten.

> > 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.

Vermutlich bin ich da auch nur etwas parnoid.
Ich habe da schon einige recht schlechte Erfahrungen gemacht.

Auf einer remote Alpha habe ich fast ein ganzes Jahr nach einem IO
Deadlock gesucht.
War recht ärgerlich, da ich remote kein Powercycle ausführen konnte und
nach einem reboot per DDB die Console nicht mehr funktionierte.
Wenn ich die Kiste also remote rebootet habe, dann mußte ich am
nächsten Tag beim Provider anrufen, damit er die Maschinen Hardware-
mässig resetet.
Crashdumps haben auch nicht mehr funktioniert.
Es hat sich dabei um die srv1.cosmo-project.de gehandelt, die zudem
auch cvsup.de.freebsd.org ist.
Zur der Zeit habe ich sogar verflucht eine Alpha genommen zu haben.
War schon recht nett von Plusline teilweise mehrmals die Woche einen
Powercycle zu machen, obwohl das Hosting nur gesponsort ist.
Gefunden habe ich den Fehler übrigens bis heute noch nicht, dafür aber
zum Glück einen sehr gut funktionierenden Workaround.

Zu FreeBSD 2.x und 3.x Zeiten hatte ich ebenfalls einige Maschinen zu
betreuen, die alle paar Wochen mit einem IO Deadlock hängen geblieben
sind - viele der Maschinen bekamen eine 4.0-current verpasst, weil
Matt Dillon dort angefangen hat sehr viele der Ursachen zu beseitigen.
Ich bin ihm dafür bis heute dankbar.

-- 
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