Re: Vinum, RAID-5, 3HDs

On Monday, 30 December 2002 at 0:53:23 +0100, Bernd Walter 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:
>>> On Sun, Dec 29, 2002 at 07:55:45PM +0100, Andreas Braukmann wrote:
>>>> On Sun, Dec 29, 2002 at 03:43:00PM +0100, Oskar Eyb wrote:
>>> Außerdem darf sich kein Plex die gleiche Spindel mit einem anderen
>>> Teilen, weil bei Ausfall der Platte dann beide Plexe weg wären.
>>
>> Nein, stimmt nicht. Es sind nicht die Plexes sondern die Subdisks,
>> die "weg"gehen. Man kann sie über Kreuz anlegen, solange der
>> Adressraum der Subdisks sich auf unterschiedlichen Spindeln befindet.
>
> Wommöglich habe ich da was falsch in Erinnerung.
> Was passiert mit einem Volume, wenn von den beiden einzigen Plexen
> jeweils eine Subdisk aus einem nicht überlappenden Bereich ausfällt?

Die fallen aus. Die Plexe gehen in den "degraded"-Zustand über, das
Volume läuft weiter.

> Soweit ich das in Erinnerung habe fällt das Volume aus,

Nein.

>> On Sunday, 29 December 2002 at 23:39:37 +0100, Andreas Braukmann wrote:
>>> On Sun, Dec 29, 2002 at 09:10:20PM +0100, Bernd Walter wrote:
>>>
>>> Wenn man eh schon mit IDE herumast, wuerde ich immer ein RAID 1+0
>>> bevorzugen. Das "Sparen" auf Kosten der Schreib-Performance und
>>> mit Vorteilen hinsichtlich der Kapazitaet, lohnt sich eigentlich
>>> nur bei hohen Kapazitaetsbedarf in Verbindung mit SCSI-Platten.
>>
>> Wieso lohnt sich das? Du kaufst eine schnelle, teuere Platte und
>> machst die dann wider langsam. Da bist Du mit einer billigen und doch
>> gar nicht so langsamen Platte besser bedient.
>
> Ohne Kontrolle über den Medieninhalt der Parität ist R5 mehr ein
> Glücksspiel als Datensicherheit.
> Das geht nur mit abgeschaltetem Schreibcache oder Tagged Command
> Queueing.
> In erstem Fall ist die IDE Platte -extrem- viel langsamer und für
> den zweiten Fall gibt es recht wenig Marktauswahl.
>
> Stelle dir mal vor es passiert folgendes:
> Du schreibst Daten und die Platte fällt Kurzzeitig aus.
> Die ausstehenden Schreibtransaktionen sind weg, aber beim nächsten
> Zugriff ist die Platte wieder da und du wirst niemals feststellen,
> das Schreibvorgänge unter den Tisch gefallen sind.

Das kann kaum passieren, ohne dass es dem Plattentreiber auffällt.
Die Requests müssten schon in Cache gewesen sein, die Platte fällt aus
und kommt wieder, ohne dass der Treiber weitere Zugriffe macht.

> Mit TCQ hingegen ist bekannt welche Transaktionen noch nicht auf dem
> Medium sind und wenn die Platte sich nicht mehr zurückmelded, dann
> wird die Platte resetet und die Transaktionen werden die neu
> ausgeführt.

Unter den genannten Bedingungen könnte das auch mit TCQ passieren.
Und auch mit SCSI.

> Natürlich ist das nicht nur ein Problem von R5, aber einen Paritäts-
> fehler wirst du ohne Regelmässige Überprüfung niemals feststellen.

Richtig. Ganz wohl ist es mir bei dem Gedanken auch nicht.

> Erst ein

(Platten-)

> Ausfall bringt der Parität eine Bedeutung zu - dann verlierst du
> trotz Raid Daten - zudem noch Daten in Dateien, die lange nicht mehr
> geschrieben wurden, bloß weil die sich die Parität mit oft
> geschrieben Daten geteilt haben.

Richtig.

> Wer denoch mit IDE R5 machen will sollte zumindestens ab und an die
> Parität prüfen - ein Fehler hier kann einen unerkannten
> Hardwarefehler aufdecken.

Es wäre interessant, ein Programm zu schreiben, das langsam im
Hintergrund die Parity fortlaufend prüft. Dürfte nicht allzuschwierig
sein: Im Prinzip kann es vinum(8) schon. Man müsste nur eine
Geschwindigkeit angeben, oder es vielleicht abhängig der
Plattenbelastung machen.

Greg

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