[Sammelthread] ZFS Stammtisch

rigel · 11.11.2018

Ich habe in meinem Server vier HDDs und mich nach langem Hin und Her für zwei Mirrors und gegen ein RAID-Z2 entschieden. Ich möchte trotzdem die Performance prüfen, erhalte unter napp-it (Pools → Benchmarks) aber ein unvollständiges Bild:

Code:

begin tests ..

Bennchmark filesystem: /tank/_Pool_Benchmark
Read: filebench, Write: filebench_sequential, date: 11.11.2018

hostname                        omnios  Memory size: 8192 Megabytes
pool                            tank (recsize=128k, compr=off, readcache=all)
slog                            -
remark                           


Fb3                             sync=always                     sync=disabled                   

Fb4 singlestreamwrite.f         sync=always                     sync=disabled                   
                                201 ops                         2379 ops
                                40.195 ops/s                    475.780 ops/s
                                5460us cpu/op                   1629us cpu/op
                                24.6ms latency                  2.1ms latency
                                40.0 MB/s                       475.6 MB/s
________________________________________________________________________________________
 
read fb 7-9 + dd (opt)          randomread.f     randomrw.f     singlestreamr
pri/sec cache=all               149.4 MB/s       169.6 MB/s     2.6 GB/s                      
________________________________________________________________________________________

Sollte hier nicht unter Fb3 noch etwas stehen?

gea · 11.11.2018

Die aktuelle Voreinstellung für die Pool > Benchmark Tests aktiviert lediglich den sequentiellen Schreibtest mit und ohne sync und die Read-Tests. Der Grund ist einfach der dass diese Werte durch die Einbeziehung von sync write auch eine sehr gute Einschätzung der random-write Leistung bringen (40 MB/s vs 375 MB/s und 200 iops vs 2300 iops durch Nutzung des RAM write-cache. Die 200 iops entsprechen genau den RAW Werten eines Raid-10 mit ca 100 iops je Platte). Dazu läuft dieser Test auch auf langsamerer Hardware noch durch während ein kompletter Testlauf inkl. Random Write und dd auf langsamer Hardware in einen Timeout läuft.

Im Menü Pool > Benchmark kann man aber die anderen Tests auch aktivieren.

Swivel · 11.11.2018

gea schrieb:
Ein Snapshots bei ZFS friert einen früheren Dateistand ein. Er ist also Bestandteil eines Dateisystems. Man kann lediglich ein ganzes Dateisystem auf der Basis eines Snaps auf ein anderes ZFS Dateisystem (gleicher oder anderer Pool/Rechner) per zfs send übertragen. Das muss nicht, geht aber oft zwischen verschiedenen Open-ZFS Plattformen

Also sollte mein Backup-System für die SnapShots auch ein ZoL sein -> das nehme ich mal so mit

rigel · 11.11.2018

Danke für deine Erklärung, gea. Wenn ich dich richtig verstehe, sind die Werte für ein "RAID 10" aus vier HDDs somit in Ordnung?
Sync brauche ich beim Datenspeicher nicht und mein Netzwerk hat eh nur 1G. Muss ich die Datasets dann auf sync=disabled stellen oder reicht sync=standard? Freigabe erfolgt nur per SMB.

Als VM-Speicher habe ich eine Intel DC S4500 eingebaut. Da ESXi hier per NFS sync erwartet, sollte ich auch in napp-it sync aktivieren, oder?
Benchmark der SSD sieht folgendermaßen aus:

Code:

Bennchmark filesystem: /rapid/_Pool_Benchmark
Read: filebench, Write: filebench_sequential, date: 11.11.2018

hostname                        omnios  Memory size: 8192 Megabytes
pool                            rapid (recsize=128k, compr=off, readcache=all)
slog                            -
remark                           


Fb3                             sync=always                     sync=disabled                   

Fb4 singlestreamwrite.f         sync=always                     sync=disabled                   
                                791 ops                         1508 ops
                                158.184 ops/s                   301.584 ops/s
                                2455us cpu/op                   2107us cpu/op
                                6.3ms latency                   3.3ms latency
                                158.0 MB/s                      301.4 MB/s
________________________________________________________________________________________
 
read fb 7-9 + dd (opt)          randomread.f     randomrw.f     singlestreamr
pri/sec cache=all               181.0 MB/s       118.4 MB/s     2.5 GB/s                      
________________________________________________________________________________________

Kann man damit als VM-Speicher erstmal arbeiten?

Hab nicht vor, irgendwelche riesigen Datenbanken zu verwalten, aber schnarchlangsam soll es natürlich auch nicht sein.

gea · 11.11.2018

Swivel schrieb:
Also sollte mein Backup-System für die SnapShots auch ein ZoL sein -> das nehme ich mal so mit

Prinzipiell wurde die Open-ZFS Initiative gegründet, damit die Pools zwischen BSD, Illumos und Linux kompatibel sind. Neue Features kommen aber jeweils mit einer Verzögerung, bisher meist Illumos zuerst, dann BSD, dann Linux. Die Wahrscheinlichkeit, dass ein zfs send von Linux nach BSD oder Illumos klappt, ist damit sehr hoch.

- - - Updated - - -

rigel schrieb:
Kann man damit als VM-Speicher erstmal arbeiten? Hab nicht vor, irgendwelche riesigen Datenbanken zu verwalten, aber schnarchlangsam soll es natürlich auch nicht sein.

Alles im grünen Bereich.
Ohne Redundanz Backup nicht vergessen (SSD > Disk-Pool)

Mit sync=standard (Voreinstellung) bestimmt das schreibende Programm was passiert. Mit SMB bedeuted das async, mit ESXi und NFS sync.

besterino · 11.11.2018

Wie ist denn eigentlich der aktuelle Stand rund um Solaris 11.4? Mein letzter Stand mit der Beta 11.4b war, dass da noch einiges hakte.

Fährt hier jemand solaris 11.4 als VM unter ESXi?

Vor allem interessant: Gibt es inzwischen sauber funktionierende vmware tools?

Bccc1 · 11.11.2018

Ich habe dieses Wochenende Solaris 11.4 unter ESXi 6.7 versucht zum laufen zu kriegen. Installation lief problemlos durch. Allerdings habe ich noch Probleme mit Passthrough von NVMe SSDs (Optane 900p und Samsung 970 Evo) und vmxnet3 läuft bei mir auch noch nicht. Die VMware-Tools-other-10.3.5-10430147 konnte ich aber ohne probleme installieren.

Dabei hab ich noch ein bisschen mit der Verschlüsselung rumgespielt. Ist das normal, das dadurch die Datenrate massiv einbricht? Ich habe erst gedacht meine CPU ist zu lahm, aber ein ssl speedtest mit ebenfalls aes-256-ccm ist doch recht schnell:

Code:

root@solaris:~# openssl speed -engine pkcs11 -evp aes-256-ccm
engine "pkcs11" set.
Doing aes-256-ccm for 3s on 16 size blocks: 82301680 aes-256-ccm's in 3.00s
Doing aes-256-ccm for 3s on 64 size blocks: 66217778 aes-256-ccm's in 2.99s
Doing aes-256-ccm for 3s on 256 size blocks: 67938469 aes-256-ccm's in 3.00s
Doing aes-256-ccm for 3s on 1024 size blocks: 68387598 aes-256-ccm's in 3.00s
Doing aes-256-ccm for 3s on 8192 size blocks: 67524671 aes-256-ccm's in 3.00s
OpenSSL 1.0.2o  27 Mar 2018
built on: date not available
options:bn(64,64) rc4(16x,int) des(ptr,cisc,16,int) aes(partial) blowfish(ptr)
compiler: information not available
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-ccm     438942.29k  1417370.50k  5797416.02k 23342966.78k 184387368.28k

Das ist, wenn ich das richtig verstehe, singlecore mit AES-NI.
blocksize 16 bytes: 418,6 MiB/s
blocksize 8192 bytes: 171,7 GiB/s

Meine Transferrate über SMB ist aber auf ~250 MiB/s eingebrochen.

gea · 11.11.2018

Die VMware Tools für Solaris aus ESXi 6.7u1 funktionieren.

besterino · 11.11.2018

@gea: wie man merkt frickel ich gerade mal wieder an meinen Solaris-Installationen rum... lief bisher alles auf Napp-It Version 17.xx - wenn ich jetzt für 18.xx ca. 3 Pro keys für Homeuse brauche, auch über die Website oder besser anders anfragen?

TCM · 11.11.2018

Bccc1 schrieb:
ein ssl speedtest mit ebenfalls aes-256-ccm ist doch recht schnell

Der ist vor allem falsch. Häng ein -elapsed dran.

Bccc1 · 11.11.2018

TCM schrieb:
Der ist vor allem falsch. Häng ein -elapsed dran.

Danke, das wusste ich nicht. Habs eben schnell gegoogled und verstehe jetzt, dass die Ergebnisse ohne elapsed mit aes ni nichts wert sind.

So siehts jetzt aus:

Code:

root@solaris:/vms# openssl speed -engine pkcs11 -evp aes-256-ccm -elapsed
engine "pkcs11" set.
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256-ccm for 3s on 16 size blocks: 80947803 aes-256-ccm's in 3.00s
Doing aes-256-ccm for 3s on 64 size blocks: 38042280 aes-256-ccm's in 3.00s
Doing aes-256-ccm for 3s on 256 size blocks: 39560205 aes-256-ccm's in 3.00s
Doing aes-256-ccm for 3s on 1024 size blocks: 38903551 aes-256-ccm's in 3.00s
Doing aes-256-ccm for 3s on 8192 size blocks: 38716073 aes-256-ccm's in 3.00s
OpenSSL 1.0.2o  27 Mar 2018
built on: date not available
options:bn(64,64) rc4(16x,int) des(ptr,cisc,16,int) aes(partial) blowfish(ptr)
compiler: information not available
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-ccm     431721.62k   811568.64k  3375804.16k 13279078.74k 105720690.01k

blocksize 16 bytes: 411,7 MiB/s
blocksize 8192 bytes: 98,5 GiB/s

Das ist schonmal deutlich weniger bei größeren blocksizes. Verstehe ich das richtig, die Blocksize aus dem openssl bench bezieht sich auf die Größe der zu verschlüsselnden Daten und NICHT auf die Blocksize von AES? Weil die sollte ja per Definition immer 128 Bit/16 Byte sein, obwohl der Rijndael Algorithmus bis zu 32 Byte könnte. Gibt ZFS dem Oracle Solaris Cryptographic Framework (gibts dafür auch ein griffigeren Namen?) immer ganze records oder kleinere Häppchen? Bei 128k recordsize würde ich erwarten, das es mindestens so schnell wie mit blocksize 8k ist, und das war ja deutlich schneller als ich brauche.

Edit: Da die VM momentan 6 vCPUs hat, habe ich den Bench nochmal mit 6 Threads ausgeführt:

Code:

root@solaris:/vms# openssl speed -multi 6 -engine pkcs11 -evp aes-256-ccm -elapsed
engine "pkcs11" set.
Forked child 0
Forked child 1
Forked child 2
Forked child 3
Forked child 4
+DT:aes-256-ccm:3:16
+DT:aes-256-ccm:3:16
+DT:aes-256-ccm:3:16
+DT:aes-256-ccm:3:16
+DT:aes-256-ccm:3:16
+DT:aes-256-ccm:3:16
Forked child 5
+R:30368221:aes-256-ccm:3.000000
+R:29550758:aes-256-ccm:3.000000
+R:30460774:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:64
+DT:aes-256-ccm:3:64
+R:30046718:aes-256-ccm:3.000000
+R:65959603:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:64
+DT:aes-256-ccm:3:64
+DT:aes-256-ccm:3:64
+R:29308429:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:64
+R:30853723:aes-256-ccm:3.000000
+R:30301686:aes-256-ccm:3.000000
+R:30490895:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:256
+R:30569295:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:256
+R:64821439:aes-256-ccm:3.000000
+R:30631695:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:256
+DT:aes-256-ccm:3:256
+DT:aes-256-ccm:3:256
+DT:aes-256-ccm:3:256
+R:29435441:aes-256-ccm:3.000000
+R:28367432:aes-256-ccm:3.000000
+R:30167988:aes-256-ccm:3.000000
+R:65696464:aes-256-ccm:3.000000
+R:53743833:aes-256-ccm:3.000000
+R:27534617:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:1024
+DT:aes-256-ccm:3:1024
+DT:aes-256-ccm:3:1024
+DT:aes-256-ccm:3:1024
+DT:aes-256-ccm:3:1024
+DT:aes-256-ccm:3:1024
+R:30767079:aes-256-ccm:3.000000
+R:30040830:aes-256-ccm:3.000000
+R:30507274:aes-256-ccm:3.000000
+R:30549839:aes-256-ccm:3.000000
+R:30552249:aes-256-ccm:3.000000
+R:64838852:aes-256-ccm:3.000000
+DT:aes-256-ccm:3:8192
+DT:aes-256-ccm:3:8192
+DT:aes-256-ccm:3:8192
+DT:aes-256-ccm:3:8192
+DT:aes-256-ccm:3:8192
+DT:aes-256-ccm:3:8192
+R:41759843:aes-256-ccm:3.000000
+R:53955217:aes-256-ccm:3.000000
+R:28632604:aes-256-ccm:3.000000
+R:30127637:aes-256-ccm:3.000000
+R:67256460:aes-256-ccm:3.000000
+R:30662855:aes-256-ccm:3.000000
Got: +H:16:64:256:1024:8192 from 0
Got: +F:22:aes-256-ccm:161963845.33:646435968.00:2349620650.67:10413149525.33:78186097322.67 from 0
Got: +H:16:64:256:1024:8192 from 1
Got: +F:22:aes-256-ccm:162457461.33:658212757.33:2574334976.00:10427678378.67:147333712554.67 from 1
Got: +H:16:64:256:1024:8192 from 2
Got: +F:22:aes-256-ccm:160249162.67:652144960.00:2420687530.67:22131661482.67:183654973440.00 from 2
Got: +H:16:64:256:1024:8192 from 3
Got: +F:22:aes-256-ccm:351784549.33:1382857365.33:5606098261.33:10253936640.00:114032211285.33 from 3
Got: +H:16:64:256:1024:8192 from 4
Got: +F:22:aes-256-ccm:157604042.67:650472426.67:4586140416.00:10501829632.00:83730036053.33 from 4
Got: +H:16:64:256:1024:8192 from 5
Got: +F:22:aes-256-ccm:156311621.33:653476160.00:2511824298.67:10428500992.00:82268534101.33 from 5
OpenSSL 1.0.2o  27 Mar 2018
built on: date not available
options:bn(64,64) rc4(16x,int) des(ptr,cisc,16,int) aes(partial) blowfish(ptr)
compiler: information not available
evp            1150370.68k  4643599.64k 20048706.13k 74156756.65k 689205564.76k

Also 1,07 GiB/s für Blocksize 16 Bytes. Natürlich ist das jetzt ohne CPU belastung durch ZFS und SMB, aber trotzdem sollte das doch locker reichen, oder?

besterino · 12.11.2018

Ihr Lieben, ich bin mal wieder zu blöd. Und ja, "never change a running System".

Was habe ich gemacht: ich habe im im Prinzip nur aus Server1 (Solaris 11.3 mit napp-it 17.06 oder so) die Platten eines Pools ausgebaut und in Server2 geschoben (Solaris 11.4 mit napp-it 18.06).

Was ist das Problem: Ich komm' ums Verrecken mit Windows nicht auf die SMB-Freigaben. Die lokalen Accounts sind auf der neuen Kiste die Gleichen (name, passwd, IDs) wie auf der alten. Selbst mit der Anmeldung als "root" komme ich nicht auf die Freigabe, sondern bekomme folgende Fehlermeldung:

Habe auch schon testweise die ACLs auf einem der alten ZFS-Filesystem resetted ("remove"). Bringt aber leider auch nüschts. Das Problem tritt auch auf, wenn ich ein neues ZFS-Filesystem anlege und beim Anlegen "shareSMB" auswähle (allerdings mit guest=off). Wenn ich die SMB-Freigabe ausstelle und dann wieder mit guest allowed=on einrichte, komme ich allerdings drauf. Aber ich will eigentlich keinen Gast-Zugang auf der Freigabe...

Ich habe den dumpfen Verdacht, dass ich irgendwas Banales übersehen/vergessen habe. Jemand eine Idee?

TCM · 12.11.2018

Bccc1 schrieb:
...

Da passt irgendwas nicht. Knapp 100GB/s ist in den Regionen von L1-Cache. Kein normaler Code schaufelt so viele Daten, auch nicht mit AES-NI.

Normal sind solche Zahlen (model name: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz):

Code:

# openssl speed -elapsed aes-256-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256 cbc for 3s on 16 size blocks: 19093168 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 5154091 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 1307673 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 327633 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 8192 size blocks: 41138 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 16384 size blocks: 20580 aes-256 cbc's in 3.00s
OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/x86_64-linux-gnu/engines-1.1\""
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256 cbc     101830.23k   109953.94k   111588.10k   111832.06k   112334.17k   112394.24k


# openssl speed -elapsed -evp aes-256-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256-cbc for 3s on 16 size blocks: 94454753 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 26419290 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 6725099 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 1689166 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 210995 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16384 size blocks: 105774 aes-256-cbc's in 3.00s
OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/x86_64-linux-gnu/engines-1.1\""
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc     503758.68k   563611.52k   573875.11k   576568.66k   576157.01k   577667.07k

Keine Ahnung, was aes-256-ccm da treibt, aber um den Faktor 100+ wird es nicht einfach so schneller. Auffällig ist vor allem, dass er überhaupt nicht mit der Blockgröße und den insgesamt berechneten Blöcken nach unten geht. Je größer die Blöcke, umso weniger dürfte er in festen 3s schaffen.

Hier mal noch aes-256-gcm, was auch wesentlich realistischer aussieht:

Code:

# openssl speed -elapsed -evp aes-256-gcm
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256-gcm for 3s on 16 size blocks: 59570152 aes-256-gcm's in 3.00s
Doing aes-256-gcm for 3s on 64 size blocks: 44027890 aes-256-gcm's in 3.00s
Doing aes-256-gcm for 3s on 256 size blocks: 22336523 aes-256-gcm's in 3.00s
Doing aes-256-gcm for 3s on 1024 size blocks: 7054975 aes-256-gcm's in 3.00s
Doing aes-256-gcm for 3s on 8192 size blocks: 1003361 aes-256-gcm's in 3.00s
Doing aes-256-gcm for 3s on 16384 size blocks: 508234 aes-256-gcm's in 3.00s
OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/x86_64-linux-gnu/engines-1.1\""
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-gcm     317707.48k   939261.65k  1906049.96k  2408098.13k  2739844.44k  2775635.29k

gea · 13.11.2018

besterino schrieb:
Ihr Lieben, ich bin mal wieder zu blöd. Und ja, "never change a running System".

Was habe ich gemacht: ich habe im im Prinzip nur aus Server1 (Solaris 11.3 mit napp-it 17.06 oder so) die Platten eines Pools ausgebaut und in Server2 geschoben (Solaris 11.4 mit napp-it 18.06).

Was ist das Problem: Ich komm' ums Verrecken mit Windows nicht auf die SMB-Freigaben. Die lokalen Accounts sind auf der neuen Kiste die Gleichen (name, passwd, IDs) wie auf der alten. Selbst mit der Anmeldung als "root" komme ich nicht auf die Freigabe, sondern bekomme folgende Fehlermeldung:

Anhang anzeigen 449451

Habe auch schon testweise die ACLs auf einem der alten ZFS-Filesystem resetted ("remove"). Bringt aber leider auch nüschts. Das Problem tritt auch auf, wenn ich ein neues ZFS-Filesystem anlege und beim Anlegen "shareSMB" auswähle (allerdings mit guest=off). Wenn ich die SMB-Freigabe ausstelle und dann wieder mit guest allowed=on einrichte, komme ich allerdings drauf. Aber ich will eigentlich keinen Gast-Zugang auf der Freigabe...

Ich habe den dumpfen Verdacht, dass ich irgendwas Banales übersehen/vergessen habe. Jemand eine Idee?

Dürfte wohl ein Rechteproblem sein.
Der in ZFS eingebaute SMB Server bei Solarish nutzt Windows sid als Bezug für Rechte und nicht Unix uid wie SAMBA. Wird ein Pool auf einen anderen Rechner verschoben und man nutzt einen AD Server bleiben die Rechte inktakt. Im Workgroup Modus wird die sid lokal unter anderem aus der Unix uid erzeugt. Sind die gleichen Benutzer mit der gleichen uid angelegt und wurde jeweils zusätzlich zu dem Unix Passwort per passwd username ein SMB Passwort erzeugt (hat eine andere Struktur) so sollten die Rechte erhalten bleiben.

Wenn nicht hat man gleiches zu tun wie bei Windows wenn man eine Platte an einen anderen Rechner anschließt, nämlich Rechte neu setzen. Am schnellsten geht es per napp-it ACL Menü die Rechte rekursiv auf jeder=modify zu ändern. Dann darf jeder "ändern" und man kann anschließend die Rechte gezielt wieder einschränken (per ACL extension oder aus Windows per SMB als root).

besterino · 13.11.2018

Ok, danke. Vielleicht muss ich doch mal wieder ernsthafter über ein AD nachdenken.

Was mich so wundert ist der Umstand, dass ich aktuell gar nicht aus Windows per Root auf die Freigaben komme.

gea · 13.11.2018

Wenn man ACL bei Unix resetted bedeuted das zunächst dass niemand was darf. Prinzipiell darf bei Unix aber root immer alles auch ohne dass man root explizit Rechte vergibt. Bei Windows ist das anders. Da braucht auch der Admin Zugriffs-Rechte.

Bisher verhält sich der SMB Server bei Solaris eher Unix alike (root darf immer und alles auch ohne für root gesetzte ACL). Das macht ja auch die SMB Administration einfacher. Root darf z.B. ein Backup fahren auch ohne dass man explizit Rechte setzt damit keine Dateien ausgelassen werden. Eventuell hat aber Oracle da bei 11.4 was geändert. Sicherheit und Auditing ist ja etwas wo Solaris 11.4 nochmal deutlich draufgelegt hat.

besterino · 13.11.2018

Danke nochmals!

Werde mich wohl mal wieder in das Berechtigungskonzept vom aktuellen Solaris einlesen müssen.

Fährst Du denn eine AD und wenn ja, was nutzt du als Domaincontroller?

Happy Hepo · 13.11.2018

Ich habe für einen Pool mit mehreren Filesystems mit SMB-Freigabe Autosnaps für den Pool "every hour, keep 24" konfiguriert.
Kurz vor dem Snap-Durchlauf ändere ich eine Datei, und nach dem Snap-Durchlauf erneut.
Als Windows-User möchte ich via Previous Versions den ersten Stand der Datei wiederherstellen.
Previous Versions der Datei listet mir aber keine Vorversionen, und Previous Versions des Share listet mir zwar alle Snaps, allerdings sind die leer. Bei allen Ordnern innerhalb der Share werden ebenfalls keine Previous Versions angezeigt.
Der entsprechnde Snap ist laut Nappit nicht leer.

Works as Intended und ich muss damit leben, den ganzen Snap wiederherzustellen, oder falsch konfiguriert?

Außerdem habe ich eine Menge leerer Snaps "Used: 0". Snap Mass Delete mit der Option "only Unused" sagt mir aber, nichts wurde gelöscht.
Missverstehe ich die Option?

gea · 13.11.2018

besterino schrieb:
Danke nochmals! Werde mich wohl mal wieder in das Berechtigungskonzept vom aktuellen Solaris einlesen müssen.

Fährst Du denn eine AD und wenn ja, was nutzt du als Domaincontroller?

At work habe ich Windows 2016 als AD. Zuhause würde ich mit lokalen Usern arbeiten - außer man möchte sich in Active Directory einarbeiten.

- - - Updated - - -

Happy Hepo schrieb:
Ich habe für einen Pool mit mehreren Filesystems mit SMB-Freigabe Autosnaps für den Pool "every hour, keep 24" konfiguriert.
Kurz vor dem Snap-Durchlauf ändere ich eine Datei, und nach dem Snap-Durchlauf erneut.
Als Windows-User möchte ich via Previous Versions den ersten Stand der Datei wiederherstellen.
Previous Versions der Datei listet mir aber keine Vorversionen, und Previous Versions des Share listet mir zwar alle Snaps, allerdings sind die leer. Bei allen Ordnern innerhalb der Share werden ebenfalls keine Previous Versions angezeigt.
Der entsprechnde Snap ist laut Nappit nicht leer.

Works as Intended und ich muss damit leben, den ganzen Snap wiederherzustellen, oder falsch konfiguriert?

Außerdem habe ich eine Menge leerer Snaps "Used: 0". Snap Mass Delete mit der Option "only Unused" sagt mir aber, nichts wurde gelöscht.
Missverstehe ich die Option?

Prinzipiell sollten bei Eigenschaft > Vorgängerversionen in Windows (Maus Rechtsklick auf Datei oder Ordner) die früheren Verionen mit Angabe des Datums gezeigt werden. Einstellen kann/ muss man nichts - tut einfach.

Eventuell aber ein Rechteproblem. Nochmal probieren wenn man sich per SMB als root anmeldet.

zum Menü Snaps > Mass delete: Used=0 only
Ich habe das gerade probiert. Da scheint sich ein Fehler eingeschlichen zu haben. Ich richte das in der nächsten Version.

Bccc1 · 14.11.2018

TCM schrieb:
Da passt irgendwas nicht. Knapp 100GB/s ist in den Regionen von L1-Cache. Kein normaler Code schaufelt so viele Daten, auch nicht mit AES-NI.[...]

Ich fand die Zahlen auch suspekt und habe ESXi und die VM nochmal durchgestartet und ein Gegentest mit Ubuntu 18.04.1 LTS gemacht.
Beide VMs hatten zum Testzeitpunkt 6 vCPUs, was aber eigentlich egal sein sollte, da die Tests mWn singlethreaded laufen. Die CPU ist eine Intel Xeon Silver 4110.
Das ewig lange log lasse ich mal weg, hier die Ergebnisse:

Code:

Solaris:

openssl speed -elapsed [cipher]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-ccm     Ging nicht
aes-256-ccm     Ging nicht
aes-128-gcm     Ging nicht
aes-256-gcm     Ging nicht
aes-128 cbc     112233.28k   124635.67k   129030.74k   279577.94k   283030.87k
aes-256 cbc      83535.12k    90504.21k    91648.68k   205479.59k   203991.72k

Ging nicht = Error: bad option or value

openssl speed -elapsed -evp [cipher]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-ccm     272559.73k  1092175.91k  4398607.19k 17813014.53k 140753928.19k
aes-256-ccm     208286.41k   832178.71k  3333916.33k 13394461.35k 107368237.74k
aes-128-gcm     257146.90k   658017.88k  1225606.91k  1456088.75k  1525746.35k
aes-256-gcm     199018.12k   555275.95k  1050361.94k  1212219.73k  1264806.57k
aes-128-cbc     325580.96k   343374.25k   354834.94k   352252.93k   350210.73k
aes-256-cbc     237516.94k   247993.51k   250433.02k   252258.65k   251322.37k


Ubuntu:

openssl speed -elapsed [cipher]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ccm     Ging nicht
aes-256-ccm     Ging nicht
aes-128-gcm     Ging nicht
aes-256-gcm     Ging nicht
aes-128 cbc     114305.43k   125960.79k   129155.75k   296423.08k   303169.54k   299483.14k
aes-256 cbc      84775.85k    90822.91k    92036.95k   216244.57k   217721.51k   219867.82k

Ging nicht = Unknown algorithm

openssl speed -elapsed -evp [cipher]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ccm     524069.58k  2102398.27k  8535654.06k 33817686.36k 273298710.53k 547815445.85k
aes-256-ccm     443651.07k  1791764.14k  7223952.21k 28300791.81k 227900099.24k 462508960.43k
aes-128-gcm     439853.87k  1059727.96k  2104557.99k  3341239.98k  4227121.15k  4369350.66k
aes-256-gcm     386805.67k  1035322.67k  1813464.06k  2616023.72k  3099885.57k  3162122.92k
aes-128 cbc     110945.97k   124652.33k   128129.54k   291259.73k   293808.81k   292700.16k
aes-256-cbc     580124.92k   748598.95k   769369.26k   772435.63k   774924.97k   775094.27k

-evp sollte ja dafür sorgen, das AES-NI genutzt wird. Unter Ubuntu bringt das für aes-128-cbc nichts, für aes-256-cbc hingegen eine Menge. Scheinbar wird hier für 128bit trotz -evp kein AES-NI genutzt. Unter Solaris ist -evp in jedem Szenario deutlich schneller also ohne.

Die unbeschleinigten Werte von Solaris und Ubuntu sind sehr ähnlich, mit -evp ist Ubuntu teilweise dreimal so schnell wie Solaris.

Ohne -evp kommt openssl scheinbar nicht mit ccm und gcm klar, mit -evp schluckt der das alles, gibt aber fragwürdig schnelle Ergebnisse zurück.
Die gcm Werte passen noch grob in mein Weltbild, aber die bis zu 131 GiB/s unter Solaris bzw. 510 GiB/s unter Ubuntu bei aes-128-ccm sind wirklich viel zu viel.
Google hat mir bisher noch nicht helfen können zu verstehen, was da passiert.

Gibts eine andere Methode unter Solaris die Verschlüsslungsgeschwindigkeit zu testen? Ich bin inzwischen von meinem Ansatz nicht mehr sonderlich überzeugt...

MisterY · 15.11.2018

kann man napp-it in einer Proxmox-VM testen? Wenn ja, welche ISO nutzt man da am besten?

gea · 15.11.2018

Prinzipiell kann man ein iso von Oracle Solaris 11.4 nehmen oder einen der freien Solaris Forks (OmniOS, OpenIndiana) installieren. Kann man jeweils frei herunterladen. Dann per wget den online Installer für napp-it starten.

Solaris (Unix) soll aber nicht so gut unter Proxmox laufen. Ich nutze aber kein Proxmox um das genau zu beurteilen.

Happy Hepo · 15.11.2018

gea schrieb:
Prinzipiell sollten bei Eigenschaft > Vorgängerversionen in Windows (Maus Rechtsklick auf Datei oder Ordner) die früheren Verionen mit Angabe des Datums gezeigt werden. Einstellen kann/ muss man nichts - tut einfach.

Eventuell aber ein Rechteproblem. Nochmal probieren wenn man sich per SMB als root anmeldet.

Auch mit root angemeldet sehe ich die Vorversionen nur von dem Ordner, der ein eigenständiges Filesystem innerhalb des geshareten Filesystems ist, nicht aber von den Dateien.

gea · 15.11.2018

Ah, jetzt verstehe ich das Problem.

Es handelt sich um geschachtelte ZFS Dateisysteme bei dem man per SMB in ein darunterliegendes Dateisystem wechselt. Sowas war von Sun, dem Erfinder von ZFS nicht vorgesehen und ist bei Solaris auch nicht möglich. OmniOS erlaubt das rudimentär. Eigentlich kann man sich damit nur Probleme einhandeln da ein derartiges Wechsel ganz andere ZFS Eigenschaften zur Folge hat. Man denke da nur an anderes ACL Verhalten oder ob zwischen Groß/Kleinschreibung unterschieden wird oder Zeichensätze. Auch Snaps sind eine Eigenschaft eines Dateisystems und die sind damit nicht aus einem anderen (Eltern-) Dateisystem verfügbar.

Die Snaps/ vorherige Version erhält man nur, wenn man auf das Datesystem selbst per SMB zugreift. Geschachtelte Dateisysteme und SMB Browsen über Dateisysteme hinweg solte man daher vermeiden. In ein (per SMB freigegebenes) Dateisystem gehören nur einfache Ordner.

ps
Das ist auch der Grund warum ZFS Snaps und vorherige Version bei SAMBA so schlecht funktioniert. SAMBA weiß ja garnichts von ZFS und kann das daher auch nicht abfangen.

Happy Hepo · 16.11.2018

Ah, alles klar, danke.

Trambahner · 16.11.2018

Mit BSD und Samba funktioniert Schachteln. Nutze ich durchaus, so dass in einer SMB-Freigabe in verschiedenen für Windows sichtbaren Ordnern dann unterschiedliche ZFS-Dateisysteme stecken bzw. sogar unterschiedliche Pools.
Wenn der Win-Nutzer dann innerhalb eines gemappten Laufwerk in die entsprechenden Ordner speichert, je nach Zweck, erreiche ich damit eine Art manuelles Tiering, ohne dass der Win-Nutzer überhaupt was merkt oder mehrere Laufwerksbuchstaben braucht.

VirtuGuy · 16.11.2018

für derarige Anforderungen würde sich auch ein DFS Stamm in Samba anbieten. Das Thema "Laufwerksbuchstaben" kann man damit recht schön lösen, ebenso wie unterschiedliche Pfade.

Happy Hepo · 16.11.2018

Ich habe den Zugriff auf Vorversionen nochmal mit einem flachen, per SMB geshareten ZFS getestet, auch da kann ich keine Vorversionen innerhalb des Dateisystems sehen, obwohl laut Nappit Snaps vorhanden sind.

Da scheint noch woanders ein Problem zu liegen.

Wo könnte ich noch gucken?

27k1 · 16.11.2018

gea schrieb:
Das Problem ist weniger SAMBA oder Solaris CIFS sondern eher Apple mit OSX.
Warum zum Teufel tut das Zeug nur auf Apple Hardware sauber und wird zudem lausig bis gar nicht gepflegt.

Für manche OSX Softeware, die mit einem "normalen" SMB Share Probleme hat, würde ich mir ein Apple Dateisystem auf iSCSI überlegen - zumal at home.

ps
Unter Solaris spricht man meist immer noch vom Solaris CIFS Server, auch um SMB wegen der Namens-Ähnlichkeit zu SAMBA zu vermeiden. Solaris und OmniOS sind auf SMB 2.1. NexentaStor, wie OmniOS auch ein Illumos Abkömmling ist auf SMB3.

Tipp:
Teste mal ein aktuelles SAMBA (mind. 4.8) und konfiguriere die SMB.conf entsprechend für den Mac (*). Das scheint schnell und rund zu laufen, inkl. TimeMachine. Das ist zumindest mein Eindruck, den ich erhalten habe. Da ich (noch) keinen Server habe, fehlt mir die Langzeiterfahrung. Ich habe nur ein wenig mit einem alten Laptop rumgespielt, auf dem ich ein Linux installiert habe. In anderen Erfahrungsberichten habe ich allerdings ebenfalls positives gelesen.... das gibt Hoffnung bzw. stimmt mich positiv...

(*) vfs_fruit — Enhanced OS X and Netatalk interoperability: vfs_fruit

gea schrieb:
TimeMachine nutze ich nicht da es im Vergleich zu ZFS nichts taugt. Mac Deployment/OS Backup mache ich über CCC oder Clonezilla. Daten liegen alle zentral auf ZFS. Wer seine Daten bei uns lokal hält nutzt Timemachine per lokaler USB Platte und das interessiert mich dann nicht weiter.

Man kann auch mit der TimeMachine auf einem ZFS-Volume (oder Btrfs RAID1) sichern.

Edit:
FreeNAS 11.3 erhält nach derzeitigem Stand auch offiziell entsprechende Features.
Time Machine over SMB: Feature #23359: Time Machine over SMB - FreeNAS - iXsystems FreeNAS Redmine
vfs_fruit (better Samba/Netatalk integration): Feature #5904: vfs_fruit (better Samba/Netatalk integration) - FreeNAS - iXsystems FreeNAS Redmine

gea · 16.11.2018

SAMBA hat durchaus auch seine Vorteile und den gibts für jedes Linux und Unix wie BSD und Solaris.
Insgesamt bevorzuge ich dennoch unter Solarish den in ZFS eingebauten SMB Server.

[Sammelthread] ZFS Stammtisch

Profi

Urgestein

Experte

Profi

Urgestein

Legende

Enthusiast

Urgestein

Legende

Experte

Enthusiast

Legende

Experte

Urgestein

Legende

Urgestein

Legende

Experte

Urgestein

Enthusiast

Urgestein

Urgestein

Experte

Urgestein

Experte

Urgestein

Experte

Experte

Experte

Urgestein

Ähnliche Themen