Geli mit gpt

RobJ · 21 April 2007

Hi,

Vincent Vega schrieb:
Wow. Das hätte ich nicht erwartet. Bei 5MB/s ist der Bus eigentlich auch egal.

Sind die 5MB/s bei sequentiellem Zugriff gemessen oder bei zufälligem Zugriff? Welchen Algorithmus verwendest Du (3DES, AES, Blowfish)?

gemässen während eines Kopiervorgangs großer Dateien. Daher beinahe ausschließlich sequentieller Zugriff.

lisa# geli list
Geom name: da0.eli
EncryptionAlgorithm: AES-CBC
KeyLength: 128
Crypto: software
UsedKey: 0
Flags: NONE
Providers:
1. Name: da0.eli
Mediasize: 1918799707648 (1.7T)
Sectorsize: 512
Mode: r1w1e1
Consumers:
1. Name: da0
Mediasize: 1918799708160 (1.7T)
Sectorsize: 512
Mode: r1w1e1

Grüße
RobJ

RobJ · 21 April 2007

RobJ schrieb:
Hi,

>...
UsedKey: 0
>...

Bedeutet das, es gibt kein File, das mit ins Paßwort einfließt?
Also nur eine Passphrase für die Entschlüsselung reicht?

Grüße
RobJ

RobJ · 21 April 2007

RobJ schrieb:
Hi,
>...
lisa# geli list
Geom name: da0.eli
EncryptionAlgorithm: AES-CBC
KeyLength: 128
Crypto: software
>...

so, ich hab da0.eli auf AES 256 umgestellt. Bisher stelle ich jedoch keinen signifikaten Unterschied in der Übertragungsgeschwindigkeit fest. Sobald der Beschleuniger da ist, melde ich mich nochmal.

Grüße
RobJ

MrFixit · 22 April 2007

Bitte auch mal mit gstat und iostat oder systat -vm die auslastung der Disks ansehen. Evtl. sind die zu 100% ausgelastet ...

Die Konsolenausgaben einfach in code-tags packen.

RobJ · 22 April 2007

Hallo,

MrFixit schrieb:
Bitte auch mal mit gstat und iostat oder systat -vm die auslastung der Disks ansehen. Evtl. sind die zu 100% ausgelastet ...

Die Konsolenausgaben einfach in code-tags packen.

danke, die code-tags sind Gold wert!

Code:

# gstat

dT: 0.505s  w: 0.500s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0      0      0      0    0.0      0      0    0.0    0.0| fd0
    0      0      0      0    0.0      0      0    0.0    0.0| ad0
    0      0      0      0    0.0      0      0    0.0    0.0| acd0
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s2
    0     44      0      0    0.0     44   5577    2.2    9.7| da0
    0   1357   1357   5426    0.6      0      0    0.0   75.4| da1
    0      0      0      0    0.0      0      0    0.0    0.0| da2
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1a
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1b
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1c
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1d
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1e
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1f
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s5
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1b.eli
    0   1357   1357   5426    0.6      0      0    0.0   77.3| da1s1
    0      0      0      0    0.0      0      0    0.0    0.0| da2s1
    0   1357   1357   5426    0.6      0      0    0.0   80.3| da1s5
    0     44      0      0    0.0     44   5577   15.6   68.1| da0.eli
    0      0      0      0    0.0      0      0    0.0    0.0| da2s5

Code:

#iostat
      tty             ad0              da0              da1             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0    6  8.35   1  0.01  124.70  44  5.33   4.00 1357  5.30   0  0 41  2 57

Code:

# systat -vm

    1 users    Load  1.03  0.97  0.94                  Apr 22 13:57

Mem:KB    REAL            VIRTUAL                     VN PAGER  SWAP PAGER
        Tot   Share      Tot    Share    Free         in  out     in  out
Act   10564    2432    25168     4564   25900 count
All  503864    3400 -492331k     6368         pages
                                                        1 zfod   Interrupts
Proc:r  p  d  s  w    Csw  Trp  Sys  Int  Sof  Flt        cow    6992 total
           1 23      9319    2  220 4573   44    2  64116 wire        1: atkb
                                                    14648 act         6: fdc0
39.3%Sys   2.3%Intr  0.1%User  0.0%Nice 58.3%Idl   400792 inact       7: uhci
|    |    |    |    |    |    |    |    |    |      24780 cache       14: ata
====================+                                1120 free        15: ata
                                                          daefr  2975 16: ahc
Namei         Name-cache    Dir-cache                     prcfr     3 17: nge
    Calls     hits    %     hits    %                  33 react       19: fwo
        4        4  100                                 1 pdwak  2007 cpu0: time
                                                     4221 pdpgs  2007 cpu1: time
Disks   ad0   da0   da1   da2 pass0 pass1 pass2           intrn
KB/t   0.00   128  4.00  0.00  0.00  0.00  0.00     61472 buf
tps       0    44  1397     0     0     0     0        19 dirtybuf
MB/s   0.00  5.47  5.46  0.00  0.00  0.00  0.00     35660 desiredvnodes
% busy    0     9    74     0     0     0     0     10921 numvnodes
                                                     8908 freevnodes

Code:

last pid:  5069;  load averages:  1.39,  1.11,  1.00                        up 1+02:19:25  14:02:12
74 processes:  6 running, 51 sleeping, 17 waiting
CPU states:  0.2% user,  0.0% nice, 41.8% system,  1.3% interrupt, 56.7% idle
Mem: 14M Active, 389M Inact, 63M Wired, 26M Cache, 60M Buf, 1040K Free
Swap: 999M Total, 80K Used, 999M Free

  PID USERNAME   THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   10 root         1 171   52     0K     8K RUN    1  17.3H 66.21% idle: cpu1
  835 root         1  -8    0     0K     8K RUN    0 770:08 49.85% g_eli[0] da0
   11 root         1 171   52     0K     8K RUN    0 760:35 46.44% idle: cpu0
  843 root         1 101    0  1516K   836K RUN    1 297:19 17.97% cp
    4 root         1  -8    0     0K     8K -      1  73:02  3.91% g_down
  836 root         1  -8    0     0K     8K CPU1   1  71:52  3.12% g_eli[1] da0
    3 root         1  -8    0     0K     8K -      1  56:22  2.00% g_up

Die Last der ersten CPU liegt klar bei cp, während die zweite sich mit Geli beschäftigt. Wie setzt sich die hohe idle Time zusammen? Ist geli nicht multi-threading fähig? Die Platten sollten nicht ausgelastet sein. Das Raid ist mit einem U160 angeschlossen!
Ich habe mir ein gebrauchtes Dual Xeonboard mit 2x3Ghz besorgt. Mal sehen, was die beiden bringen. Alternativ teste ich natürlich auch die Kryptokarte mit dem alten und neuen Dualboard.

Grüße
RobJ

Edit: So sicher bin ich mir jetzt nicht mehr bei der CPU Auslastung. An /dev/da1 hängt ein ntfs Array. Von dort wird kopiert. Scheint so, als ob dies so hohe Last erzeugt.

MrFixit · 23 April 2007

iostat(1) solltest du in etwa so aufrufen 'iostat -w 1' und die Ausgabe ueber laengerem Zeitraum betrachten.

Ansonsten waere ein Test ohne Filesystem vielleicht besser geeignet. Also direktes Schreiben mit dd(1) (und unterschiedlichen Blockgroessen) auf das Device.

ray_tracer · 24 April 2007

GELI > 2TB instabil?

RobJ schrieb:
Hallo,

Gibt es hier im Forum denn niemanden, der ufs2 auf gpt-Partitionen mit geli auf Slices >4TB erfolgreich im Einsatz hat?

Grüße
RobJ

Doch, ich:

Code:

Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/ad10s1a    496M     70M    386M    15%    /
devfs           1.0K    1.0K      0B   100%    /dev
/dev/ad10s1e    496M     18K    456M     0%    /tmp
/dev/ad10s1f     67G    3.9G     58G     6%    /usr
/dev/ad10s1d    1.9G    1.0G    761M    58%    /var
/dev/da0.eli    9.9T    4.0T    5.1T    44%    /mnt

---

Geom name: da0.eli
EncryptionAlgorithm: AES-CBC
KeyLength: 128
Crypto: software
UsedKey: 0
Flags: NONE
Providers:
1. Name: da0.eli
   Mediasize: 10999996342272 (10T)
   Sectorsize: 8192
   Mode: r1w1e1
Consumers:
1. Name: da0
   Mediasize: 10999996350464 (10T)
   Sectorsize: 512
   Mode: r1w1e1

---

File './Bonnie.2117', size: 1048576000
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
         1000 37922 31.5 48829 12.0 23827  5.0 30054 36.0 43666  6.0 1120.0  2.5

Daten: FreeBSD 6.2 AMD64, Sempron 3000, 1GB RAM, 10TB RAID-6

Das Problem ist nur, daß der Testbetrieb nicht so glatt läuft wie erwünscht. Manchmal verschwinden Dateien aus Verzeichnissen (Eben noch 5000, jetzt nur noch 350) und sind nach umount/mount wieder da.
Ein fsck zeigt nichts auffälliges und dauert bei ca. 70.000 Dateien auf der Partition 3 Stunden.
Ein Hardwarefehler ist bisher auszuschließen, der Rechner läuft stabil und eine Überprüfung aller 6TB Daten mit MD5-Checksummen ergab keine Fehler.

Ich werde wohl mal an den Author von GELI schreiben müssen...

bye

RT

P.S. Ich suche noch nach einer Lösung des Geschwindigkeitsproblemes, nativ sind 500 MB/s (sustained) locker drin...

P.P.S. GELI kann nicht mehrere Prozessoren nutzen...

RobJ · 24 April 2007

Hallo,

ray_tracer schrieb:
Doch, ich:
>...
Das Problem ist nur, daß der Testbetrieb nicht so glatt läuft wie erwünscht. Manchmal verschwinden Dateien aus Verzeichnissen (Eben noch 5000, jetzt nur noch 350) und sind nach umount/mount wieder da.
Ein fsck zeigt nichts auffälliges und dauert bei ca. 70.000 Dateien auf der Partition 3 Stunden.
Ein Hardwarefehler ist bisher auszuschließen, der Rechner läuft stabil und eine Überprüfung aller 6TB Daten mit MD5-Checksummen ergab keine Fehler.

Ich werde wohl mal an den Author von GELI schreiben müssen...

Ups, das ist aber sehr kritisch! Da wäre ich sehr an Ergebnissen interessiert. Bei mir soll das System schon sehr schnell in den Produktivbetrieb gehen.

P.S. Ich suche noch nach einer Lösung des Geschwindigkeitsproblemes, nativ sind 500 MB/s (sustained) locker drin...

P.P.S. GELI kann nicht mehrere Prozessoren nutzen...

Mit welcher Hardware, mit 2xU320?
Ich glaube nicht, daß Du den Durchsatz mit i386 Architektur hinbekommen wirst.
Mir würden schon 30-50MB/s ausreichen. Ich versuche demnächst ein DualXeonboard mit Kyptobeschleunigerkarte.
Übrigens soll die Sun T2 10Gbit schaffen:

http://www.tecchannel.de/news/themen/technologie/450388/index2.html

Grüße
RobJ

FreeBSDuser · 24 April 2007

Die insgesamt acht Stream Processing Units erreichen laut Golla einen Verschlüsselungsdurchsatz, der der Bandbreite beider integrierter 10-GBit/s-Ethernet-Ports entspricht.

also ca. 20Gbit

ray_tracer · 24 April 2007

> Ups, das ist aber sehr kritisch! Da wäre ich sehr an Ergebnissen interessiert. Bei mir
> soll das System schon sehr schnell in den Produktivbetrieb gehen.

Bei mir eigentlich auch... Das Problem ist nur, daß ich kein Programmierer bin und daher auch nicht großartig eine Fehler debuggen kann, der dazu noch unmotiviert auftritt... *bääh*

> Mit welcher Hardware, mit 2xU320?

Sempron3000, ASUS M2N2-SLI + 24-Port SATA RAID6

> Ich glaube nicht, daß Du den Durchsatz mit i386 Architektur hinbekommen wirst.

Wozu auch die CPU unter i386 benutzen? Das arbeitet GELI 40% langsamer...

> Mir würden schon 30-50MB/s ausreichen. Ich versuche demnächst ein
> DualXeonboard mit Kyptobeschleunigerkarte.

GELI sollte ja mit der CPU ganz gut skalieren und der Sempron 3000 schafft ja schon 37 MB/s

> Übrigens soll die Sun T2 10Gbit schaffen:

Zu teuer, Hardwareverschwendung - ich will außerdem mein RAID noch tragen können...

bye

RT

RobJ · 24 April 2007

Hi,

ray_tracer schrieb:
>

>..
Bei mir eigentlich auch... Das Problem ist nur, daß ich kein Programmierer bin und daher auch nicht großartig eine Fehler debuggen kann, der dazu noch unmotiviert auftritt... *bääh*

das geht mir genauso. Da kommt meine Frage wieder hoch, ob es eine struktubedingte maximale Größe für Geli gibt?

> Mit welcher Hardware, mit 2xU320?

Sempron3000, ASUS M2N2-SLI + 24-Port SATA RAID6

Ich meinte, über welchen Anschluß. Denn 500MB/s bekommst Du ja nicht in das Board rein.

> Ich glaube nicht, daß Du den Durchsatz mit i386 Architektur hinbekommen wirst.

Wozu auch die CPU unter i386 benutzen? Das arbeitet GELI 40% langsamer...

> Mir würden schon 30-50MB/s ausreichen. Ich versuche demnächst ein
> DualXeonboard mit Kyptobeschleunigerkarte.

GELI sollte ja mit der CPU ganz gut skalieren und der Sempron 3000 schafft ja schon 37 MB/s

Das ist mal eine Ansage, danke. Somit dürften meine angepeilten 50MB/s in erreichbare Nähe kommen.

> Übrigens soll die Sun T2 10Gbit schaffen:

Zu teuer, Hardwareverschwendung - ich will außerdem mein RAID noch tragen können...

Deutlich zu teuer. Für den Preis einer T1000 bekommt man ja noch mind. zwei weitere Arrays

Grüße
RobJ

ray_tracer · 25 April 2007

RobJ schrieb:
Hi,

Ich meinte, über welchen Anschluß. Denn 500MB/s bekommst Du ja nicht in das Board rein.

PCI-Express kennst Du schon? ;-)

http://www.areca.com.tw/products/pcie341.htm

Ich verwende den ARC-1280...

bye

RT

RobJ · 26 April 2007

Hallo,

ray_tracer schrieb:
Doch, ich:

>...
Daten: FreeBSD 6.2 AMD64, Sempron 3000, 1GB RAM, 10TB RAID-6

Das Problem ist nur, daß der Testbetrieb nicht so glatt läuft wie erwünscht. Manchmal verschwinden Dateien aus Verzeichnissen (Eben noch 5000, jetzt nur noch 350) und sind nach umount/mount wieder da.
Ein fsck zeigt nichts auffälliges und dauert bei ca. 70.000 Dateien auf der Partition 3 Stunden.
Ein Hardwarefehler ist bisher auszuschließen, der Rechner läuft stabil und eine Überprüfung aller 6TB Daten mit MD5-Checksummen ergab keine Fehler.

Ich werde wohl mal an den Author von GELI schreiben müssen...

>...

bei mir verschwinden zwar keine Dateien, aber sie nehmen nicht die richtige Größe an. Zieldatei hat teilweise nur einen Bruchteil der Originaldatei unter NTFS (gemounted und kopiert mit mount_ntfs).

Hier hab ich gerade erfahren, daß FreeBSD Probleme mit Dateien größer 3,99 GB hat. Kann Dein Problem damit zusammen hängen?

Grüße
RobJ

ray_tracer · 27 April 2007

RobJ schrieb:
Hallo,
bei mir verschwinden zwar keine Dateien, aber sie nehmen nicht die richtige Größe an. Zieldatei hat teilweise nur einen Bruchteil der Originaldatei unter NTFS (gemounted und kopiert mit mount_ntfs).

Hier hab ich gerade erfahren, daß FreeBSD Probleme mit Dateien größer 3,99 GB hat. Kann Dein Problem damit zusammen hängen?

Meine Datein verschwinden ja nicht richtig, sie sind ja nach umount/mount wieder da...

Da ich keine NTFS-Platten mounte, habe ich auch nicht das Problem mit Dateien > 3,99 GB. UFS hat ja ansonsten keine Probleme, ich habe nie Fehler gehabt, auch wenn Dateien mal größer als 200GB waren...

Yamagi · 27 April 2007

Das Problem lag an der Implementation von NTFS mit FreeBSD. Es sorgte nur dafür, dass bei 3,99GB auf NTFS-Partitionen schluss war. Keine verschwindenden Dateien und erst recht keinen Zusammenhang mit GELI oder FFS.

RobJ · 27 April 2007

Hi,

Yamagi schrieb:
Das Problem lag an der Implementation von NTFS mit FreeBSD. Es sorgte nur dafür, dass bei 3,99GB auf NTFS-Partitionen schluss war. Keine verschwindenden Dateien und erst recht keinen Zusammenhang mit GELI oder FFS.

Habe mir "PITA" gespart, und mit Win die NTFS-Daten gesichert.
Danke für die Infos.

Grüße
RobJ

Geli mit gpt

RobJ

Well-Known Member

RobJ

Well-Known Member

RobJ

Well-Known Member

MrFixit

aka uqs

RobJ

Well-Known Member

MrFixit

aka uqs

ray_tracer

New Member

RobJ

Well-Known Member

FreeBSDuser

Well-Known Member

ray_tracer

New Member

RobJ

Well-Known Member

ray_tracer

New Member

RobJ

Well-Known Member

ray_tracer

New Member

Yamagi

Possessed With Psi Powers

RobJ

Well-Known Member

Wir schützen deine Privatsphäre