Re: Vinum, RAID-5, 3HDs

From: Greg 'groggy' Lehey <grog(at)lemis.com>
Date: Mon, 30 Dec 2002 12:42:59 +1030

On Monday, 30 December 2002 at 2:59:02 +0100, Bernd Walter wrote:
> 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

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

> Jetzt haben wir im Datenbereich der HDD1 einen künstlichen Bruch
> erzeugt.

Was meinst Du da? Mit einem Hammer?

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

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

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

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

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

Ja, Yahoo! hat ähnliches gemacht.

Greg

--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply or reply to the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger grog(at)lemis.com for PGP public key
See complete headers for address and phone numbers
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 - 03:13:12 CET

search this site