'init' eines RAID5 mit gvinum unter FreeBSD 5.4

[blackthunder]

Hi,

erstmal vielen Dank für all die hilfreichen Tipps die ich schon in diesem Forum gefunden habe, aber jetzt komme ich nicht mehr weiter.

Ich bin dabei einen Server (SCSI-Platen) mit Groupware aufzusetzen.
Bis jetzt habe ich mein Glück mit 5.4-RELEASE und RELENG_5 versucht ein Raid5 aufzusetzen aber scheitere daran, dass ich von gvinum beim ausführen von 'gvinum init raid5.p0' jedesmal die Fehlermeldung
'gvinum: can't init: Unknown verb parameter' bekomme.
'/' und '/var' habe ich mit gmirror gespiegelt und '/usr' sollte eben das raid5 mit 4 Platten werden.
Weiss jemand ob es bei einem raid5 mit gvinum reicht vor dem newfs ein rebuildparity auszuführen?

@free wie hast du das problem gelöst? Ich habe gelesen, dass du ein raid5 mit gvinum am laufen hast.

Unter 4.X hab ich mit vinum noch keine Erfahrungen gesammelt, aber laut allen Info die ich bis jetzt gefunden habe soll es sehr stabil sein.

Auch soll gvinum beim Ausfall einer Platte bei raid5 noch sehr unzuverlässig sein. Klappt das unter 4.x besser?

So wie ich das sehe hab ich 3 Möglichkeiten:
1. Den Server mit 4.x aufsetzen('/' und '/usr' mit vinum spiegeln),
2. geom-raid3 anstatt des gvinum_raid5 verwenden, oder
3. das Raid5 mit gvinum (wenn möglich) zum laufen bringen und auf die Weiterentwicklung von gvinum warten (Was evtl ein nachträgliches 'init' mit sich bringen könnte).

Ich wäre euch sehr dankbar wenn ihr mir helfen könntet.

Gruss
Peter

PS: Die Platten sind zwar nicht mehr neu aber fit.
PPS: Das soll ein Produktivsystem werden.


Edit: Da bei RAID3 die Daten Byteweise geschrieben werden, fällt Möglichkeit 2 wohl aus, oder?

 

[dagnu]

irgendwie fehlt mir bei der Möglichkeitliste noch die Option einen
RAID5 Controller zu verwenden und auf Softewarelösungen zu verzichten

 

[Azazyel]

Ich bin dabei einen Server (SCSI-Platen) mit Groupware aufzusetzen.
Bis jetzt habe ich mein Glück mit 5.4-RELEASE und RELENG_5 versucht ein Raid5 aufzusetzen aber scheitere daran, dass ich von gvinum beim ausführen von 'gvinum init raid5.p0' jedesmal die Fehlermeldung
'gvinum: can't init: Unknown verb parameter' bekomme.

Kannst du deine Config-Datei und die Ausgabe von "gvinum list" hier mal auflisten?

'/' und '/var' habe ich mit gmirror gespiegelt und '/usr' sollte eben das raid5 mit 4 Platten werden.

Ich würde je nach Organisation noch '/home' mit auf das Raid 5 packen.

Weiss jemand ob es bei einem raid5 mit gvinum reicht vor dem newfs ein rebuildparity auszuführen?

Ein rebuildparity brauchst du bei Inbetriebnahme eines Raid 5 nicht. Das notwendige "init" überschreibt alles mit Nullen und setzt die Paritätsinformation damit in einen definierten Zustand.

Außerdem wird rebuildparity erst eingesetzt, wenn checkparity Fehler gefunden hat; checkparity sollte man von Zeit zu Zeit laufen lassen, um bösen Überraschungen vorzubeugen.

Auch soll gvinum beim Ausfall einer Platte bei raid5 noch sehr unzuverlässig sein. Klappt das unter 4.x besser?

Unter 4.x kann ich es dir nicht sagen, aber ich habe unter gvinum bei meinen Tests (unter 5.3) die Erfahrung gemacht, dass es es eine defekte Platte problemlos überlebt.

Was es erstaunlicherweise nicht überlebt hat, war der Ausbau (nicht Austausch) einer Platte. Beim nächsten Hochlauf verhielt sich sich gvinum so, als wäre die Platte nie vorhanden gewesen, und zeigte mein Raid 5 mit vier statt der ursprünglich fünf vorhanden Platten an.
Danach konnte ich die Raid 5 Partition nicht mehr mounten, und ein fsck lies sich aufgrund eines "incorrect superblock" erst gar nicht ausführen.
Ich weiß nicht, ob dieses Verhalten unter 5.4 immer noch gegeben ist.

So wie ich das sehe hab ich 3 Möglichkeiten:
1. Den Server mit 4.x aufsetzen('/' und '/usr' mit vinum spiegeln),

Davon würde ich aus zwei Gründen abraten.

Zum einen würde ich einen neuen Produktivserver nicht mehr mit der 4.x Linie aufsetzen. Die 4.x wird demnächst auslaufen, und erfahrungsgemäß sind Produktivsysteme immer wesentlich länger im Einsatz als ursprünglich geplant ist. Spätestens bei der ersten Erweiterung wirst du wahrscheinlich wegen mangelnder Treiberunterstützung auf Probleme stoßen, geschweige denn bei Problemen noch viel Support für die 4.x Linie bekommen.

Zum anderen ist der Betrieb der root-Partition mit (g)vinum aus meiner Erfahrung heraus nicht empfehlenswert. Ich würde die grundlegenden Partitionen ('/', '/usr', usw.) eher mit gmirror als Raid 1 betrieben und dann den Rest als Raid 5 hinzunehmen, so wie du es jetzt schon machst.

2. geom-raid3 anstatt des gvinum_raid5 verwenden, oder

Für Groupware würde ich aus Gründen der Performance eher zu Raid 5 greifen. Die vielen wahlfreien Zugriffe bei diesem Einsatzgebiet sind Gift für Raid 3.

3. das Raid5 mit gvinum (wenn möglich) zum laufen bringen und auf die Weiterentwicklung von gvinum warten (Was evtl ein nachträgliches 'init' mit sich bringen könnte).

Wenn du notfalls den Server für ein Wochenende für ein init entbehren kannst, ist das die Option, die ich ebenfalls wählen würde (eigentlich würde ich zu Hardware greifen, siehe unten).

Allerdings glaube ich nicht, dass bei einer Weiterentwicklung von gvinum ein init des Raids fällig sein wird. An der Datenstruktur auf den Platten sollte sich nichts ändern.

PS: Die Platten sind zwar nicht mehr neu aber fit.

Bei einem Produktivsystem würde ich schon zu neuer Hardware raten. Die Ausfallrate bei Festplatten steigt ab einem gewissen Alter ziemlich stark an.

PPS: Das soll ein Produktivsystem werden.

In diesem Fall würde ich auf jeden Fall - wie von dagnu korrekterweise angedeutet - zu einem Hardware-Raidcontroller raten. Sollte das Budget begrenzt sein und man nicht unbedingt die kurzen Zugriffszeiten der SCSI-Platten benötigen, kann man eine Lösung mit Serial ATA ins Auge fassen; die bekommt man selbst mit 5 Platten noch für dreistellige Beträge.

Ferner bedeutet Groupware im Normalfall auch schnell wachsende Datenmengen, für die die vorhandenen SCSI-Platten eventuell nicht ausreichend dimensioniert sind.

Im Normalfall dürften die Kosten eines Betriebsausfalls des Raids wesentlich höher sein als die Kosten für vernünftige Hardware. Insbesondere bei einem Groupware-Server ist ein unnötiger Ausfall (plus die Dauer für die Rekonstruktion des Raids plus etwaiger Datenverlust) inakzeptabel.

 

[blackthunder]

Vielen Dank für eure Antworten, die haben mir schonmal weitergeholfen.

Kannst du deine Config-Datei und die Ausgabe von "gvinum list" hier mal auflisten?

Die config schaut so aus:

drive d1 device /dev/da0s2e
drive d2 device /dev/da1s2e
drive d3 device /dev/da2s2e
drive d4 device /dev/da3s2e
 volume raid5
  plex org raid5 279k
   sd length 16658 drive d1
   sd length 16658 drive d2
   sd length 16658 drive d3
   sd length 16658 drive d4

Wenn ich nun gvinum create configfile eintippe erstellt er mir das raid ohne probleme und unter gvinum list wird dann alles ordentlich ausgegeben, d.h. d1 -d4 state up, 1volume: raid5 State up (48GB), 1plex: raid5.p0 state up und die 4 subdisks auch up. Allerdings initialisiert sich das RAID nicht und lässt sich auch nicht manuell initialisieren (Fehlermeldung siehe oben).

Allerdings habe ich gerade per Zufall festgestellt das nach folgendem Vorgehen gvinum automatisch ein init auf das RAID ausführt:

1. Das RAID mit obigem configfile erstellen (ein checkparity raid5.p0 schlägt fehl)
2. mit gvinum -> rm -r raid5 das raid löschen
3. Die Drives nicht mit gvinum -> rm dx löschen (!!!!)
Bis jetzt hatte ich die drives jedesmal mit gelöscht um für den nächsten Versuch eine saubere Basis zu haben.
4. Die ersten 4 Zeilen aus dem configfile entfernen.
5. Das Raid mit dem neuen configfile wieder erstellen.
6. Jetzt ist das raid down und die sds stale
7. Nach Eingabe von gvinum start raid5 wird das init ausgeführt.
8. checkparity ergibt keine Fehler

Was es erstaunlicherweise nicht überlebt hat, war der Ausbau (nicht Austausch) einer Platte. Beim nächsten Hochlauf verhielt sich sich gvinum so, als wäre die Platte nie vorhanden gewesen, und zeigte mein Raid 5 mit vier statt der ursprünglich fünf vorhanden Platten an.

Die Erfahrung hab ich mit 5.4 leider auch gemacht.

Zum Thema 'Hardwarecontroller':
Momentan steht nur diese HW zur Verfügung.
Was spricht bis auf den Geschwindigkeitsaspekt gegen eine Softraidlösung?

Was für eine stripesize würdet ihr für dieses raid empfehlen?

Gruss
Peter

 

[Azazyel]

Die config schaut so aus:

An der Konfiguration kann es schon mal nicht liegen, die ist einwandfrei. Ich würde allerdings statt "volume raid5" einen anderen Namen verwenden, z.B. "volume groupwaredata" oder was auch immer, das ist sonst hochgradig verwirrend.

Wenn ich nun gvinum create configfile eintippe erstellt er mir das raid ohne probleme und unter gvinum list wird dann alles ordentlich ausgegeben, d.h. d1 -d4 state up, 1volume: raid5 State up (48GB), 1plex: raid5.p0 state up und die 4 subdisks auch up. Allerdings initialisiert sich das RAID nicht und lässt sich auch nicht manuell initialisieren (Fehlermeldung siehe oben).

Das klingt schon sehr unsauber. Ich würde nochmal nach unten stehendem Schema neu starten.

Allerdings habe ich gerade per Zufall festgestellt das nach folgendem Vorgehen gvinum automatisch ein init auf das RAID ausführt:

Der Zufall hat auf einem Produktivsystem nichts zu suchen. Ich würde nochmal tabula rasa machen und empfehle (aus dem Gedächtnis) folgende Vorgehensweise:

• gvinum darf erstmal nicht automatisch beim Systemstart geladen werden
• reboot, damit gvinum nicht geladen ist
• Die ersten Sektoren der Festplatten erstmal löschen, damit alle "alten" Einstellungen, die stören könnten, mit Sicherheit weg sind: "dd if=/dev/zero of=/dev/da1 bs=64k count=10" für die erste, analog für alle anderen Platten
• bsdlabel erstellen, dabei sind zwei Besonderheiten zu beachten:
  • Der slice muss ein Offset von 16 haben (IIRC speichert vorher (g)vinum Verwaltungsinformationen ab)
  • Der slice darf nicht mit der Plattengrenze enden (IIRC damit geom nicht versehentlich den slice als Provider erkennt und in Beschlag nimmt, dann kann gvinum nicht mehr direkt darauf zugreifen)
  Die Begründungen sind etwas mit Vorsicht zu genießen, die sind aus der hintersten Ecke meines Schädels hervorgekramt. Es kann gut sein, dass es inzwischen auch ohne geht - die Empfehlungen waren teilweise noch für vinum - aber es kann nicht schaden.
  Hier z.B. mein bsdlabel:
  

  #        size   offset    fstype   [fsize bsize bps/cpg]
    c: 390721905        0    unused        0     0         # "raw" part, don't edit
    d: 390721888       16     vinum

• nochmal rebooten (sicher ist sicher)
• gvinum laden
• in gvinum "create -f /path/to/configfile" eingeben
• in gvinum "saveconfig" eingeben
• reboot (sicher ist sicher)
• falls das "create" nicht schon alles auf "up" gesetzt hat, in gvinum "start meinplex.p0" eingeben
• 5 Minuten warten, dann solltest du bei den Subdisks ein großes 'R' für Rebuild sehen
• Wenn das durchgelaufen ist, "saveconfig" in gvinum und anschließend reboot
• gvinum händisch starten, anschließend newfs auf das gvinum-device
• newfs auf das device
• mount
• als Test mit dd if=/dev/random of=/mnt/raid5device das Raid 5 vollschreiben
• wenn alles passt, gvinum wieder automatisch starten lassen
• reboot
• nochmal mounten und testes

Die Liste ist aus dem Gedächtnis und einige Punkte sind eigentlich redundant, aber so sollte es auf jeden Fall funktionieren.

Zum Thema 'Hardwarecontroller':
Momentan steht nur diese HW zur Verfügung.
Was spricht bis auf den Geschwindigkeitsaspekt gegen eine Softraidlösung?

Die Geschwindigkeit selbst ist nicht das Problem, die Systemlast ist es. Nachdem dein System kein reiner Fileserver ist und nebenbei noch andere Aufgaben hat, nehmen die Paritätsberechnungen zum einen unnötig Rechenzeit in Anspruch, zum anderen müssen die ganzen Daten über den Bus geschaufelt werden.
Dadurch entstehen nur durch die Festplattenzugriffe eine Grundlast, die der Rechner neben seinen eigentlichen Aufgaben bewältigen muss.

Wenn der Rechner schnell und modern genug ist, kann es sein, dass dies nicht so sehr ins Gewicht fällt. Das lässt sich aber nur durch Tests herausfinden.

Was für eine stripesize würdet ihr für dieses raid empfehlen?

Wenn ich mich recht entsinne, sind Werte zwischen 256 KB und 512 KB empfehlenswert.
Ich habe ein paar Tests mit verschiedenen Größen gemacht, es hat im Rahmen der Messgenauigkeit keine Unterschiede gemacht.

 

[marzl]

bei raid5-hardwarecontrollern ( die sind auch nicht besonders teuer) kann man unter freebsd bedenkenlos zu 3ware greifen. ansonsten würd ich persönlich gvinum derzeit noch nicht in einer kritischen umgebung einsetzen.
eine ernsthafte alternative wäre auch ein "günsiger" hardwarecontroller, der raid1 kann.
damit ist man datentechnisch ebenfalls auf der sicheren seite (z.b. promise fasttrak).

 

[free]

Hi,

bei gvinum ist noch kein "init" kommando eingebaut. stattdessen benutzt bitte "start <volume>" - das macht genau das.

free

 

[hazelnut]

Hi,

also ich hab das mal versucht so nachzuvollziehen ... ein

gvinum -> create /etc/vinum.conf brachte:

gvinum -> create /etc/vinum.conf
6 drives:
D raid56 State: down /dev/ad14s1d A: 0/157066 MB (0%)
D raid55 State: down /dev/ad12s1d A: 0/157066 MB (0%)
D raid54 State: down /dev/ad10s1d A: 0/157066 MB (0%)
D raid53 State: down /dev/ad8s1d A: 0/157066 MB (0%)
D raid52 State: down /dev/ad2s1d A: 0/157066 MB (0%)
D raid51 State: down /dev/ad0s1d A: 0/157066 MB (0%)

1 volume:
V data State: down Plexes: 1 Size: 0 B

1 plex:
P data.p0 R5 State: down Subdisks: 6 Size: 766 GB

6 subdisks:
S data.p0.s5 State: stale D: raid56 Size: 153 GB
S data.p0.s4 State: stale D: raid55 Size: 153 GB
S data.p0.s3 State: stale D: raid54 Size: 153 GB
S data.p0.s2 State: stale D: raid53 Size: 153 GB
S data.p0.s1 State: stale D: raid52 Size: 153 GB
S data.p0.s0 State: stale D: raid51 Size: 153 GB
gvinum ->


das Problem hier ist zu sehen ... nach einem

gvinum -> start data gab es dann nur noch ein:

GEOM_VINUM: plex data.p0 state change: down -> degraded
GEOM_VINUM: plex data.p0 state change: degraded -> down


Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x10
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc1c08128
stack pointer = 0x10:0xd525eccc
frame pointer = 0x10:0xd525ed10
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 500 (gv_init data.p0.s0)
trap number = 12
panic: page fault
Uptime: 4m39s

wo kann da das Problem sein? Unter 5.3 konnte man das gvinum noch im Single User Mode mit dem klassischen Vinum initialisieren ... das geht hier jetzt aber nicht mehr ...

und ich meine selbst ein
gvinum -> create -f /meine/config brachte nichts ...

gvinum -> create -f /etc/vinum.conf
# Vinum configuration of feuer.netinterview.de, saved at Sat Aug 13 21:40:12 200
5
# Current configuration:
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
:q!

wobei ich hier einmal sogar ein gescheidtes Ergebnis hatte - sprich, wo meine config dann wirklich drin stand. Wie ich dazu gekommen bin ... ??? Ein mal hab ich mir den Spaß gemacht, das alles einzutragen aber auch das hat nicht geholfen ...

und auch das
gvinum -> saveconfig bringt nichts ... nach einem gvinum -> create /etc/vinum.conf und einem anschließenden saveconfig + reboot erinnert er sich an das:

gvinum -> list
0 drives:

0 volumes:

0 plexes:

0 subdisks:

(nach einem reboot) wenn das so weitergeht, installiere ich mir wirklich noch ein 5.3 beta irgendwas - mit dem hab ich das damals ans laufen bekommen ...

Wenn also noch einer einen zündende Idee hat ... ich bin mit meinem Latein am ende ...

Im Voraus schon mal danke

PS:

gelabelt sind die HDD's wie bei vinum bzw. wie oben beschrieben.

 

[Azazyel]

also ich hab das mal versucht so nachzuvollziehen ... ein

gvinum -> create /etc/vinum.conf brachte:

gvinum -> create /etc/vinum.conf
6 drives:
D raid56 State: down /dev/ad14s1d A: 0/157066 MB (0%)
D raid55 State: down /dev/ad12s1d A: 0/157066 MB (0%)
D raid54 State: down /dev/ad10s1d A: 0/157066 MB (0%)
D raid53 State: down /dev/ad8s1d A: 0/157066 MB (0%)
D raid52 State: down /dev/ad2s1d A: 0/157066 MB (0%)
D raid51 State: down /dev/ad0s1d A: 0/157066 MB (0%)

Hier liegt schon das Problem: Nach dem create müsste hier auf jeden Fall State: up stehen, ich vermute daher, dass es ein Problem mit deinen Slices bzw. der Partition gibt.
Kannst du einmal die Ausgaben von

fdisk ad0
bsdlabel ad0s1

posten?

Es sieht so aus, also würde gvinum bzw. geom deine Partition nicht erkennen, und wenn der Zugriff darauf erfolgen soll, kann geom mit dem Zugriff nichts anfangen und verabschiedet sich.

wo kann da das Problem sein? Unter 5.3 konnte man das gvinum noch im Single User Mode mit dem klassischen Vinum initialisieren ... das geht hier jetzt aber nicht mehr ...

Es wird nach und nach immer mehr alter Code entfernt und ausschließlich auf geom umgestellt, insofern wundert mich das nicht sonderlich.

Ich würde vinum und gvinum unter gar keinen Umständen mischen, das schreit geradezu nach Ärger.

und ich meine selbst ein
gvinum -> create -f /meine/config brachte nichts ...

gvinum -> create -f /etc/vinum.conf
# Vinum configuration of feuer.netinterview.de, saved at Sat Aug 13 21:40:12 200
5
# Current configuration:

Das konnte ich nachvollziehen (auf 5.4-RELEASE-p6), scheint eine neue Eigenheit zu sein. Ich habe versuchsweise mal eine erstellte Konfiguration dort eingelesen und gesichert, dann hat es funktioniert.

und auch das
gvinum -> saveconfig bringt nichts ... nach einem gvinum -> create /etc/vinum.conf und einem anschließenden saveconfig + reboot erinnert er sich an das:

gvinum -> list
0 drives:

0 volumes:

0 plexes:

0 subdisks:

Das dürfte mit deinen Slices/Partition zusammenhängen. Wenn das nicht richtig aufgesetzt ist, kann gvinum keine Plexes darauf erstellen und keine Informationen speichern. Das würde erklären, warum deine Drives immer down sind und gvinum keine Informationen speichern kann.

(nach einem reboot) wenn das so weitergeht, installiere ich mir wirklich noch ein 5.3 beta irgendwas - mit dem hab ich das damals ans laufen bekommen ...

Wenn also noch einer einen zündende Idee hat ... ich bin mit meinem Latein am ende ...

Posten mal die oben angesproche Ausgabe von fdisk und bsdlabel, dann kriegen wir das schon hin.

 

[hazelnut]

Hi,

hier die Daten:

feuer# fdisk ad0
******* Working on device /dev/ad0 *******
parameters extracted from in-core disklabel are:
cylinders=319120 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=319120 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 321672897 (157066 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 655/ head 15/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
feuer#

feuer# bsdlabel ad0s1
# /dev/ad0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 321672897 0 unused 0 0 # "raw" part, don't edi
t
d: 321672881 16 vinum
feuer#


der Rest sieht analog aus.
Wie bin ich drauf gekommen ... zuerst mal alles gelöscht, wie du es beschrieben hattest, dann nach Handbuch neu eingerichtet.

anbei mal noch meine vinum.conf ...

drive raid51 device /dev/ad0s1d
drive raid52 device /dev/ad2s1d
drive raid53 device /dev/ad8s1d
drive raid54 device /dev/ad10s1d
drive raid55 device /dev/ad12s1d
drive raid56 device /dev/ad14s1d
volume data
plex org raid5 194k
sd length 0 drive raid51
sd length 0 drive raid52
sd length 0 drive raid53
sd length 0 drive raid54
sd length 0 drive raid55
sd length 0 drive raid56

Grüße + Danke!

 

[hazelnut]

Achso, noch ein kleiner Nachtrag ...

wenn ich ein

gvinum -> create /meine/config mache und dann ein
gvinum -> create -f /meine/config passiert nichts .... (die schon dargestellte leere Ausgabe eben)

nehme ich an dieser stelle aber nach dem

gvinum -> create /meine/config ein
gvinum -> create -f /neue/config stehen die Daten der alten drin - und zwar so wie es (anscheinend) sein soll ...

Das konnte ich nachvollziehen (auf 5.4-RELEASE-p6), scheint eine neue Eigenheit zu sein.

hmm, ich kann mir auch ein R5.4 ziehen und dann updaten ... vielleicht macht sich das besser ...


Gruß

Hazelnut

 

[Azazyel]

hmm, ich kann mir auch ein R5.4 ziehen und dann updaten ... vielleicht macht sich das besser ...

Das wäre klasse, sonst jagen wir vielleicht noch Fehlern hinterher, die längt behoben sind.

 

[hazelnut]

Hi,

...

Wobei ich zu bedenken geben möchte, dass ich das gvinum Raid5 set erst nach einem cvsup auf RELENG_5 aufbauen wollte ...

Ich muss mal gucken, ob ich noch passende CD's hier rumliegen habe. Ansonsten wird's wohl wieder eine FTP-Installation werden. (ich hoffe, damit gibts keine Probleme, bzw. eher positive Erfahrungen)

Was mich irritiert ... dann waren die Angaben aus dem fdisk ad0 und dem bsdlabel ad0s1 usw. nicht irgendwie auffällig? Ich hatte ja schon fast gehofft, dass da ein Fehler zu finden ist und ich endlich einen Ansatzpunkt habe ... ;-)

Grüße + Danke

Hazelnut

 

[ouTi]

in current hab es hierzu gestern einen commit. ic hweiss nicht, ob es genau dieses problem trifft, da ich
1. diesen thread nur überflogen habe
2. vinum/gvinum noch nie eingesetzt habe

aber hier die commit-message:

Fix a stupid logic bug introduced in geom_vinum_drive.c rev 1.18:

When a drive is newly created, it's state is initially set to 'down',
so it won't allow saving the config to it (thus it will never know of
itself being created). Work around this by adding a new flag, that's
also checked when saving the config to a drive.

original nachzulesen unter: http://lists.freebsd.org/pipermail/cvs-src/2005-August/050939.html

 

[Azazyel]

in current hab es hierzu gestern einen commit. ic hweiss nicht, ob es genau dieses problem trifft, da ich
1. diesen thread nur überflogen habe
2. vinum/gvinum noch nie eingesetzt habe

Das sieht haargenau nach der Lösung von hazelnuts Problem aus.

Ohne das System zu patchen, könnte noch folgender Workaround funktionieren:

gvinum -> setstate up raid51
gvinum -> setstate up raid52
gvinum -> setstate up raid53
gvinum -> setstate up raid54
gvinum -> setstate up raid55
gvinum -> setstate up raid56

 

[hazelnut]

Hi,

also ich hab mir heut mal die Zeit genommen, das OS gänzlich neu aufzusetzen (5.4 via FTP). Offensichtlich war das wirklich der Fehler... Aktuell sieht das jetzt so aus:

gvinum -> list
6 drives:
D raid51 State: up /dev/ad0s1d A: 0/157065 MB (0%)
D raid52 State: up /dev/ad2s1d A: 0/157065 MB (0%)
D raid53 State: up /dev/ad8s1d A: 0/157065 MB (0%)
D raid54 State: up /dev/ad10s1d A: 0/157065 MB (0%)
D raid55 State: up /dev/ad12s1d A: 0/157065 MB (0%)
D raid56 State: up /dev/ad14s1d A: 0/157065 MB (0%)

1 volume:
V data State: up Plexes: 1 Size: 766 GB

1 plex:
P data.p0 R5 State: up Subdisks: 6 Size: 766 GB

6 subdisks:
S data.p0.s0 State: up D: raid51 Size: 153 GB
S data.p0.s1 State: up D: raid52 Size: 153 GB
S data.p0.s2 State: up D: raid53 Size: 153 GB
S data.p0.s3 State: up D: raid54 Size: 153 GB
S data.p0.s4 State: up D: raid55 Size: 153 GB
S data.p0.s5 State: up D: raid56 Size: 153 GB
gvinum ->

Die Schritte dahin waren ein

gvinum -> create /meine/config

gvinum -> saveconfig

reboot

gvinum -> list

und weil ich das berühmte R noch nicht gesehen habe ein

gvinum -> start data.p0

so, nun bin ich am Warten, auf das, was da jetzt kommen mag ....


... oder anders gefragt - wie erkenne ich, dass der das initialisiert? Irgendwie scheint der nämlich keine Anstalten in diese Richtung zu machen ... und auch top sagt mir was von 100% idle ...

:-)

Ansonsten dennoch erst einmal ein dickes Danke an euch! Weil, ich war hier schon wieder am verzweifeln ...


Gruß

Hazel

 

[Azazyel]

1 volume:
V data State: up Plexes: 1 Size: 766 GB

[...]

... oder anders gefragt - wie erkenne ich, dass der das initialisiert? Irgendwie scheint der nämlich keine Anstalten in diese Richtung zu machen ... und auch top sagt mir was von 100% idle ...

Das Array ist schon up, es ist fertig und einsatzbereit. Ich würde es zum testen einfach mal mounten und mittels dd if=/dev/zero of=/mnt/raid5 bs=256k vollschreiben.

Spaßeshalber kannst du danach mal ein checkparity oder rebuildparity in gvinum machen, falls dir das System zu sehr im Idle-Status herumdümpelt.

 

[hazelnut]

Hi,

checkparity hab ich zwar nicht gemacht, aber er ist mit einem rebuildparity schon eine kleine Weile beschäftigt. Systemauslastung beträgt ca. 50%. :-) Allerdings rattern hier auch jede Menge Meldungen der Form :
...
Parity incorrect at offset 0x16d640000
...
durch.

Mal sehen, was da kommt, und wann er damit fertig ist ... danach kommt dann auch das checkparity und noch eine Rückmeldung von mir ...

So, bleibt nur noch die Frage, ob sich das ganze auch mit GBDE verträgt ... aber ich denke, das gehört hier nicht mehr so wirklich hin ...

Dann Danke ich für die Hilfe und die Mühe!

Grüße

Hazelnut

 

[Azazyel]

checkparity hab ich zwar nicht gemacht, aber er ist mit einem rebuildparity schon eine kleine Weile beschäftigt. Systemauslastung beträgt ca. 50%. :-) Allerdings rattern hier auch jede Menge Meldungen der Form :
...
Parity incorrect at offset 0x16d640000
...
durch.

Das hat seine Richtigkeit, die Parität wird ja erst beim ersten Schreibvorgang eines Blocks gesetzt. Bis dahin sind ja die vorherigen Daten auf der Festplatte, die natürlich bei der Paritätsprüfung nicht stimmen.

So, bleibt nur noch die Frage, ob sich das ganze auch mit GBDE verträgt ... aber ich denke, das gehört hier nicht mehr so wirklich hin ...

Ich habe es hier auch mit GBDE laufen, funktioniert makellos. Das einzige Manko ist die Performance, ein fsck dauert gute fünf Minuten und der Durchsatz beim Schreiben ist auch nicht gerade berauschend.

 

[hazelnut]

Hi,

Ich habe es hier auch mit GBDE laufen, funktioniert makellos. Das einzige Manko ist die Performance, ein fsck dauert gute fünf Minuten und der Durchsatz beim Schreiben ist auch nicht gerade berauschend.

sei vorsichtig mit dem, was du mir da sagst ... :-) Gut zu wissen, dass das mit GBDE geht. Hatte im IRC schon mal nachgefragt, aber keine Rückmeldung bekommen ...

Gibts beim Schreibdurchsatz noch optionen? Ich meine, ich hab hier bewusst bei den zwei IDE-HDD's die dabei sind nur einen Kanal belegt. Die anderen 4 sind SATA, da sollte das auch so gehen ... Wobei ich eh davon ausgehe, dass das eigentliche Performance-Problem woanders liegt ...

Na mal sehen, was sich ergibt. Ich poste das dann hier ...

Im Übrigen ist er noch mit dem rebuildparity beschäftigt ;-)

n8 + Gruß

Hazel

 

[Azazyel]

Gibts beim Schreibdurchsatz noch optionen? Ich meine, ich hab hier bewusst bei den zwei IDE-HDD's die dabei sind nur einen Kanal belegt. Die anderen 4 sind SATA, da sollte das auch so gehen ... Wobei ich eh davon ausgehe, dass das eigentliche Performance-Problem woanders liegt ...

Du hast Recht, selbst UDMA/33 ist nur in den wenigsten Fällen der Flaschenhals.

Das Performance-Problem liegt eher daran, dass zum einen RAID 5 beim Schreiben prinzipiell nicht sehr schnell ist, es durch eine Software-Lösung nicht schneller wird und GBDE obendrauf nochmal als Bremse wirkt.
Ich komme bei einem 650er Athlon auf rund 4 MB/s Durchsatz beim Schreiben, die Leseleistung beträgt rund 8 MB/s (jeweils mit GBDE). Hier wirkt allerdings der Prozessor als limitierender Faktor.

Im Übrigen ist er noch mit dem rebuildparity beschäftigt ;-)

Das ist der Nachteil der Software-Lösung, man wartet bei solchen Aktionen eine geraume Weile, während die Systemlast nicht unerheblich ist.

 

[marzl]

Ich komme bei einem 650er Athlon auf rund 4 MB/s Durchsatz beim Schreiben, die Leseleistung beträgt rund 8 MB/s (jeweils mit GBDE). Hier wirkt allerdings der Prozessor als limitierender Faktor.

Richtig. Software is nunmal Software. Nicht umsonst haben echte Raidcontroller eine RISC-CPU mit massig Speicher verbaut. Je höher also der Prozessor und niedriger die Systemlast, desto schneller das Vinum. Ich hab einen 2,4 GHz Athlon mit ca 3,5 Mb/s beim schreiben. Lesen ist unerheblich, da diese keine Rechenoperationen nach sich zieht. Hier sollte das Netzwerk der limitierende Faktor sein

 

[Maledictus]

Mal so ne Frage am Rande:
Wo finde ich Dokumentation zu gvinum raid5?

 

[Azazyel]

Mal so ne Frage am Rande:
Wo finde ich Dokumentation zu gvinum raid5?

Leider gibt es zu gvinum selber noch fast gar keine Dokumentation, man kann aber fast alles von vinum 1:1 auf gvinum anwenden. Ansonsten ist man auf viel ausprobieren und die Suche in Foren angewiesen.

 

[free]

Das haette ich schon vor ein paar Monaten tun wollen/sollen:
http://wiki.bsdforen.de/index.php/FreeBSD_-_RAID5_mit_gvinum