gvinum + gbde = mehrere Tage zum initialisieren?

hazelnut

Well-Known Member
Hi,

ich konnte mit euer Hilfe in der Zwischenzeit ein funktionierendes gvinum Raid5 system aufsetzen. Hierfür erst einmal Danke.

Jetzt versuche ich diese Partition mittels gbde zu verschlüsseln. Hierzu hab ich mir die manpages und einige Anleitungen durchgelesen und das einfach mal probiert.

Das ganze sieht jetzt so aus:

feuer# mkdir /etc/gbde
feuer# gvinum
gvinum -> list
6 drives:
D raid56 State: up /dev/ad14s1d A: 0/157065 MB (0%)
D raid55 State: up /dev/ad12s1d A: 0/157065 MB (0%)
D raid54 State: up /dev/ad10s1d A: 0/157065 MB (0%)
D raid53 State: up /dev/ad8s1d A: 0/157065 MB (0%)
D raid52 State: up /dev/ad2s1d A: 0/157065 MB (0%)
D raid51 State: up /dev/ad0s1d 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.s5 State: up D: raid56 Size: 153 GB
S data.p0.s4 State: up D: raid55 Size: 153 GB
S data.p0.s3 State: up D: raid54 Size: 153 GB
S data.p0.s2 State: up D: raid53 Size: 153 GB
S data.p0.s1 State: up D: raid52 Size: 153 GB
S data.p0.s0 State: up D: raid51 Size: 153 GB
gvinum -> exit

feuer# gbde init /dev/gvinum/data -i -L /etc/gbde/data.lock
# $FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $
#
# Sector size is the smallest unit of data which can be read or written.
# Making it too small decreases performance and decreases available space.
# Making it too large may prevent filesystems from working. 512 is the
# minimum and always safe. For UFS, use the fragment size
#
sector_size = 512

#
# Start and end of the encrypted section of the partition. Specify in
# sector numbers. If none specified, "all" will be assumed, to the
# extent the value of this can be established.
#
#first_sector = 0
#last_sector = 2879
#total_sectors = 2880

#
# An encrypted partition can have more than one key. It may be a good idea
# to make at least two keys, and save one of them for "just in case" use.
# The minimum is obviously one and the maximum is 4.
#
number_of_keys = 4

#
# Flushing the partition with random bytes prevents a brute-force attack
# from skipping sectors which obviously contains un-encrypted data.
# NB: This variable is boolean, if it is present it means "yes" even if
# you set it to the value "no"
#
random_flush = yes
/tmp/temp.sNvZ3dBngH: 32 lines, 1124 characters.


tja und genau an dieser Stelle steht er nun seit nunmehr ...

hazel@feuer: uptime
10:33PM up 2 days, 6:43, 3 users, load averages: 0.35, 0.20, 0.17
hazel@feuer:

... nach der HDD-Anzeige (und auch nach top) ist der Rechner auch noch am arbeiten. Die Frage ist, kann es wirklich so lange dauern, die Dummy-Daten (random_flush=yes) da draufzuhauen? Ein dd if=/dev/random of=/meine/partition brachte Werte von 8,2 MB/s. Für diese Tests habe ich allerdings ein newfs machen müssen. Vor den Versuchen mit gbde hab ich das Laufwerk dann nur mit umount entfernt.

Die Frage ist nun, sollte ich das hier abbrechen und noch mal neu versuchen oder ist das normal dass das so sehr lange braucht? Bzw kann es sein, dass mir das newfs auf die Füße fällt und der in einer Endlosschleife ist? Hat jemand eine Idee, wie ich das prüfen kann, ohne den Vorgang zu unterbrechen?

Im Voraus schon mal Danke

Hazelnut
 
hallo, hier nochmal die Ausgaben von:

Code:
hazel@feuer: iostat -w 1
      tty             ad0              ad2              ad4             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   51  0.50 591  0.29   0.50 591  0.29   0.51   0  0.00   0  0 15  5 80
   0  230  0.50 672  0.33   0.00   0  0.00   0.00   0  0.00   0  0 12  8 81
   0   76  0.50 347  0.17   0.50 1014  0.50   0.00   0  0.00   0  0 19  3 78
   0   77  0.00   0  0.00   0.00   0  0.00   0.00   0  0.00   0  0 15  6 79

und von

Code:
hazel@feuer: vmstat
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre  flt  re  pi  po  fr  sr ad0 ad2   in   sy  cs us sy id
 1 1 0   40000 295616    5   0   0   0   4   0   0   0 5570 1793 12815  0 20 80


Gruß

Hazel
 
Bei mir dauert ein init von meinem Raid5 mit 4x200GB an zwei Controllern in einer Celeron 700 Maschine ca. 24h...
Und Schreiben dauert auch viel laenger als auf normale Platten. Wenn du jetzt noch einen schwachen Prozessor hast, kann ich mir schon vorstellen, dass das Verschluesseln bei dir so lange braucht.
 
Übrigens eignet sich "gstat" auch gut, um I/O auf Speichermedien zu "beobachten". Ich gehe genau wie Forumsteilnehmer free nicht davon aus, dass es sich gerade um einen schnellen Prozessor handelt. Wenn er wirklich mit 0,... MB/s die Partition mit zufälligen Bytes beschreibt, dann würde ich von mindestens 2 bis 3 Tagen für 150 GB ausgehen.

Björn
 
Das Hauptproblem sehe ich weniger im schreiben der Zufallszahlen als viel mehr im erzeugen.

766 GiB sind kein Pappenstiel, zumal auf dem Rechner ausser dem wegschreiben der Zufallszahlen wohl nicht wirklich viel passiert. Jedes Byte Zufallszahlen also hart erkauft werden muss.

Etwas über 2-3 Tage klingen auch für mich nicht sonderlich weltfremd.
 
ja, hab das aber in der zwischenzeit auch hinbekommen :-)

Dann noch mal Danke an alle für die schnelle Hilfe (auch im IRC), ohne die ich nie so schnell so weit gekommen wäre.


Gruß

Hazel
 
Back
Top