Geli mit gpt

R

RobJ

Well-Known Member
Hallo,

ich versuche, leider ohne Erfolg, ein großes Diskarray mit Geli zu verschlüsseln.
Damit das verschlüsselte Filesystem größer als 4TB werden, kann denke ich, muß die Blockgröße vergrößert werden. (Hiesiges Array ist bisher nur 1TB groß.)

Meine Vorgehensweise:

1. dd if=/dev/zero of=/dev/da0

2. geli init -s 16384 /dev/da0

Blockgröße vergößert auf 16K, damit ich die 4 TB Grenze knacken kann.

3. geli attach /dev/da0

4. gpt create /dev/da0.eli

5. gpt add /dev/da0.eli

6. newfs -b 16384 /dev/da0.eli

Die Blockgröße der obigen angepaßt.

Daraufhin erfolgt folgende Fehlermeldung:
/dev/da0.eli: 1066569.0MB (2184333280 sectors) block size 16384, fragment size 16384
using 1188 cylinder groups of 898.39MB, 57497 blks, 14400 inodes.
newfs: can't read old UFS1 superblock: read error from block device: Invalid argument


gpt show /dev/da0.eli zeigt:
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 1 Pri GPT table
3 68260412

Wo ist das Problem, bzw. was mache ich falsch?
Danke vorab für Eure Hilfe.

Grüße
RobJ
 
Die Blockgröße ist eine Sache des Dateisystems, mit -s legt man die Sektorgröße fest, das hat soweit ich weiß nichts mit dem Adressraum zu tun.

Ich vermute mal das Problem liegt irgendwo bei dem gpt Befehlen. Haben die einen bestimmten Zweck? Eigentlich kann man die ja weg lassen.
 
Hi Kamikaze,

Kamikaze schrieb:
Die Blockgröße ist eine Sache des Dateisystems, mit -s legt man die Sektorgröße fest, das hat soweit ich weiß nichts mit dem Adressraum zu tun.
Zum Vergrößern anklicken....

Meinst Du also, das verschlüsselte Device muß die Blockgröße nicht in 16K vorstrukturieren? Oder ist "-s" einfach der falsche Parameter?

Kamikaze schrieb:
Ich vermute mal das Problem liegt irgendwo bei dem gpt Befehlen. Haben die einen bestimmten Zweck? Eigentlich kann man die ja weg lassen.
Zum Vergrößern anklicken....

Ich habe vermutet, daß GPT fdiskgleich handelt. fdisk kann aber nur 2TB, richtig?
Welche Partition hätte ich denn ohne gpt, und mit welcher Blockgröße?

Grüße
RobJ
 
Bei geli ist der -s Parameter ein reine Performancesache. Da wir keine optimalen Werte kennen, würde ich sagen, Finger weg.

Einfach:
# geli init /dev/da0
# geli attach /dev/da0
# newfs -U /dev/da0.eli

Dann kannst du einfache mit
# mount /dev/da0.eli /mnt/tmp
das Ding mounten. Das ganze device wäre dann einfach eine Partition.
 
Hi Kamikaze,

Kamikaze schrieb:
Bei geli ist der -s Parameter ein reine Performancesache. Da wir keine optimalen Werte kennen, würde ich sagen, Finger weg.

Einfach:
# geli init /dev/da0
# geli attach /dev/da0
# newfs -U /dev/da0.eli

Dann kannst du einfache mit
# mount /dev/da0.eli /mnt/tmp
das Ding mounten. Das ganze device wäre dann einfach eine Partition.
Zum Vergrößern anklicken....

UFS scheint standardmäßig 16K anzuwenden. Somit sollte die 2TB Grenze keine Rolle spielen. Aber wie ist das mit der Partition, braucht ein Device nicht zwingend eine?
Wofür sonst der Umstand mit gpt?

Grüße
RobJ
 
Das wird nur benötigt wenn du das Device partitionieren willst. Wenn du sowieso nur eine einzige Partition willst, kannst du einfach das ganze Device verwenden. Dann brauchst du keine Partitionstabelle.
 
Also, um mal 2 Dinge richtig zu stellen:

- GPT hat vor allem einen Vorteil gegenüber dem klassischen DOS-Partitionstabellen. Es kann mehr als 2TB pro Partition verwalten. Ich weiß nicht wo die Grenze liegt, aber sie ist mit derzeitigen Speichermedien unerreichbar....

- UFS1 konnte bis knapp 2TB verwalten. Eines der Argumente überhaupt bei der Einführung von UFS2 damals war, dass seine 64Bit Adressfelder deutlich mehr verwalten können, wieder mehr als man mit aktuellen Speichermedien erreichen kann. Wer es probieren möchte sein gvistor an die Hand gelegt, wobei das natürlich keine "echte" festplatte ist. Alternativ qemu mit einer großen Sparse-File.

Daraus leiten wir mal ab, dass das Problem beim GELI zu suchen ist. Vielleicht läuft da was schief, dass er über 2TB wieder von vorn beginnt. Oder Müll zurückgibt. Ich weiß es nicht, aber dort würde ich mal ansetzen.
 
Hallo,

Yamagi schrieb:
Also, um mal 2 Dinge richtig zu stellen:

>...UFS1 konnte bis knapp 2TB verwalten. Eines der Argumente überhaupt bei der Einführung von UFS2 damals war, dass seine 64Bit Adressfelder deutlich mehr verwalten können, wieder mehr als man mit aktuellen Speichermedien erreichen kann. ...
Zum Vergrößern anklicken....

Das ist mir schon nicht ganz klar. Ich dachte bisher, die Adreßfelder seien durch das Betriebssystem begrenzt. Demnach war meine Vermutung, daß ein UFS2 mit einem 32bit Betriebssystem nur deshalb obderhalb von 2TB speichern kann, da es die Blockgröße >4K, nämlich 16K, wählt.

Yamagi schrieb:
>...
Daraus leiten wir mal ab, dass das Problem beim GELI zu suchen ist. Vielleicht läuft da was schief, dass er über 2TB wieder von vorn beginnt. Oder Müll zurückgibt. Ich weiß es nicht, aber dort würde ich mal ansetzen.
Zum Vergrößern anklicken....
[/QUOTE]

Das scheint mir nicht schlüssig zu ein. Bisher habe ich in keinem geli Befehl auch nur eine Größenangabe gesehen. Hier war meine bisherige Vorstellung so, daß *.eli-Devices die Daten lediglich (verschlüssetl) durchschleusen auf das physische Device. Demnach dürfte Geli sogar mit beliebiger Größe zurecht kommen. Soweit meine Annahme.
Mir ist nicht klar, warum newfs aus meinem ersten Posting ein ufs1-Problem hat.
Gibt es hier im Forum denn niemanden, der ufs2 auf gpt-Partitionen mit geli auf Slices >4TB erfolgreich im Einsatz hat?

Grüße
RobJ
 
Wenn du gpt verwendest musst du newfs auf da0.elip1 anwenden. da0.eli ist dann partitioniert, was in deinem Anwendungsfall aber gar nicht nötig ist. Also lass gpt einfach weg und alles ist gut.
 
Kamikaze sagt es, da liegt der Fehler. Ichw ar nur zu blöd ihn zu sehen :)

- Nein. Die Adressfelder bei Dateisystemen sind durch das Layout auf der Platte begrenzt. Nutzt das Dateisystem intern nur 32Bit Zeiger wie UFS1, ist bei ca. 2TB natürlich Schluss. Nutzt man 64Bit Zeiger (UFS2) oder gar 128Bit (ZFS), sind natürlich viel größere Dateisysteme möglich. Weil man schlicht mehr Adressen ansprechen kann... Das Betriebssystem und die Rechnerarchitektur hat damit erst einmal nichts zu kriegen.

Das mit GELI war - wie gesagt - eine Vermutung. Die sich inzwischen allerdings als falsch herausgestellt hat :)
 
Hier noch mal ein Beweisscreenshot, dass es wirklich geht. Erstellt per Sparsefile und md(4). Ein ganz normales UFS2 auf GPT und einem 4TB Storage.
 

Anhänge

  • 4tib.png
    4tib.png
    316,4 KB · Aufrufe: 321
Bitte nicht -s x mit geli(8) verwenden, wenn dir an deinen Daten etwas liegt. Stuerzt dein Rechner naemlich beim Update einer einzigen Inode (atime, zb) ab, sind 16kB an Inodes futsch. Das tut weh, glaub mir.
 
Hi,

Kamikaze schrieb:
Wenn du gpt verwendest musst du newfs auf da0.elip1 anwenden. da0.eli ist dann partitioniert, was in deinem Anwendungsfall aber gar nicht nötig ist. Also lass gpt einfach weg und alles ist gut.
Zum Vergrößern anklicken....

das ist ein super Hinweis, danke.
Doch werde ich es vermutlich ohne Partitionen machen, wenn ich sie sowieso nicht unbedingt brauche.

Grüße
RobJ
 
Hi,

Yamagi schrieb:
Kamikaze sagt es, da liegt der Fehler. Ichw ar nur zu blöd ihn zu sehen :)

- Nein. Die Adressfelder bei Dateisystemen sind durch das Layout auf der Platte begrenzt. Nutzt das Dateisystem intern nur 32Bit Zeiger wie UFS1, ist bei ca. 2TB natürlich Schluss. Nutzt man 64Bit Zeiger (UFS2) oder gar 128Bit (ZFS), sind natürlich viel größere Dateisysteme möglich. Weil man schlicht mehr Adressen ansprechen kann... Das Betriebssystem und die Rechnerarchitektur hat damit erst einmal nichts zu kriegen.
...
Zum Vergrößern anklicken....

Oh Mann, da hätte ich auch selber drauf kommen müssen. Sonst bräuchte ZFS ja auch neue Generation Hardware :)

Grüße
RobJ
 
Hi,

Yamagi schrieb:
Hier noch mal ein Beweisscreenshot, dass es wirklich geht. Erstellt per Sparsefile und md(4). Ein ganz normales UFS2 auf GPT und einem 4TB Storage.
Zum Vergrößern anklicken....

prima, danke für Deine Mühe.
Dann freue ich mich auf mein verschlüsseltes Array.
Zu der oben aufgekommenen Frage: Hat Geli eine Grenze?

Grüße
RobJ
 
Cryptoaccelerator

Gibt es schon günstige Cryptoaccelerators für z.B. Zuhause, mailserver .. ?
Möglicherweise PCIe ?
Der Via C3 soll ja einen drinne haben, ich weis nicht was der für nen durchsatz schafft, aber ab 30MB/s macht das doch schon Spass.

Möglicherweise gibt es ja lösungen für Notebooks, denn mich hält die CPU-Belastung
davon ab meine Partitionen zu verschlüsseln, und so ein kleiner chip, oder diese Express-Slot Karten wären doch optimal und Akku wird geschont.

Puhh, hab grade mal nachgesucht, der C3 (Nehemia+)soll 12,5Gbit AES schaffen.
Ich glaub das is zu gebrauchen, könnte man nich aus kostengründen einfach das ding auf ne PCIe >4x Karte packen für Cryptoacceleration ?

Sorry wenn blöd, hab nich so richtig Ahnung...
 
Zuletzt bearbeitet:
FreeBSDuser schrieb:
Gibt es schon günstige Cryptoaccelerators für z.B. Zuhause, mailserver .. ?
Möglicherweise PCIe ?
Der Via C3 soll ja einen drinne haben, ich weis nicht was der für nen durchsatz schafft, aber ab 30MB/s macht das doch schon Spass.

Möglicherweise gibt es ja lösungen für Notebooks, denn mich hält die CPU-Belastung
davon ab meine Partitionen zu verschlüsseln, und so ein kleiner chip, oder diese Express-Slot Karten wären doch optimal und Akku wird geschont.

Puhh, hab grade mal nachgesucht, der C3 (Nehemia+)soll 12,5Gbit AES schaffen.
Ich glaub das is zu gebrauchen, könnte man nich aus kostengründen einfach das ding auf ne PCIe >4x Karte packen für Cryptoacceleration ?
Zum Vergrößern anklicken....

Wofür?

So quer über den Daumen gepeilt schafft eine durchschnittliche Desktop-Festplatte ca. 40 MBytes/s im sequentiellen Zugriff. Meist greift man aber nicht sequentiell zu, sondern der Zugriff folgt eher zufälligen Mustern. Fakt ist, obwohl SATA-II Platten "mit bis zu 3GBit/s Durchsatz" angepriesen werden, der Flaschenhals ist im lokalen Zugriff zunächst die Festplatte, nicht der Bus.

Bei DMA Transfers von der Platte in den RAM ist die CPU heutzutage chronisch unterbeschäftigt. Wenn der verschlüsselte Block von der Platte erstmal im RAM liegt, ist das Entschlüsseln schnell erledigt, die Mehrbelastung auf der CPU wirst Du i.A. nicht sehr deutlich spüren.

Etwas anders sieht's natürlich im Notebook aus, denn dort wird u.U. die Host-CPU hochgetaktet was wiederum etwas mehr Strom kostet. Auf der andern Seite läuft eine zusätzliche Beschleuinigerkarte natürlich auch nicht von alleine.

Der einzige Grund (für mich) heute noch Kryptobeschleuniger zu verbauen sind entsprechenden Low-Power-Lösungen, denn viele Algorithmen, z.B. 3-DES, lassen sich in Hardware einfacher als in Software lösen. D.h. eine Beschleunigerkarte kann langsamer getaktet sein um dennoch mit einer GHz-CPU mitzuhalten.

Der von Dir o.g. Chip hat mit 12,5GBit/s einen höheren Durchsatz als die meisten gebräuchlichen Übertragungswege (PCI ist immer noch weit verbreitet, GBit Ethernet gerade erst im kommen, etc.). Ich halte es für Overkill.
 
Vincent Vega schrieb:
Wofür?

....

Der von Dir o.g. Chip hat mit 12,5GBit/s einen höheren Durchsatz als die meisten gebräuchlichen Übertragungswege (PCI ist immer noch weit verbreitet, GBit Ethernet gerade erst im kommen, etc.). Ich halte es für Overkill.
Zum Vergrößern anklicken....

Der Via C3 ist sehr kostenoptimiert, und wie ich glaube billiger wie diese Karten, da er multifunktional und schon vorhanden und viel benutzt wird.

Ob das jetz nen overkill is is doch wurscht beim Desktop/Server.
Bei einem Notebook ist der stromverbrauch einfach zu hoch und das nebenbei zu
machen.

###

Zu dem PCI(old) Flaschenhals: Ich hab ja auch PCIe > 4x geschrieben, das drüften dann so um die 1000Mbyte/s sein. Und wenn ich ein Raid 10 oder 0 verschlüssele brauch ich ein wenig mehr als 30Mbyte/s, und das dürfte schon ein wenig CPU-Zeit kosten.

###

BTW: so eine Karte, kann die von mehreren anwendungen gleichzeitig benutzt werden? z.B. VPN und geli ?

Edit: Vincent Vega, ich frage mich wie Probleme ala Jahr2000 oder Unixtime@jahr2038 entstehen. Ich nehm ja nich ne andere (mögl. gleichteure) Karte nicht, nur weil die etwas schneller ist als ich es bräuchte.

Greetings FreeBSDuser :)
 
Zuletzt bearbeitet:
Die Karte wird seitens des Systems von Crypto-Framework angesprochen. Siehe auch "man 4 crypto". Jedes Subsystem welches Cyrpto nutzen kann, kann auch die Karte jederzeit verwenden.
 
Hi,

Yamagi schrieb:
Also bezahlbar sind die Beschleuniger von Soekris. Aber auch relativ schwach auf der Brust: http://www.soekris.com/vpn1401.htm Gibts bei Tronico für 76€ in der PCI-Fassung. Als MiniPCI sogar nur unter 70€.
Zum Vergrößern anklicken....

so, hab vorhin eine bestellt. Damit sollte der Durchsatz besser werden.
Könnt ihr mir erklären, warum ich während des Kopiervorgangs von unverschlüsselt nach verschlüsselt eine 60% idle Time habe?

CPU states: 0.0% user, 0.0% nice, 37.5% system, 2.3% interrupt, 60.2% idle

Läuft die zweite CPU meine Servers (2xPIII 800) überhaupt?
Ich habe sie nicht gesondert installiert. Sie war nach der Standardinstallation einfach schon da. Sie wird mit TOP jedenfalls in der Spalte angezeigt.

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
954 root 1 -8 0 1516K 884K biord 1 1:13 18.99% cp
883 christian 1 96 0 6252K 2208K select 0 0:03 0.00% sshd
900 christian 1 96 0 6252K 2204K select 1 0:00 0.00% sshd
956 root 1 5 0 4940K 2472K ttyin 0 0:00 0.00% csh

Grüße
RobJ
 
Ich krieg auf meinem P3-500 mit geli leider auch gerade mal 3-4MB/s raus. Ich waere also _brennend_ an Zahlen mit crypto(4) Hardware interessiert.

Bei dem Idle Wert gehen bestimmt 50% auf das Konto der zweiten CPU (geli ist sicherlich single-threaded), ueberpruefen kannst du das besser, in dem du "top -S" startest und dir die Kernel-Threads ansiehst.
 
Hallo,

MrFixit schrieb:
Ich krieg auf meinem P3-500 mit geli leider auch gerade mal 3-4MB/s raus. Ich waere also _brennend_ an Zahlen mit crypto(4) Hardware interessiert.

Bei dem Idle Wert gehen bestimmt 50% auf das Konto der zweiten CPU (geli ist sicherlich single-threaded), ueberpruefen kannst du das besser, in dem du "top -S" startest und dir die Kernel-Threads ansiehst.
Zum Vergrößern anklicken....

"top -S2 ergibt: (ein Auszug)

last pid: 4018; load averages: 1.15, 0.95, 0.89 up 0+17:05:12 10:02:08
73 processes: 4 running, 53 sleeping, 16 waiting
CPU states: 0.0% user, 0.0% nice, 36.0% system, 1.9% interrupt, 62.1% idle
Mem: 13M Active, 400M Inact, 53M Wired, 27M Cache, 60M Buf, 1088K Free
Swap: 999M Total, 152K Used, 999M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
10 root 1 171 52 0K 8K RUN 1 692:37 66.41% idle: cpu1
11 root 1 171 52 0K 8K RUN 0 599:56 56.84% idle: cpu0
923 root 1 -8 0 0K 8K geli:w 0 394:30 40.19% g_eli[0] da0
954 root 1 -8 15 1516K 848K biord 1 185:59 18.41% cp
4 root 1 -8 0 0K 8K - 1 44:47 3.86% g_down
3 root 1 -8 0 0K 8K - 1 35:38 2.59% g_up
924 root 1 -8 0 0K 8K geli:w 1 36:02 2.00% g_eli[1] da0
29 root 1 -64 -183 0K 8K WAIT 1 17:07 1.22% irq16: ahc0
18 root 1 -40 -159 0K 8K CPU1 1 14:40 0.44% swi2: cambio
12 root 1 -32 -151 0K 8K WAIT 0 15:35 0.05% swi4: clock sio
37 root 1 171 52 0K 8K pgzero 0 4:38 0.00% pagezero
35 root 1 -16 0 0K 8K psleep 1 3:25 0.00% pagedaemon
39 root 1 20 0 0K 8K syncer 1 0:28 0.00% syncer
2 root 1 -8 0 0K 8K - 1 0:12 0.00% g_event

Beide CPUs scheinen gleich ähnlich belastet/gelangweilt.

Grüße
RobJ

P.S. Läßt sich hier ein Copy&Paste aus der Konsole auch in schön einbringen?
 
RobJ schrieb:
Hi,



Für meinen Fileserver (2xPIII 800), der mit Geli nur 5MB/s schafft. Und das, obwohl das Raid mit U160 angebunden ist. Zugegeben, der 32bit PCI Slot kann den 64bit Adaptec nicht befriedigen, aber dennoch wären 20-30MB/s für Dauerdatentransfer sehr angenehm.
Zum Vergrößern anklicken....

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)?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben