Raid5 erstellen und verwalten, womit?

pit234a

pit234a

Well-Known Member
Hi.
Ich denke, bei Installation kann ich das mal fragen, denn ich bin ja gerade dabei (von Zeit zu Zeit) an der Installation meines zukünftigen Fileservers zu basteln. Im Grunde würde eine FreeNAS wahrscheinlich alles leisten, was ich brauche, aber, weil ich kein langsames Motherboard mehr bekommen konnte, möchte ich den Rechner auch noch ein wenig weiter nutzen und deshalb wird es vermutlich eher eine Vollinstallation von FreeBSD, die auf einem seperaten Medium landet.
Die eingebauten Festplatten möchte ich zu einem Raid5 Verband zusammenfassen. Darauf kommt dann ein Verzeichnisbaum, der halt exportiert wird.
Nun lese ich schon eine Weile im FreeBSD Handbuch und fand da ccd und gvinum und geom und bin darob verwirrt. Im WIKI finde ich auch nichts darüber und so frage ich halt mal nach.

Es wird wohl so sein, daß ich gvinum brauche und als Modul laden lasse, das leuchtet mir soweit ein. Doch, wie konfiguriere ich die fünf Platten als Raid5? Muß ich da jeden Stripe einzeln angeben oder wie? Und wie kann ich den Raid später verwalten, evtl mal ne Platte austauschen und so.
Gibt es vielleicht gar ein grafisches Tool dafür (in FreeNAS zeigen die Screenshots eine einfache Umsetzung).
Wo kann ich denn etwas dazu nachlesen?
Es geht mir nicht um das grundlegende Verständnis von raids, ich nutze schon lange immer wieder Raid-Verbände, allerdings meist HW-Controlled und nur sehr selten mal unter Linux und damals gab es auch ein einfaches, grafisches Frontend, wenn ich mich recht entsinne.
 
Hey.

Ich nutze das GEOM Framework für Encryption und Mirroring. Für ein RAID-5 benötigst du das gvinum(8) Modul. Guck dir auch mal die anderen geom-manpages an. Die sind gut dokumentiert und auch mit Beispielen versehen die man einfach mal ausprobieren kann.

Mit ccd habe ich keine Erfahrungen.

Falls deine Maschine über genug RAM verfügt könnte ZFS vielleicht auch interessant sein...

Ich plappere nur.......xcvb :)
 
ZFS könnte vielleicht wirklich mal was werden, aber nicht nur lokal.
Derzeit betreibe ich schon einen so genannten NAS, wo ich mehrere Platten Raid5 mittels HW-Controller verschaltet habe und ein busybox-Linux die Prozesse steuert. Das ist aber nicht frei, die Leute haben da alles schön dicht gemacht (ein Thecus N5200) und weil ich vieles gar nicht brauche, anderes aber will, versuche ich es nun mal mit FreeBSD und es läuft gerade die Vollinstallation, was eigentlich dumm ist. Ich werde den rechner (vermutlich) nicht auch als Desktop-PC verwenden, doch wenn genug Platz auf dem Stick sein sollte, kann das auch laufen.
Also, schaue ich mir mal gvinum an. Vielleicht verstehe ich ja was in der man, aus dem Handbuch ist es mir nicht klar geworden, was ich da machen muß.
Danke mal.
 
Naja, so viel plapperst du eigentlich gar nicht. Die Geschichte ist so, dass es früher zu Zeiten von FreeBSD 4 einmal "vinum" gab. Das Ding war ein Klon des im professionellen Bereich lange Zeit sehr beliebten Veritas Volume Managers und auch unter FreeBSD nutzte man ihn trotz seines komplexen Konzeptes recht gern. Dann kam FreeBSD 5 und mit ihm das GEOM-Framework. Die Änderungen am Kernel sorgten aber dafür, dass der klassische vinum nicht mehr funktionierte. Also begann man ihn auf GEOM zu portieren, dass Ding ist dann gvinum. Nun war es aber so, dass gvinum lange Zeit gar nicht vorwärts kam. Bugs ohne Ende und vor allem fehlende Funktionen. So konnte man ein zerstörtes RAID nicht neu aufbauen, man musste die Daten auskopieren und es neu erstellen. Das war dumm. Dann jedoch kam ein Entwickler und reparierte im Rahmen des Google Summer of Code das Ding. Wenn du also einen gvinum willst, nehme auf jeden Fall FreeBSD 7. In allen vorherigen Versionen ist er gefährlich. FreeNAS wiederum wartete nicht auf gvinum und nutzt es auch nicht. Sie haben ihr eugenes graid5, welches allerdings nie Teil von FreeBSD wurde, da es einige sehr schwere Bedenken gegen dessen Zuverlässigkeit im Falle eines Stromausfalls oder Absturz gibt / gab.

Nachteilig an gvinum ist vor allem seine sehr komplexe Struktur. Das mit den "Plexes" zu kapieren ist nicht ganz ohne. Hat man es aber mal, ist gvinum ein sehr mächtiges Werkzeug. Die Manpage versucht es zu erklären, dass Handbuch ebenfalls: http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/vinum-vinum.html Jetztendlich ist aber wirklich das beste mal den Qemu oder ähnliches anzuschmeißen und zu spielen. Auch mal die Fälle, dass man eine Platte herauszieht und so. Nur dann wird es wirklich klar.
 
ok, ich gebe zu, daß ich da nicht so gaaanz durchblicke. Meine Suche im www brachte aber diesen, leicht verständlichen Beitrag, der offenbar erfolgreich war:
FreeBSD : RAID5 with gvinum (non-boot)


GEEK00L was wondering whether I have messed around with software based RAID5 under FreeBSD. He needs to set up the same on FreeBSD at work. Since I have not touched anything on RAID5, I gave it a shot and it turned out to be relatively easy. More or less the setup concept is similar to gmirror configuration.
SETUP SCENARIO
3 identical IDE HDD were used in this configuration. (4 identical IDE HDD actually. I will use ad0 in gvinum RAID5 with root in the near future.)

ad0: 76319MB < MAXTOR STM3802110A 3.AAJ> at ata0-master UDMA100
ad1: 76319MB < MAXTOR STM3802110A 3.AAJ> at ata0-slave UDMA100
ad2: 76319MB < MAXTOR STM3802110A 3.AAJ> at ata1-master UDMA100
ad3: 76319MB < MAXTOR STM3802110A 3.AAJ> at ata1-slave UDMA100

DISK PREPARATION
You can skip this step if you are using new hdd. or Probably just do the following and clean them up.

# dd if=/dev/zero of=/dev/ad1 bs=512 count=79
# dd if=/dev/zero of=/dev/ad2 bs=512 count=79
# dd if=/dev/zero of=/dev/ad3 bs=512 count=79

Disk formatting
The hard way:-

# fdisk -v -B -I /dev/ad1
# fdisk -v -B -I /dev/ad2
# fdisk -v -B -I /dev/ad3
# bsdlabel -w -B ad1s1
# bsdlabel -w -B ad2s1
# bsdlabel -w -B ad3s1
# bsdlabel -e ad1s1

# /dev/ad1s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 156301425 0 unused 0 0 # "raw" part, don't edit
d: 156301425 0 4.2BSD 2048 16384 28552
The above size is for my own configuration. Please amend according to your system.
Creating disk protofile

bsdlabel ad1s1 > label.ad1s1

Restoring disk protofile

bsdlabel -R ad2s1 label.ad1s1
bsdlabel -R ad3s1 label.ad1s1

The easy way, you can use sysinstall to partition the hdd.
RAID VOLUME CONFIGURATION
Create a gvinum raid volume configuration file.


# vi raid.conf
drive d1 device /dev/ad1s1d
drive d2 device /dev/ad2s1d
drive d3 device /dev/ad3s1d

volume rvol
plex org raid5 512k
sd drive d1
sd drive d2
sd drive d3

Initializing gvinum


# kldload geom_vinum
# gvinum create raid.conf

3 drives:
D d3 State: up /dev/ad3s1 A: 0/76318 MB (0%)
D d2 State: up /dev/ad2s1 A: 0/76318 MB (0%)
D d1 State: up /dev/ad1s1 A: 0/76318 MB (0%)1 volume:
V rvol State: up Plexes: 1 Size: 149 GB
1 plex:
P rvol.p0 R5 State: up Subdisks: 3 Size: 149 GB
3 subdisks:
S rvol.p0.s2 State: up D: d3 Size: 74 GB
S rvol.p0.s1 State: up D: d2 Size: 74 GB
S rvol.p0.s0 State: up D: d1 Size: 74 GB

Saving the gvinum configuration

# gvinum start rvol
# gvinum saveconfig

In dmesg, you will see these messages. It seems that I have some issues with stripe size. I will iron out this next time as it is still in working stage.

gvinum: size of sd rvol.p0.s0 is not a multiple of plex stripesize, taking off 446464 bytes
gvinum: size of sd rvol.p0.s1 is not a multiple of plex stripesize, taking off 446464 bytes
gvinum: size of sd rvol.p0.s2 is not a multiple of plex stripesize, taking off 446464 bytes

GEOM_VINUM: subdisk rvol.p0.s2 state change: stale -> up
GEOM_VINUM: subdisk rvol.p0.s1 state change: stale -> up
GEOM_VINUM: plex rvol.p0 state change: down -> degraded
GEOM_VINUM: subdisk rvol.p0.s0 state change: stale -> up
GEOM_VINUM: plex rvol.p0 state change: degraded -> up


The gvinum is a rather user-friendly tool. You can display the raid volume by issuing gvinum list. Apart from this, you drop down to its command prompt by just invoking gvinum.


# gvinum
gvinum -> help

COMMANDS
checkparity [-f] plex
Check the parity blocks of a RAID-5 plex.
create description-file
Create as per description-file or open editor.
l | list [-r] [-v] [-V] [volume | plex | subdisk]
List information about specified objects.
ld [-r] [-v] [-V] [volume]
List information about drives.
ls [-r] [-v] [-V] [subdisk]
List information about subdisks.
lp [-r] [-v] [-V] [plex]
List information about plexes.
lv [-r] [-v] [-V] [volume]
List information about volumes.
move | mv -f drive object ...
Move the object(s) to the specified drive.
quit Exit the vinum program when running in interactive mode. Nor-
mally this would be done by entering the EOF character.
rename [-r] [drive | subdisk | plex | volume] newname
Change the name of the specified object.
rebuildparity plex [-f]
Rebuild the parity blocks of a RAID-5 plex.
rm [-r] volume | plex | subdisk | drive
Remove an object.
saveconfig
Save vinum configuration to disk after configuration failures.
setstate [-f] state [volume | plex | subdisk | drive]
Set state without influencing other objects, for diagnostic pur-
poses only.
start [-S size] volume | plex | subdisk
Allow the system to access the objects.
gvinum ->

FORMAT AND MOUNT GVINUM RAID5 VOLUME

# newfs /dev/gvinum/rvol
# mount /dev/gvinum/rvol /mnt

Note : Replace rvol with whatever volume name you’ve set in raid.conf. In my case, it is volume “rvol”.
Loading gvinum upon boot
Edit /boot/loader.conf and set :-

geom_vinum_load="YES"

Remember to edit /etc/fstab to enable mounting on boot.
Zum Vergrößern anklicken....
Das sieht ja zunächst mal gut aus und beschreibt ziemlich, was ich will und das verstehe ich auch fast und kann es recht gut nachvollziehen.
Außer dieses da:
# bsdlabel -e ad1s1

# /dev/ad1s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 156301425 0 unused 0 0 # "raw" part, don't edit
d: 156301425 0 4.2BSD 2048 16384 28552
The above size is for my own configuration. Please amend according to your system.
Creating disk protofile

bsdlabel ad1s1 > label.ad1s1

Restoring disk protofile

bsdlabel -R ad2s1 label.ad1s1
bsdlabel -R ad3s1 label.ad1s1
Zum Vergrößern anklicken....
Also, daß mit -R nun der editierte Label auf die anderen Disks übernommen wird, verstehe ich ja noch. Aber was editiert der da überhaupt? Wenn ich doch die gesamte Platte nutzen will, kann ich dort meinetwegen ja eine Partition anlegen, aber was sagt denn dort bsdlabel es seien 8 Partitionen und was soll das mit dieser Größe? Ich hätte es aus meinem Verständnis heraus ohne diesen Schritt getan. Bis dahin sollten doch alle Platten gleich sein, eine Partition bekommen haben und die bsdlabel deshalb auch gleich sein. Vielleicht kann mir das erklärt werden?

Mit raid.conf ist sicher die /etc/raid.conf gemeint.
 
bsdlabel -e wirft dich in einen editor zum editieren des disklabels vom gewünschten slice. bei meinem system sieht das momentan so aus:
Code: 
$ sudo bsdlabel -e /dev/ad1s1

# /dev/ad1s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  2097152  4194304    4.2BSD        0     0     0
  b:  4194304        0      swap
  c: 240107427        0    unused        0     0         # "raw" part, don't edi
t
  d: 56623104  6291456    4.2BSD        0     0     0
  f:  2097152 62914560    4.2BSD        0     0     0
  g: 10485760 65011712    4.2BSD        0     0     0
  h: 164609955 75497472    4.2BSD        0     0     0
eine leere festplatte ohne slices und labels hat nur die partition/disklabel "c". das steht für die gesamte platte. also wird ein label gleicher größe - man möchte ja die gesamte platte nutzen - angelegt und das für die daten verwendet ("a" ist meistens / und "b" meistens swap, daher hier "d"). das mit den 8 partitions steht da immer, weil das die maximale anzahl der labels, oder eben partitionen, ist. lass dich von den bezeichnungen nicht verwirren.
die größe der verwendete partition, in diesem falle "d", ist wohl kein vielfaches der stripesize, die gvinum verwendet (ich hab das jetzt nicht nachgerechnet). darauf muss wohl auch geachtet werden, laut fehlermeldung beim starten.
 
ah ja, das macht es etwas klarer, aber was editiert der denn dann?
Wie ich das sehe, nutzt er doch die gesamte Partition die er eben erstellt hat. Wenn ich bei nachsehe, sieht das nämlich grad so aus, wie bei ihm im Beispiel.
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 16048872 0 4.2BSD 2048 16384 28552
c: 16048872 0 unused 0 0 # "raw" part, don't edit
Zum Vergrößern anklicken....
Bei mir ist das ein Stick mit einer einzigen Partition mit alles drauf.
Da ist doch der Label dann schon richtig und vorhanden, weshalb nimmt er den von der ersten Platte dann für die beiden anderen? Die müssten doch gleich sein? Es sieht nicht so aus, als habe er da wirklich was editiert. Vielleicht wollte er nur die Möglichkeit zeigen, eben wegen dieser Geschichte mit den stripesize. Die ist ja dann wohl mit
plex org raid5 512k
Zum Vergrößern anklicken....
festgelegt? Ist das nicht eigentlich recht wenig? da gibt es ja eine ganze Menge von stripes und einen gewaltigen Aufwand, dies zu verwalten. Es kommt ja dann auch noch das filesystem auf diesen raid, also auf diese Stripes.
Ah näh, das hört sich aber nicht richtig an. Die Platten sind doch immer vielfache von 1024 und müssten dann doch auch mit 512k stripes hinkommen. Das muß wohl doch was anderes sein. Die plexes und die subdisks gehen mir noch nicht recht unter.
 
also die partition, die er mit disklabel erstellt, nennt sich "d", weil da nur daten draufkommen. er hat eben gezeigt, dass er die ganze partition nimmt. welchen buchstaben die nun hat, ist wurscht (außer "c", aber eben der übersichtlichkeit halber "d"). damit die beiden anderen platten dann das gleiche layout haben, schreibt er es per "bsdlabel" in eine datei und importiert die dann in bsdlabel um die beiden anderen platten zu bügeln und die dann das gleiche layout in diesem falle haben (neue festplatten haben weder partitionen geschweige denn disklabels).
bei deinem stick ist es ähnlich, da du allerdings sowieso eine rootpartition hast, ist bei dir eben nur "a" vorhanden. bei hardware raids ist es doch genau dasselbe, nur das der controller eben die platten ansteuert, was jetzt das system noch mit macht. der controller stellt dann dem system eine logische festplatte zur verfügung (hier das gvinum device), darauf kommt ein filesystem und eben die daten. was soll daran nicht richtig sein?
 
# fdisk -v -B -I /dev/ad1
# bsdlabel -w -B ad1s1

Hi.
Ja, den Vorgang an sich habe ich verstanden und daß die Platten als ein gvinum device zusammengefaßt werden, das ist auch klar.
Aber, mit diesen Befehlen da oben werden doch die Label bereits angelegt und die Partitionen erstellt, oder nicht? Das macht er bei allen Platten, dann müssten die doch alle gleich sein und ich brauche doch nichts mehr zu editieren und zu übernehmen. Oder macht das mir nur leere bsd-label? Dann verstehe ich den Rest, ich glaubte, daß damit schon eine Partition erstellt und eingetragen wird.

Nicht richtig wollte ich meinen Gedanken abtun, daß plex org raid5 512k die stripegröße eines plexes bestimmt und auf 512k festlegt.

Vielleicht sollte ich es wirklich einfach mal probieren, das hilft ja manchmal....
 
ok, konnte eine Platte mal überreden und nach
# fdisk -v -B -I /dev/ad6
# bsdlabel -w -B ad6s1
zeigt bsdlabel -e ad6s1:
# /dev/ad6s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 1953525089 16 unused 0 0
c: 1953525105 0 unused 0 0 # "raw" part, don't edit
Zum Vergrößern anklicken....
Es ist also schon eine Partitionstabelle angelegt und eine Partition eingetragen, der ist aber kein Filesystem zugeordnet, was mich nicht wundert, denn das würde ja im nächsten Schritt erst newfs machen. Das brauche ich aber nun nicht, weil ich es später ja auf den Raid anwenden will. mhmm. Mal sehen.
 
so.
wie oben erklärt, machte ich also nur dieses fdisk und bsdlabel und legte dann eine raid.conf an:
Code: 
files# cat /etc/raid.conf
drive d1 device /dev/ad6s1a
drive d2 device /dev/ad7s1a
drive d3 device /dev/ad8s1a
drive d4 device /dev/ad9s1a
drive d5 device /dev/ad10s1a

volume raid1
plex org raid5 512k
sd drive d1
sd drive d2
sd drive d3
sd drive d4
sd drive d5

des weiteren folgte ich dann wieder den Anweisungen, erhielt mein gvinum device und konnte darauf ein newfs anlegen und dann auch mounten. Es steht mir nun zur Verfügung. bsdlabel -e machte ich also nicht.
dmesg zeigte auch solche stripe-Meldungen, daß da was gekürzt werden muß, aber ansonsten scheint das kein Problem gewesen zu sein.
Natürlich habe ich dann entsprechend auch nicht "d" genommen, sondern "a", wo ja meine erste und einzige Partition automatisch landet.
Von den Plexen und Subdisks sieht man zunächst gar nichts, nur gvinum gibt entsprechende Meldungen beim Erstellen aus.

Ich würde grob sagen, daß dies zunächst mal funktioniert hat. Dafür also meinen besten Dank.

Nun muß ich noch sehen, warum mir die Platten nur als UDMA33 eingetragen sind, obwohl sie richtig als SATAII erkannt sind. Vielleicht wegen des noch vorhandenen DVD Laufwerks, das ich mit langsamem Kabel angeschlossen habe. Dann wäre das zwar Mist, wenn die Kanäle nicht getrennt sind, aber das ist dann auch wieder leicht zu lösen, DVD-Laufwerk brauche ich da nicht wirklich.
Außerdem wird mein Stick wohl doch zu knapp, ich hätte nicht so viele Pakete auswählen sollen! Vielleicht lege ich dann später das System doch noch auf den Raid oder wenigstens Teile davon, mal sehen.

Also, nochmals Dank.
 
noch was: wie lege ich denn diesen raid am besten schlafen?
Weil, in der Nacht, brauche ich ihn eigentlich nicht und wollte nach 30Minuten ohne Zugriff die Platten schlafen schicken. ataidle macht mir das irgendwie bei einzelnen Platten, manchmal konnte ich die nicht wieder beleben, nicht so einfach jedenfalls. Nun würde ich gerne den ganzen Verband auf einmal zur Ruhe schicken, gibt es da was? oder atacontrol und für jede Platte setzen und das beim booten in einem startscript?
 
bin ganz schön erstaunt. Irgendwas ist mir abgeschmiert, ein Neustart des PCs fand statt und ich nutzte die Gelegenheit, nach diesem UDMA33 Problem zu sehen und fand, daß eine Bios-Einstellung von IDE auf AHCI geändert werden mußte. Damit wurden meine Platten nun richtig erkannt, aber als ad6, 8, 10, 12 und 14, also anders als bisher und tatsächlich hat gvinum das trotzdem erkannt und richtig zusammengesetzt, mein Raid ist immer noch da! Wunderbar!
 
Also, bevor ich nun das Handtuch werfe, will ich doch lieber nachfragen, ob es nicht irgendeine Chance gibt, die Daten von meinem neuen Raid noch zu retten. Das ist nämlich bereits kaputt und ich sehe keine Möglichkeit mehr, daraud zuzugreifen. Was schade ist, weil da einige Dinge dabei sind, die ich nicht mehr doppelt gesichert habe.

Was passierte: Es fiel mir auf, daß ich eine Grottenschlechte Performance hatte. Als nächstes merkte ich, daß der PC scheinbar gelegentlich einfach einen Neustart absolvierte. Ich dachte mir nicht viel dabei, startete den Übertragungsvorgang neu und kümmerte mich nicht weiter darum, bis das dann etwa viermal passiert war. Da setzte ich mich vor den PC und sah ihm mal zu, um festzustellen, daß eine Platte aus dem Verband als down gemeldet wurde. Huch, die waren zwar alle fünf neu, doch sowas kann ja mal vorkommen. Nun hätte ich eigentlich erwartet, daß da nichts weiter furchbares passiert, denn dazu hat man schließlich Raid und ich machte mich daran, die Bestellnummer für eine Ersatzplatte zu suchen, da merkte ich, daß eine wilde Aktivität auf den Platten einsetzte und dacht ebi mir: logisch, der Background-fsck. Das fand ich auch bestätigt und nach einer Weile stürzte dann der PC ab und bootete neu.
Im Single-User Modus versuchte ich dann auch fsck auf den Raid und wieder kam dieser Absturz. Dann versuchte ich, die defekte Platte aus dem Raid abzumelden und konnte nun zwar einen fsck aufrufen, ohne daß der PC wieder abstürzte, dafür war der aber erfolglos, kann einige Sektoren nicht lesen, ioctl sei inappropriate für dieses Device (den Raid) und fsck kann den disk label auch nicht davon lesen.
Da steh ich nun.
Den Raid kann ich so zwar mounten, doch da kann ich nichts mit anfangen. Es werden mir nur irgendwelche Zeichen angezeigt, die nicht sinnvoll sind, kein Verzeichnis und keine Daten.
Nun ist es schlecht, wenn man sich wenig auskennt und nicht helfen kann.
Fast möchte ich wieder von vorne anfangen, aber wenn ich das so sehe, bin ich vielleicht mit einem HW-Controller doch besser bedient. Da schiebe ich doch einfach meine neue HD rein und lasse mir den Raid neu bauen, das geht ganz zauberhaft und irgendwie hätte ich mir sowas von einem SW-Raid auch erwartet. Der müsste doch auch noch funktionieren, wenn eine Platte fehlt und nicht solchen Ärger bringen.
Es sieht ganz danach aus, als sei das Hauptproblem der Background.fsck gewesen, der damit einfach nicht zu Recht kam, daß da was fehlte, daraufhin zum Absturz führte und die Sache immer schlimmer machte.

Vielleicht gibt es aber noch Hinweise, die dazu führen, mich wieder zu meinen Daten zu bringen. Ansonsten muß ich wohl einige Filme abschreiben. Naja, dann wird halt mehr gelesen...
 
Also, falls noch jemand hier liest, Hinweise brauche ich nicht mehr, ich habe es aufgegeben und einen Raid neu gebaut. Diesmal ganz ohne die Platten vorzubereiten, lediglich mit dd if=/dev/zero... die alten Informationen gelöscht.
Dann einfach eine raid.conf angelegt und darin die Bezeichnungen der Platten direkt gewählt, keine Partitionen oder Slices angegeben. gvinum ist zwar so flexibel, doch ich wollte ja einen Raid aus allen Platten und weil das Filesystem da nachher eh auf das /dev/gvinum gelegt wird, brauche ich hier keine Partitionierung bei den Platten. Ob es denn ginge, Partitionen auf dem gvinum device anzulegen, probierte ich nicht. Stattdessen ließ ich gleich einen raid bauen und dann ein newfs anlegen. mounten testen und alles automatisieren. Sieht dann so aus:
Code: 
5 drives:
D d5                    State: up       /dev/ad14       A: 0/953869 MB (0%)
D d4                    State: up       /dev/ad12       A: 0/953869 MB (0%)
D d3                    State: up       /dev/ad10       A: 0/953869 MB (0%)
D d2                    State: up       /dev/ad8        A: 0/953869 MB (0%)
D d1                    State: up       /dev/ad6        A: 0/953869 MB (0%)

1 volume:
V raid1                 State: up       Plexes:       1 Size:       3726 GB

1 plex:
P raid1.p0           R5 State: up       Subdisks:     5 Size:       3726 GB

5 subdisks:
S raid1.p0.s0           State: up       D: d1           Size:        931 GB
S raid1.p0.s1           State: up       D: d2           Size:        931 GB
S raid1.p0.s2           State: up       D: d3           Size:        931 GB
S raid1.p0.s3           State: up       D: d4           Size:        931 GB
S raid1.p0.s4           State: up       D: d5           Size:        931 GB
Sehr seltsam: die vorhin defekte Platte hat sich wieder gemeldet.

Ich hatte softupdates gewählt und ich hatte die Platten mit atacontrol einen spindown machen lassen, wenn 30 Minuten nicht zugegriffen wird. Weil mein Stick zu klein war, hatte ich /usr auf den Raid gelegt. Das war natürlich unbedacht, denn sowas lässt man dann ja nicht schlafen! Auch softupdates machen da vielleicht Ärger, wenn die Platten wegtauchen. Keine Ahnung, irgendwas muss passiert sein, das mir das Filesystem auf dem raid übel zerschossen hat.
Vielleicht habe ich auch einen HW-Defekt im PC, der gelegentliche Abstürze verursacht. Ich muß das mal weiter im Auge behalten.
 
kleinen Update nach einigen Tagen Betrieb und Wirklichkeit mit diesem raid:

Wirklichkeit meint, daß drei bis vier andere PCs bisher auf den Raid Zugriff haben und ausreichend Daten zum Testen hier vorhanden sind. Der neue Raid hat hier voll die Aufgaben des alten übernommen.
Die Syntax der exports will allerdings noch nicht, was ich gerne möchte. Das versteh ich nicht.

Das größte Problem bei der Zuverlässigkeit ist aber, daß ich den raid nicht schlafen lassen darf. Auch, wenn er nur Daten enthält, also keine Teile des Betriebssystems: er wacht nicht wieder zuverlässig auf! Also, Platten spindown, das kann üble Folgen haben. Muß aber nicht. Es funktionierte eine Weile sehr gut, aber dann kamm irgendeine Platte leicht aus dem Tritt und der raid galt als beschädigt. Anschließender Neustart fing die Platte von selbst wieder und fsck konnte die Daten wieder ordnen. Aber einmal ging es ja bereits schief, das ist also nicht gut und deshalb mein erstes Resümee: lass die Platten laufen.

Von den Problemen abgesehen funktioniert der Raid und der NFS Server gut und arbeitet mit allen Rechnern gut zusammen (busybox/Linux, GNU/Linux, FreeBSD und Mac OS-X).
 
Hallo Pit,

fuer den gvinum kann ich nicht sprechen, ich kenn nur den "grossen" Veritas Volume Manager und weiss das er schwer zu verstehen ist. Aber ein Raid schlafen zu legen halte ich grundsaetzlich fuer keine gute Idee, insbesondere wenn schon "richtige" Daten drauf sind und es sofort produktiv ist. Raid ist kein Backup, RAID5 an sich auch nicht besonders performant. Ausserdem das Risiko ins Write Hole zu fallen ist auch nicht gerade lecker.

Auch die Write Performance bei RAID5 ist nicht gerade der Ueberhammer, im Gegenteil
Ich wuerde ernsthaft ueberlegen ob es nicht Sinn macht auf ZFS und Raid Z zu setzen.
Die Vorteile liegen meiner Meinung nach auf der Hand. Transaktionsorientiertes Dateisystem und nicht read modify write

Ich wuerde Dir zu dem Thema auch Vergleich RAID5 und RAID Z das folgende PDF ans Herz legen.

Vielleicht hilft es Dir ja weiter, informativ ist es in jedem Fall.
 
@solarix
Danke für den Hinweis und den Link, werde ich mir gewiss demnächst ansehen.

Nun, schlafen legen oder nicht, das sind immer wieder Diskussionen die ich auch schon lange führe. Es ist sicherlich nicht zu vertreten, eine Platte alle paar Minuten aufzuwecken um irgendein Journal aufzufrischen. Hier liegen aber wirklich nur Daten auf meinem Raid, keine Teile eines Systems und ich nutze kein Journal, mounte noatime und ich weiß, daß Nachts, wenn wir alle schlafen, kein weiterer Zugriff auf dieses raid erfolgt. Im Grunde genommen könnte ich den Rechner über Nacht komplett ausschalten und mit etwas überlegen, den dann über LAn mittels eines Cron-Jobs von Remote wieder wecken zu lassen.
Fünf Platten für mehrere Stunden garantiert unnütz bereit zu halten, das wollte ich vermeiden.
Auf dem busybox/Linux NAS kann ich die Platten problemlos schlafen schicken und das funktioniert seit etwas mehr als einem Jahr.

ZFS und RaidZ sind relativ neue Dinge und ich kenne davon nichts, sondern habe davon nur manchmal Überschriften gelesen.
Aus meiner Vergangenheit weiß ich, daß ich die Performance schon alleine durch geschicktes Verteilen der Daten auf mehrere SCSI-Platten deutlich erhöhen konnte. Nachdem ich mir unter GNU/Linux einen SW Raid einrichten konnte, brauchte ich mir keine Gedanken mehr über Datenverteilung zu machen. IDE und SCSI habe ich dann auch mit diversen HW Kontrollern immer wieder gehabt und bei IDE in der Regel Raid0 genommen und bei SCSI Raid5 und jedesmal war die Performance besser, als mit einzelnen Platten. Beste Ergebnisse hatte ich immer mit Raid5 und fünf SCSI-Platten. Das ist hinsichtlich Performance und Datensicherheit ein guter Kompromiss.
In den letzten drei Rechnern, die ich bekam (einschließlich des Thecus NAS) sind SATA Platten verbaut. Ich wähnte die ähnlich wie SCSI Platten. Sehe mich da aber wohl getäuscht.
SATA300 sollte schnell wie noch was sein. In dem kleinen busybox/Linux, der 512MBRam auf einer "schwachen" CPU hat, bekomme ich deutlich höhere Performance mit Raid5, als mit FreeBSD und gvinum, trotz deutlich schnellerer Umgebung. Garantiert ist das keine Frage der Rechnerleistung und weil eben auch der kleine Thecus SATA Platten nutzt, ist es sicher auch keine Frage der HW an sich.
Mein Gefühl war, daß ich was ungünstig konfiguriert habe und weil ich da nichts finden konnte, glaube ich an schlechte Implementierung des gvinum in FreeBSD.
Ich kenne mich zu wenig aus damit, um das qualifiziert behaupten zu können, aber vielleicht ist das nebenbei auch ein Grund für die FreeNAS Leute gewesen, was anderes zu nehmen.
Wenn ich das recht verstanden habe, bildet der Raid-Controller (ob HW oder SW) für das Betriebssystem ja eine physikalische Platte aus mehreren tatsächlich vorhandenen Platten nach. Er sorgt dabei für eine Verteilung der Daten auf diesen Platten, gemäß des gewählten Raid-Schemas. Wie die Daten beschaffen sind, also auch, welches Filesystem auf den Platten angelegt wird, interessiert den Raid nicht. Er hat nur die Aufgabe, die Platten zu bündeln und die Datenverteilung zu überwachen und schließlich dem Kernel/Betriebssystem eine einzige Platte vorzuspielen. Zusätzliche Funktionen, wie Erweiterung oder Reparatur des Verbandes, machen den Umgang damit komfortabel. gvinum schreibt auf jede Platte die wichtigen Informationen, die zum Betrieb des Raid nötig sind. Es könnte auch so gemacht werden, daß diese Information in einer extra reservierten Stelle auf der Systemdisk bereitgehalten und im Betrieb in eine Ramdisk geladen wird. Die unterschiedlichen Möglichkeiten haben unterschiedliche Vor- und Nachteile, doch ganz sicher ist der Weg von gvinum nicht gerade auf hohe Performance ausgelegt.
Wie gesagt, werde ich mich mal den anderen Möglichkeiten noch widmen.
 
Guten Morgen, komme grade von der Nachtschicht und habe Deinen Prost gerade noch gesehen und gelesen.

Zum Thema RAID Z kann ich Dir sagen das es manche unserer Kunden einsetzen (Solaris Maschinen) und die sind zufrieden.

Mit dem Hardwarecontroller hast Du Recht, der hat nur die Aufgabe das RAID bereit zu stellen, was Du drauf setzt, Haumichblau FS oder Buxtehudefilesystem interessiert den schon mal gar nicht.

Zum Thema SATA vs. Scsi und Konsorten, Sata wird Scsi oder Fibrechannel nie schlagen. Das ist einfach Crap.

Wie gesagt zum Gvinum kann ich nicht viel sagen, nur zum großen Original und das ist extrem performant. Falls Dich das Original interessiert Symantec stellt seinen Veritas Volumemanager als Basic Edition (Veritas Storedge Foundation) bereit, Die Edition unterliegt ein paar Beschränkungen wie begrenzte Anzahl der Volumes, aber Veritas selbst ist es herzlich egal wie groß das Volume dann am Ende ist. Allerdings ist die Lernkurve und der Abstraktionsgrad recht hoch, wie Yamagi korrekt erwähnt hat. Daher würde ich zu ZFS tendieren, da es doch wirklich einfacher zu handhaben ist, das einzige Problem was ich bei ZFS momentan sehe ist das Volumes nicht verkleinert werden können, sondern der Pool dann zerstört werden muss. Allerdings wird man im Privatbetrieb kaum den Pool verkleinern müssen.

Aber ich will Dir da nichts aufdrängen, Du musst am Ende wissen was Dir wichtig ist.

Wünsche Dir viel Erfolg und Spass mit Deinem RAID System. :)
 
Performance ist so eine Sache, die schwer zu schätzen ist. Und mindestens ebenso schwer objektiv zu messen. Führe zum Beispiel bonni++ oder iozone viermal aus. Du bekommst vier gänzlich unterschiedliche Ergebnisse. Ich würde über den Daumen geschätzt sagen, dass gvinum bei potenter Hardware (SAS-Platten, schnelle CPU) in etwa zwischen 25% und 30% langsamer als ein echter Veritas Volume Manager ist. Gerade auf Desktophardware kann es schnell grottenlahm werden, da die Controller die Bandbreite nicht hergeben, das S-ATA spinnt und das NCQ nicht will, etc. ZFS mit RaidZ ist hingegen deutlich schneller, aber auch nur aufgrund seines wirklich extremen Cachings. Es legt Unmengen Daten im RAM ab, gleicht dadurch die Probleme der Hardware zumindest teilweise aus. Zu dem was solarix sagte, ist dort eigentlich nichts hinzuzufügen, außer dass zumindest hier unter FreeBSD ein RaidZ nicht vergrößert werden. Ich weiß allerdings nicht, ob ZFS Version 13 in -CURRENT diese Funktionalität schon bietet.

Hardwareseitiges RAID hat gewisse Vorteile. Vor allem schont es die Haupt-CPU und den Arbeitsspeicher. Allerdings ist es - je nach Controller - auch unfexibler. Wenn du in die Richtung schaust, wäre dort sicher ein SAS-Controller und dazu SAS-Platten der Weg zu gehen. Die sind mit 7200 RPM gar nicht mal so viel teurer als klassisches S-ATA. 10.000 RPM oder gar 15.000 RPM sind natürlich deutlich schneller, was sich gerade bei einem RAID auszeichnet. Aber sie sind auch bedeutend teurer und du bekommst ganz neue Probleme. Zum Beispiel die richtige Kühlung der Platten ist dort zu nennen. Wichtig ist auch, dass der Controller eine Battery Backup Unit oder kurz BBU hat. Die stützt im Falle eines Stromausfalls oder Absturzes des meist mehrere hundert Megabyte oder gar Gigabyte großen Cache des Contollers und schreibt seinen Inhalt beim nächsten Start auf die Platten aus. Das macht die Sache deutlich zuverlässiger im Katastrophenfall, aber vor allem auch im ein Vielfaches schneller.
 
Yamagi,
mit der Kühlung sprichst du einen Punkt an.
Meine SCSI-Platten-Verbände waren immer gekühlt und liefen auch immer durch, also keine Schlafenszeiten.
Vielleicht erkläre ich es mal so.
Vor einiger Zeit entstand die Idee, einen Netzwerkspeicher bei mir zu installieren. Anstatt zahlreiche Dinge überall auf verschiedene Platten zu verteilen, sollte ein zentraler Speicher entstehen, der Daten an alle Rechner im Haus liefern kann. Aus Mangel an Zeit, durchsuchte ich Angebote von einigen Zulieferern und fand eine Lösung, die aber nur mit einem Windows laufen würde. Ich bitte euch, in einem Haus, wo es nur Unixoide Rechner gibt, wird nicht ausgerechnet ein Dateiserver als Windows Kiste kommen, auch nicht, wenn es dabei um 2003 Server geht. Den Lieferanten deswegen angeschrieben, bekam ich etwa ein halbes Jahr später die Antwort, daß nun ein NAS auf Linux-Basis verfügbar sei, http-Interface und deshalb keinerlei Bediensoftware und natürlich in der Lage, NFS zu exportieren. Das Ding bestellte ich und so bekam ich den Thecus N5200. Nicht schlecht, die kleine Kiste, aber schon mit der exports ging das Elend los. Das System ist nicht so gebaut, daß einfach per ssh oder telnet eingelogt werden kann und eine exports editiert wird, nein, alles muß über die grafische Webinterface-Oberfläche passieren und da sind die Möglichkeiten mehr als dürftig, was NFS-Exports anbelangt. Durch Aufspielen verschiedenster SW konnte ich mein Ziel erreichen, allerdings bleibt die Kiste vernagelt. Das Betriebssystem ist als IMG auf einer CF-Card und wird beim Booten in Ramdisks geladen und es erfordert einen Aufwand, eine eigene exports zum Funktionieren zu bringen. Auch zusätzliche SW kann kaum installiert werden, das Grundsystem ist das gute busybox.
Obwohl Unixoid, es wollte mir nie gefallen und als ich nun die ersten Mac ins Haus bekam, konnte ich nur sehr schwierig die Option insecure in die exports reinnehmen und weil ich mir nicht gemerkt hatte wie das ging, hielt das nur bis zum nächsten Boot und dann saß ich da wieder Stunden davor. Als auch der Speicherplatz nun schon klein wurde, entschied ich mich zum Bau eines eigenen Gerätes, bei dem ich mehr und alles einfacher machen könnte.
Damit habe ich nun angefangen, ich betrachte das Stadium derzeit noch als Experiment. Auch das Gehäuse ist noch nicht sicher, denn derzeit benutze ich einen MIDI-Tower und habe nur einen zusätzlichen Lüfter angebracht. Ich fürchte, daß es darin schon heiß werden kann. Das will ich auch herausfinden und sehen, wo ich schließlich landen werde, HW und SW-seits.
SW Raid hat einen großen Vorteil: stirbt dein HW Kontroller ist das meist das Aus für alle deine Daten. Ein SW Kontroller, wie gvinum, sollte spielend in ein zweites System einzubinden sein. Ich weiß, Raid5 bedeutet nicht Backup-Medium, aber es sollte Sicherheit bis zum ersten Fehlerfall geben ohne daß dabei Daten verloren gehen. Dann kann ich immer noch anfangen zu sichern.
Welcher SW Raid der geeignete ist, weiß ich nicht. Was ich weiß ist aber, daß ich häufiger Stromausfälle habe und deswegen auch eine UPS vorgesehen ist. Große Mengen an Cache will ich aber verhindern. FreeBSD ist nicht unbedingt ein Muß dafür, aber ich hatte es nun eh zur Hand und dachte auch, daß es damit einfach gehen kann. Das Handbuch ist ja eine große Hilfe und auch das Wiki ist besser, als bei vielen anderen Systemen. Außerdem fand ich den FreeBSD NFS-Server sehr performant und schneller und besser, als die Kernel-basierten Linux Versionen, die ich bisher meist nutzte. Vollkommen problemlos werden Mac und meine busybox/linux und GNU/Linux bedient, das ist nicht immer so.

gvinum ist nicht authark.
Also, ich weiß nicht, ob ich das nun richtig beschreibe. Meine Vorstellung von einem SW Raid-Kontroller war, daß eine komplette Abstraktion der HW stattfindet. Erst mal gestartet, sollte dieser Kontroller auch tatsächlich nicht nur den raid kontrollieren, sondern alle HW und alle Schreib- und Lesevorgänge. Das passiert nicht, atacontrol hat nach wie vor vollen Zugriff auf die einzelnen Laufwerke und das ist bedenklich. Alle Eigenschaften eines Speichermediums sollten von der raid-kontroller-SW für das Betriebssystem dargestellt werden, die Eigenheiten und das Handling der einzelnen Medien sollte komplett der Kontroller-SW unterliegen. Das scheint so mit gvinum nicht der Fall zu sein, der setzt nur irgendwas auf, das dafür sorgt, daß mehere Platten Datentechnisch zusammengefasst werden. Ich glaube, daß hier das Zusammenspiel zwischen den Modulen und Kernel nicht optimal ist.
Inwieweit das andere Programme überhaupt leisten, weiß ich nicht. Früher habe ich mich darum nicht so sehr gesorgt.
Alleine schon die Tatsache, daß sich die Latenzzeiten der Platten summieren, zeigt ja, daß das eigentliche Ziel der Paralellisierung nicht erreicht wird. Das ist keine intelligente Lösung. Bei meinen alten SCSI-HW-Kontrollern war das genau ein Schwerpunkt, der echte Performance brachte. Daten konnten schon laufen, während andere Platten noch positionierten. Das ist Sache des Kontrollers, hier günstig zu operieren. Das System braucht nur so zu tun, als werde eine einzige Platte angesteuert und es kümmert sich um die Bedürfnisse des Dateisystems, alles andere macht der Raid-Kontroller. So jedenfalls meine Vorstellung. Was ich erlebe sieht eher so aus, daß sich das System um alles kümmert und der SW-Raid-Kontroller nur weiß, wie er die einzelnen Platten aufgeteilt hat. Wie nun die Köpfe der Platten dorthin kommen und welche Platte zuerst gestartet wird und wie dann Daten zusammenlaufen, scheint wieder Sache des Systems zu sein und nicht des Kontrollers.
 
Nun, die Sache ist halt, dass eine Software auf einer der höheren Ebenen des Kernels laufen MUSS. Denn die Softwarelösung ist ja wie der Name sagt ein reines Softwarekonstrukt und nutzt als solches die Funktionen des Betriebsssystem. Für GEOM sieht dies im Diagramm so aus:

Anwendungen
--------------------------------
Virtual File System (VFS)
--------------------------------
Dateisystem (meist FFS)
--------------------------------
GEOM
--------------------------------
ATA oder CAM (für SCSI)
--------------------------------
Hardware
====================

ATA und CAM liegen also unterhalb von GEOM. Sie exportieren ihre Geräte an DevFS. GEOM wiederum nimmt diese Geräte und nudelt sie um. Daher siehst du auch die einzelnen Plattend es gvinum oder eines gmirrors. Kaputtmachen kannst du allerdings nicht. Denn jeder Zugriff auf diese Geräte muss durch GEOM durch und wir dort geprüft. Es erkennt "Hey, das Gerät nutze ich für eine Klasse, lass die Finger davon" und verweigert den Zugriff. Gut zusehen beim Partitionieren. GEOM verwaltet auch Partitionsschemen. Möchtest du einen Slice ändern, verhindert GEOM es, da das Gerät durch eine Klasse genutzt wird. Man muss die Sicherung erst per sysctl abschalten. Ein "ATA-Raid", wie du es über atacontrol aufbauen kannst (wovon ich abraten würde, es ist nicht sicher), liegt unterhalb von GEOM im ATA-Framework selbst. Hier liegt es an ATA dir die einzelnen Platten zu zeigen oder nicht.

Schreibkopfpositionierungen und diese Dinge sind zwischen SAS/SCSI und ATA/S-ATA sehr unterschiedlich. ATA ist ursprünglich als billiges Interface gebaut worden, zu einer Zeit als Computer sehr schwach waren. Man wollte Logik aus der Haupt-CPU heraus nehmen und dem Programmierer das leben einfacher machen. ATA und S-ATA Geräte sind daher "aktiv", sie haben eine eigene Intelligenz. Man sagt der Platte "Hey Platte, schreibe diese Daten an Stelle ABC" und das war es. Wo die Platte es wirklich hinspeichert, wie sie dies macht und in welcher Reihenfolge, entscheidet sie selbst. Daher sind ATA-Platten so firmwareabhängig, wie man bei Seagate im Moment mal wieder sieht. Dafür aber sind die Controller recht einfach und entsprechend billig zu produzieren. Auch die Softwareseite ist theoretisch relativ einfach zu implementieren. Theoretisch deshalb, da ATA und auch S-ATA Hardware Unmengen Fehler hat, welche man ausgleichen muss.
Im Gegensatz dazu steht SCSI und SAS. Das Konzept ist älter als ATA und richtete sich von Beginn an an professionelleren Einsatz. Die Idee ist, alles relevante im Controller zu Bündeln. SCSI hat also "passive" Platten, die Dinger sind dumm wie Brot. Es funktioniert so. "Hey, Controller! Schreib mal diese Daten an Stelle ABC". Der Controller nudelt diesen Befehl intern durch, gibt dann Anweisungen an die Platten. Er sagt der Platte alles. "Schreibkopf dahin, schreiben! Zack Zack!". Der große Vorteil dieses Konzeptes ist, dass die Platten die Sklaven des Controllers sind. Der Controller kann ein RAID bis runter auf die Ebene der absoluten Hardware auf den Platten aufbauen, er kann die Platten sogar mit einer eigenen Grundformatierung (Low level Format) ausstatten. Das kommt dort stark entgegen, wo es darum geht viele Platten zu koordinieren. Auch sind die Platten in Sachen Hardwarefehler weniger anfällig, da sie weniger Logik in sich haben. Theoretisch zumindest, auch sie haben Firmware. Das realtiviert die Aussage natürlich ein wenig. Der Nachteil dieses Konzeptes ist, dass die Controller sehr viel Logik beinhalten müssen. Die meisten SAS-Controller haben leistungsstarke CPUs mit mehreren hundert Megahertz. Das macht sie teuer.

Ich hoffe das macht einigermaßen klar, wieso SCSI und SAS für RAID-Verbünde an sich besser geeignet sind als S-ATA Controller. Ob sich das in der Praxis (höhere Anschaffungskosten, etc.) rechnet, ist eine andere Frage. Auch sind Soft-RAIDs auf SCSI und SAS reichlich sinnfrei, sie machen den großen Vorteil dies Konzeptes wieder zunichte. Aber es können praktisch alle entsprechenden Controller RAID in Hardware, von daher...
 
Ahja, das beschreibt sehr genau, was ich glaubte, da zu erfahren.
Meine Vorstellung war, daß genau die GEOM und ATA Schicht zusammengefasst (vielleicht optimiert) würden und Grundlage für einen SW-Raid-Kontroller bilden, denn mir war klar, daß ein guter Kontroller ja auch die Herrschaft über die HW übernehmen müßte.

So, wie das sich darstellt, hätte ich vielleicht dann doch besser daran getan, einen HW-Kontroller zu nehmen und vielleicht auch etwas länger für SCSI Platten zu sparen.
Natürlich, ich kann so leben und bin wirklich nicht hungrig nach Leistung und kümmere mich sehr wenig um Performance-Fragen. Ein System das schnell ist wie noch was, aber nichts kann, nutzt mir auchnichts und eines, das ich dauernd neu starten muß, macht mich auch nicht froh. Ich kann nicht gut mit komplizierten Dingen umgehen und jede Stunde, die ich unproduktiv vor einem PC sitze ist ja eine verlorene Stunde und deshalb habe ich mich auf einfach und schnell bedienbare grafische Oberflächen und stabile Unix-System eingeschossen. Mir macht KDE3 Spaß und das braucht ein gutes System darunter, denn es kann einen Rechner wirklich fordern. M$ macht gar keinen Spaß und nur Ärger und ein Mac eigentlich auch, nur daß der wenigstens funktioniert, im Gegensatz zu den Windoofs Sachen. Stell dir mal einen M$ Rechner vor, der über dreißig Anwendungen auf bei mir 14 virtuellen Konsolen verteilt hat und bedient und gleichzeitig ein System-Update laufen lässt: da machst du aber nichts mehr dran!
Ging mir nur eben mal so durchs Hirn.
Wie gesagt, ich brauche die Dinger zum Arbeiten und nicht zum Angeben und da funktionieren die SATA nun auch und der gvinum macht alles, was er soll und ich war nur ein wenig enttäuscht, weil meine Vorstellung eben anders war, als die Wirklichkeit. So erklärt, bleibt mir kaum was anderes übrig, als das zu akzeptieren, wie es nun mal ist.

Daß ich das hier und öffentlich mache, das wisst ihr ja schon. Ich glaube, so wird das auch für andere interessanter. Jedenfalls nochmals Dank für die Hinweise und Erklärungen und wie ich mich kenne, melde ichmich wieder, wenn ich mal wieder was anderes probiere...
 
ZFS:
Danke noch an solarix, gut verständlicher Artikel und wie ich sehe, werden einige meiner Gedanken dort auch genau wiedergegeben.
ZFS, darüber hatte ich kurz gelesen und nicht viel davon verstanden. Es schien mir unausgereift und vor allem vorteilhaft, bei verteilten Medien, diese in einem Pool zu vereinigen. Außerdem schreckt mich noch immer leicht der Hinweis, daß es nur experimentellen Charakter hat und nicht als stabil gelten kann.
Davon abgesehen schient es aber eine Menge von dem zu verkörpern, was ich mir so vorgestellt hatte.
Nur, wie ernst sind denn die Hinweise, die im FreeBSD Buch dazu gemacht werden, bzw, dazu, daß es leicht zu Abstürzen führen kann, weil Speicher zu eng wird?
http://wiki.freebsd.org/ZFSTuningGuide :
On i386 systems you will need to recompile your kernel with increased KVA_PAGES...
Zum Vergrößern anklicken....
Die Tuneables in die loader.conf zu nehmen, ist ja einfach. Einen neuen Kernel wollte ich dazu nicht bauen. Das hat einfach den Grund, daß ich mir immer vorstelle, bei HW-Versagen außerhalb des Raids, die Platten nur in ein anderes System zu hängen, dort ZFS einzuschalten und die Daten wieder transparent zu haben, ohne daß ich erst wieder einen neuen Kernel eigens dafür bauen müßte.
Aus dieversen Gründen wollte ich auch nicht amd64 nehmen, sondern i386.

Ich denke, ich werde es ohnehin mal testen, aber vielleicht hat jemand auch schon Erfahrung gesammelt.
 
pit234a schrieb:
So, wie das sich darstellt, hätte ich vielleicht dann doch besser daran getan, einen HW-Kontroller zu nehmen und vielleicht auch etwas länger für SCSI Platten zu sparen.
Zum Vergrößern anklicken....

HW-Controller - ja, der ist durch nichts zu ersetzen, aber eher wegen den Panicfällen.
Bei guten Controllern kannst du die Platten übrigens einfach an nen neuen Controller hängen, falls der abraucht und die Sache geht sofort weiter. Da verliert man keine Daten.

Performance - bei deinem System stimmt einfach was nicht. Im Normalfall sind SATA-Platten schneller als ein gbit Netzwerk und somit braucht man da nicht mehr Performance, weil das Netz selbst der Flaschenhals ist. Selbst ein SW-Raid5 sollte noch schneller sein, als das Netzwerk.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben