sokratische Hebammenlehre

Omas Linzertorte

Prolog: Vor ein paar Jahren backte mir meine (Ex-)Stieftochter mir auf meinen Wunsch eine Linzer – ich musste mit Erschrecken feststellen, daß diese ganz anders als die meiner Mama ist (mit Himbeere)! Daraufhin backe ich mittlerweile mind 1mal jährlich mir meine Linzer…

Deshalb selbstverständlich mit Rezept und Montageanleitung:

Also: Omas Linzer
(in meinem Falle: Mamas Linzer!)

200g Mehl
200g gemahlene Haselnüsse
150g Zucker
200g Butter
2 Eier – etwas Eiweiß „absondern“
1 TL Zimt
1 gestrichener TL Backpulver
1/2 Fläschchen Bittermandelöl-Aroma
ca 500-600gr Pflaumenmus (möglichst geringer Zuckeranteil! in meinem Falle 43%, weniger wäre besser).

Teig kneten aus allem, außer Pflaumenmus.
Springform fetten und mit Mehl einstäuben.
Backofen auf 180° (Gas Stufe 3) vorheizen.

ca „5/6“ vom Teig in die Form, gleichmäßig ausbreiten. Einen Rand „vorsehen“ (ca 2-3cm), weil da kommt dann das Pflaumenmus drauf, das soll nicht an die Form…

Das Mus gleichmäßig verteilen. Ich nehme gerne ein Quäntchen mehr, gute 600g in diesem Falle.

Ich habe mit nem Spritzbeutel dann den restlichen Teig Gittermäßig über das Mus von Rand zu Rand gezogen. Nur mit Gitter gefällt es mir besser, aber bei der Restteigmenge hätte ich garantiert heftige Bauchschmerzen bekommen!

Bestreichen mit dem Eiweiß

und genießen:

FreeBSD Wechsel bei Raid5 von 4disks zu 5disks

Es gilt die Empfehlung bei einem Raid5 eine ungeradzahlige Anzahl von Festplatten einzusetzen, so daß die Daten auf 4+1 verteilt werden. Somit habe ich mein raidz1 von 4 disks (mit ZIL) auf 5 disks (ohne ZIL) erweitert und hier sind die Ergebnisse, teils ernüchternd und mehr oder minder enttäuschend, aber auch teils imposant:

Sequential Output bei char etwa gleich, beim Block mehr als 50% Steigerung, beim Rewrite mehr als das Doppelte, idR immer einhergehend mit einer höheren CPU-Last, gerade bei letzterem hätte ich weniger Last erwartet…
Beim Sequential Input char einen massiven Einbruch beim Block lesen…

Schwarzwälder Kirschtorte

Mein Sohn wünschte sich zum Geburtstag eine Schwarzwälder Kirschtorte – die erste Torte, welche ich backte. Ist ein Haufen Arbeit, hat aber lecker geschmeckt.

Zutatenliste:
350 g Mehl
1 TL Backpulver
340g Zucker
3 P Vanillezucker
Schale einer Zitrone
1 Prise Salz
9 Eier
100 g Butter oder Margarine
2 El Rum
130 g Speisestärke
30 g Kakao
700 g Sauer-Kirschen
2 El Kirschwasser
3 Blatt Gelatine
½ l Schlagsahne
100 g grob geraspelte Schokolade

!Achtung! -> siehe Kommentar

Handrührgerät oder Küchenmaschine, 28cm Springform, sonstige Küchenutensilien

Böden:
1 Mürbeteig-Tortenboden nach Mürbeteig-Grundrezept (ohne Rand gebacken)
1 Kakao-Tortenbiskuit

Mürbeteig (Boden)
15-20 min bei 210-220° (mein Gas-Backofen: Stufe 3)
250g Mehl
1TL Backpulver
60g Zucker
1 Pkg Vanillezucker
Abrieb einer halben Zitronenschale
1 Prise Salz
1 Ei
100g Butter

Mehl und Backpulver in eine Rührschüssel sieben, restliche Zutaten drauf und mit Knethaken gut vermengen. Wird sich dann als bröselig (vergleichbar zu Streusel) bilden, dann nochmal gut mit der Hand durchkneten. Eine gute halbe Stunde ruhen lassen.

Ca 30min Backen, mit Zahnstocher oder vergleichbaren prüfen, ob durchgebacken (Spitze darf nach reinstecken nicht mehr klebrig sein).

Kakaobiskuit – Zwischenböden
25-35min bei 175-195° (mein Gasbackofen Stufe 2)
Zutaten:
8 Eier
180 g Zucker
1 Pkg Vanillezucker
2 El Rum
Schale einer halben Zitrone
100 g Mehl
100 g Speisestärke
30 g Kakao

8 Eier trennen, Eiweiß steif schlagen -> nebenhin stellen
Mehl mit Speisestärke und Kakao sieben
8 Eigelb mit 2 EL Rum, dem Zucker, dem Vanillezuckerund Zitronenschale schaumig quirlen
Zum Mehl hinzugeben und gut durchrühren und gleich in die Springform und ca 30min backen – mit Zahnstocher prüfen ob durch (s.o.)
Gut abkühlen lassen und in der Mitte „teilen“

Zum Finale der Schwarzwälder Kirschtorte:

v.l.n.r.: Kirschwasser, Speisestärke, Gelatine gelöst, Kakao/Zuckermischung

Füllung und Überzug Zutaten:
700 g Kirschen
60 g Zucker
6 El Kirschwasser
30 g Speisestärke
3 Blatt Gelatine
½ l Schlagsahne
40 g Zucker
1 Pkg Vanillezucker
100 g grob geraspelte Schokolade

30g Speisestärke mit etwas Kirschsaft auflösen
¼ l Kirschsaft aufkochen
Von Kochstelle und Speisestärke einrühren
Kirschen (nach Belieben ein paar rausnehmen für die spätere TOP-Deko) und 6El Kirschwasser hinzugeben
Gelatine kalt auflösen (gelegentlich rühren) und im Wasserbad verflüssigen
60g Zucker + Vanillezucker vorbereiten

Sahne halbsteif schlagen
Zucker und Vanillezucker hinzu und löffelweise die Gelatine -> steif schlagen bis es zu einer „festen“ Creme wird
Den Mürbeteigboden mit der Sahnecreme bestreichen, die Hälfte der Kirschcreme drauf, die erste Kakaobiskuit-hälfte drauf, Sahnecreme drauf, Kirschcreme drauf, 2te Kakaobiskuit-hälfte drauf.

Mit Sahnecreme betreichen und mit Kakaoraspel „bewerfen“.

Kommentar:

Das war meine erste Torte und, ja, Haufen Arbeit, will ich nicht mehr – oder vielleicht doch, nur um zu schauen, ob es dann besser gelingt?

Fehler No1: ich hatte mich verlesen und ½ l Kirschsaft genommen – die Festigkeit war nicht so dolle, sollte mit der korrekten Menge eines ¼ l entsprechend besser sein.

Fehler No2: Die Sahnecreme reichte zum Schluss beileibe nicht aus, um die Torte oben, seitlich zu bestreichen und die „Krönchen“ zu setzen. Dafür habe ich nochmals fast nen halben Liter Sahne steif geschlagen, aber ohne Gelatine -> mindere Festigkeit.

Als Speisestärke verwende ich Kartoffelmehl, dieses löst sich sehr gut auch im kalten Zustand ohne zu klumpen.

Die ursprünglich empfohlene Kirschwassermenge habe ich verdreifacht (2EL -> 6EL), das war kein Fehler.

„Bewerfen“ – wie krieg ich die Raspel an die Seite -> einfach bewerfen mit „Prisen“…

How to remove ZIL (log device) from pool

Ich habe mich entschieden gehabt, von meinen beiden Pools, einem raid1 und einem raid5 die ZIL-devices (zfs intention log; „write cache“) zu entfernen. Im internet war nur zu finden, daß dies auf einen Fehler hinausläuft und nicht möglich sei.
Jetzt stand bei mir das FreeBSD upgrade von 12 auf 13 an. Das FB12 wurde heruntergefahren, die System-SSD von 512 auf 1000GB upgegraded und auf die Neue das aktuelle FreeBSD 13R installiert.
Logischerweise lief der zpool import der raid-pools in Fehler, auch ein zpool import -f <pool> schlug fehl. Es bestand aber die Möglichkeit mit einem zpool import -fm den pool zu importieren, mit zpool status sich das fehlende device mit ID anzeigen zu lassen und danach mit dem zpool remove <ID> <pool> das zil-device zu entfernen. Das scheint zu funktionieren. Glücklicherweise waren die partition-IDs, welche verwendet wurden, viel höher als die existenten…

Beim neuen openZFS kann man ohne größeren Umstände das entsprechende zil-device einfach löschen!

I have decided to eliminate my ZIL-device from my zpools, one raid1 and one raid5, implemented with ZIL-devices (zfs intention log, „write cache“). In internet I only found comments, that this is not possible.
Now, these days, I upgraded my home server from FreeBSD 12 to FreeBSD 13. The FreeBSD12 was shutdown, I have exchanged the boot-system-disk and I have installed the new FreeBSD 13 on the new disk.
Rebooting in the new system, the import of the old raid-pools fails. Also, importing with zpool -f also fails, due of „missing devices“. It was possible to import them with zpool import -fm <pool>. With zpool status you get the IDs of the missing devices and with zpool remove <pool> <ID> you can remove now the missing ZIL-devices.
Be patient, that there are no available partitions configured on the system disks, in my case, the partition numbers are higher than they are available (the device name nvd0 didn’t changed).

With the new openZFS it is possible to delete the zil-device!

bonnie++ performance Disk IO-Werte unter FreeBSD mit zfs

Hier mal ein paar performance Messungen unter FreeBSD. Messungen sind ja alle sehr relativ, der eine mag das Andere, ich mag bonnie.
Die Messungen fanden statt auf einem i5-6600, 32GB Ram und FreeBSD 12.2, bonnie++1,98. Filesystem ist ZFS. Der Cache ist 29GB groß, das ZIL 1GB.

Samsung SSD 950 PRO 512GB

bonnie benchmark Samsung SSD 950Pro — Die 950PRO dient auch als cache und ZILs für einen Raid1 und einen Raid5-zpool

Die 950 Pro wurde abgelöst – durch eine SanDisk Extreme Pro 1TB. Sie dürfte baugleich mit der WD Black Series sein, WD kaufte SanDisk vor längerem.
Die performance Messungen fanden unter FreeBSD 13-Release statt.

SanDisk Extreme Pro 1TB

Raid1 mit 2x Seagate Barracuda 4TB

Bei der initialen Erstellung meines Raid1 bestehend aus 2 Seagate 4TB Festplatten des Typs ST4000DM004 hatte ich einfach den zpool create mit den raw-devices verwendet – und damit das sector 63 Problem:

2x4GB false sec63
raid1 mit cache und log (L2ARC - 29GB, logs 1GB beides auf nvme)
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1        64G  287k  99 10.4m   1 8373k   1  720k  99  2.7g  99 200.0   4
Latency             29770us      437s      430s   14303us     391us     859ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 165.746758   0 +++++ +++ +++++ +++ 566.048702   1
Latency             28743us      41us   54405ms    1516us      20us    5952ms

Dann habe ich das sector 63 Problem behoben:

gpart show ada3
=>        40  7814037088  ada3  GPT  (3.6T)
          40        2008        - free -  (1.0M)
        2048  7814033408     1  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)

gpart show ada5
=>        40  7814037088  ada5  GPT  (3.6T)
          40        2008        - free -  (1.0M)
        2048  7814033408     1  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)

Danach interessiert man sich dafür, wofür man sich die Arbeit gemacht hat und macht mal ein paar performance Messungen, angefangen mit einer Single-disk, über Zuschaltung von cache und zuletzt dem ZIL (log):

single disk, mit zfs 
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-single 64G  306k  98  105m   7 30.1m   2  727k  98  179m   6 145.7   1
Latency             28417us   38531us    1541ms   45365us     173ms     478ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-single     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4154.577626   8 +++++ +++ +++++ +++ 3948.968091   7
Latency              1598us      36us     967ms    1535us      24us     468ms


raid1 - "naggisch"
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1        64G  299k  97 76.8m   6 40.8m   3  702k  96  232m   8 220.6   2
Latency             28550us   38345us     861ms   68444us     175ms     325ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1            -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4145.272690   8 +++++ +++ +++++ +++ 3683.089828   7
Latency              1502us      30us     899ms    1463us      83us     441ms


raid1 mit cache (L2ARC - auf 29GB nvme)
[root@alpina /raid1]# bonnie++ -r 32768 -m alpinaR1_cache -u root
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1_cache  64G  230k  89 68.9m   5 39.8m   3  720k  99  235m   8 241.0   3
Latency             33220us    7303ms     623ms   29652us     269ms     341ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1_cache      -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 2690.164896   5 +++++ +++ +++++ +++ 4142.792682   8
Latency              1511us      37us    2925ms    1473us      25us     558ms


raid1 mit cache und log (L2ARC - 29GB, logs 1GB beides auf nvme)
[root@alpina /raid1]# bonnie++ -r 32768 -m alpinaR1_cache_log -u root
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1_cache_ 64G  258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms
Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1_cache_log  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.157708   7
Latency              1560us      36us    1601ms    1470us      26us     580ms

und hier nochmal das listing im direkten Vergleich:

single disk, mit zfs im Vergleich zur Raid1 config
Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-single 64G  306k  98  105m   7 30.1m   2  727k  98  179m   6 145.7   1
Latency             28417us   38531us    1541ms   45365us     173ms     478ms
alpinaR1_cache_log   258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms

Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-single     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 4154.577626   8 +++++ +++ +++++ +++ 3948.9680 7
Latency              1598us      36us     967ms    1535us      24us     468ms
alpinaR1_cache_log   /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.1577 7
Latency              1560us      36us    1601ms    1470us      26us     580ms



2x4GB Raid1 mit false sec63 im Vergleich zur "bereinigten" config:

Version  1.98       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Name:Size etc        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alpinaR1-sec63       287k  99 10.4m   1 8373k   1  720k  99  2.7g  99 200.0   4
Latency             29770us      437s      430s   14303us     391us     859ms
alpinaR1_new         258k  99 78.9m   6 46.4m   4  700k  96  229m   8 229.2   2
Latency             33061us    7278ms     567ms     103ms     196ms     391ms

Version  1.98       ------Sequential Create------ --------Random Create--------
alpinaR1-sec63      -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 165.746758   0 +++++ +++ +++++ +++ 566.048702 1
Latency             28743us      41us   54405ms    1516us      20us    5952ms
alpinaR1_new         /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ 3669.165249   7 +++++ +++ +++++ +++ 3656.1577 7
Latency              1560us      36us    1601ms    1470us      26us     580ms

Interessant empfinde ich, daß ein Spiegel unter dem Strich erkennbar schlechtere Werte liefern kann, als die Single-disk – ausgenommen beim seq-output rewrite und seq-input-block.
Ansonsten ist der Vergleich zwischen alter RAID1 und neuer ganz passabel – man sieht deutlich schlechtere Werte in der alten RAID1-config:
seq. output Block 10MB/s zu 78MB/s,
rewrite 8k3 zu 46m,
seq Input Block 2.7g zu 229m??? ein schlechterer Wert dafür mit wesentlich weniger Last
random seeks
und allgemein weniger CPU-Last… und vor allem sieht man wesentlich geringere Latenzen -> hat sich also meiner Meinung nach gelohnt, also wird irgendwann später das Raid5 auch umgestellt!

Raid5 mit 4x Seagate IronWolf 6TB

Leider hatte ich auch bei der initialen Erstellung meines raidz1 Volumes (Raid5) aus 4x 6TB Festplatten (Seagate Ironwolf 5400rpm, ST6000VN001) nicht GPT zur Partitionierung verwendet, sondern die raw-devices direkt mit zpool angesprochen. Jetzt habe ich die Umstellung vorgenommen und vorher wie nachher bonnie++ Messungen vorgenommen (zpool in allen Fällen mit gleichen Daten gefüllt zu etwa 80%):

Benchmarking mit sector63 Fehler, mit cache, mit ZIL

Signifikanteste Verbesserungen mit korrektem Blockalignment sieht man beim sequential Output: 244 zu 311MB/s, beim rewrite von 116 zu 169MB/s, beim sequential Input Block von 296 zu 502MB/s – interessanterweise hierbei überall mit mehr CPU-Last zu vorher (meine Theorie: Daten kommen logisch sauberer im alignment auf die Platte und somit sind schneller die Parity-Berechnungen erforderlich).
Random seeks haben sich verbessert von ~138/sec zu ~173/sec.
Weitere Verbesserungen zu sehen beim sequential create die Latenz hat sich von ~12,800µs auf ~1450µs verbessert und beim Random Create von 178ms zu ~1500µs.

Das sind so die signifikantesten Verbesserungen des RAID5 Stapels, welche sich beim benchmarking zeigen. Ich unterstelle, daß ich in der Praxis bestimmt nicht soviel merken werde. Mit der Umstellung ist aber ein mögliches Bottleneck beseitigt.

Die Werte mit ZIL als Verbesserung erachte ich als vernachlässigbar, in Relation zu der damit einhergehenden Gefahr eines Total-filesystem-Verlustes mit dem Hops-gehen eines ZILs. Dafür macht man kein RAID5, um Datenverlusten vorzubeugen. Also wird beim nächsten Umbau der Systemplatte der ZIL verschwinden.

FreeBSD, ZFS und dedup

Ein paar dedup-Erfahrungen möchte ich hier mitteilen…

Dedup ist ein feature im zfs, welches Daten auf Blocklevel-Ebene dedupliziert. Wird also eine Datei zweimal in zfs-Volume kopiert, wird sie nur einmal ihren Speicherplatz beanspruchen. Aktuell habe ich in meinem Serverchen 2 zpools, einen Raid1-basierten (2x4TB) mit aktiviertem dedup und einen mit Raid5 (4x6TB).
Da dedup sehr viel memory für die Verwaltung benötigt (die sogenannten ddt-tables), wurde auf einer nvme für jeden zpool neben einem 1GB großes ZIL (zfs intent log; Pufferung von metadaten im synchronen IO) ein 29GB großer cache für den L2ARC (hier werden die ddt-Tabellen verwaltet).

[maulwurf@alpina ~]$ zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
WD14TB    12.7T  10.5T  2.24T        -         -    12%    82%  1.11x  ONLINE  -
archiv    21.8T  16.8T  5.01T        -         -    24%    77%  1.14x  ONLINE  -
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.45T   180G        -         -    47%    95%  1.17x  ONLINE  -
root       382G   257G   125G        -         -    40%    67%  1.03x  ONLINE  -

Im zpool raid1 liegt ein zfs Volume „backup“, in welches regelmäßig eine WordPress-Seite gesichert wird, sowie eines für Musik-Dateien…
Im zpool archiv befindet sich ein Time Machine-Volume (zusätzlich ein Archiv für große files), auf welches 2 High-Sierra Systeme sowie 2 Big Sur Systeme (macOS) Installationen gesichert werden.
Die Idee ist einfach: Da fallen einige „Dubletten“ an, welche hervorragend dedupliziert werden können… leider gibt aber die zpool-Statistik nur Infos aus, welche den pool als Ganzes betreffen. Im Zuge einer Optimierung der zpool device Verwaltung, muss der zpool archiv noch neu eingerichtet werden.
Für die Reorganisierung wurde eine externe Backup-Festplatte mit 14TB angeschafft, das Kopieren des zfs mit den Backupdaten (9TB/~27,000 files) via zfs send/receive geschah recht zügig mit rund 150MB/s. Danach erfolgte das gleiche Verfahren mit dem Time Machine-Volume (3.75TB/~190,000 files), welches eine Woche brauchte, anfänglich mit rund 30MB/s, letztlich bei knapp 7.6MB/s im Schnitt landete für transferierte 4.14TB (Ausgabe vom Transfer mit -v Option). Was mich verwundert, warum ~400GB mehr transferiert wurden, als vom Urpsrungsvolume angegeben wurden – die Verwunderung wird dann vom Ärger verdrängt, wenn man feststellen darf, daß beim Ziel-zpool keine compression aktiviert war…
Nunja, die Backup-Platte hat keinen L2ARC-cache, was ich als mögliche Ursache für den langsamen Transfer sehe (hat sich beim Wiederherstellen mehr oder minder bestätigt)…
Der Restore war wesentlich erfreulicher, hat er das DatenVolume beim Backup noch um rund 400GB erhöht, behielt der Prozess es diesmal bei und die Datentransferrate lag bei beachtlichen 63MB/s für das dedup-Volume.
Jetzt kommt die Frage, hat der L2ARC cache ausgereicht?, hierzu ist folgende Ausgabe als Ergebnis interessant, beim monitoring hat man die Nutzung prima verfolgen können:

maulwurf@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       4.93T  16.9T    177  2.77K  5.32M  72.4M
  raidz1    4.93T  16.9T    177  2.77K  5.32M  72.4M
    ada0p1      -      -    46    532  1.30M  26.3M
    ada1p1      -      -     43    531  1.28M  25.7M
    ada2p1      -      -     43    531  1.44M  26.3M
    ada4p1      -      -     44    532  1.42M  25.6M
  nvd0p6     128K   960M      0      0      1  24.9K
cache           -      -      -      -      -      -
  nvd0p7    19.5G  9.52G    504     41  1.20M  3.09M
----------  -----  -----  -----  -----  -----  -----

von den zur Verfügung stehenden 29GB (L2ARC cache) werden in etwa 2/3 genutzt, für dieses Volume also ausreichend (?)- der ZIL wird fast gar nicht verwendet (mehr oder minder logisch)…
Jetzt kopier ich noch das rund 300GB große Backup-Volume vom raid1 pool in den raid5 –

11:08:51    303G   raid1/backup@backup
received 303GB stream in 5217 seconds (59.5MB/sec)
[root@alpina /raid5]# zpool iostat -v raid5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
raid5       5.31T  16.5T    176  2.76K  5.02M  71.2M
  raidz1    5.31T  16.5T    176  2.76K  5.02M  71.2M
    ada0p1      -      -     46    532  1.22M  25.9M
    ada1p1      -      -     43    531  1.21M  25.2M
    ada2p1      -      -     43    531  1.35M  25.9M
    ada4p1      -      -     44    532  1.33M  25.2M
  nvd0p6     256K   960M      0      0      1  48.2K
cache           -      -      -      -      -      -
  nvd0p7    18.6G  10.4G    515     41  1.22M  3.05M
----------  -----  -----  -----  -----  -----  -----

Man sieht hier sogar noch eine Abnahme der cache (L2ARC) Nutzung.

Interessant zur Berechnung benötigter Ressourcen ist der Artikel „dedup or not dedup„, in welchem auch beschrieben wird, wieviel voraussichtlich an ARC-Speicher benötigt wird, in meinem hier betrachteten Falle (vor Umstellung):

[root@alpina ~]# zdb -b raid1 

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
3.87T completed (3323MB/s) estimated time remaining: 277098hr 45min 20sec        
	No leaks (block sum matches space maps exactly)

	bp count:              35419785
	ganged count:                 0
	bp logical:       4477203583488      avg: 126404
	bp physical:      4252535812096      avg: 120061     compression:   1.05
	bp allocated:     4270123028480      avg: 120557     compression:   1.05
	bp deduped:        463651233792    ref>1: 1992696   deduplication:   1.11
	Normal class:     3806470971392     used: 95.50%

	additional, non-pointer bps of type 0:     132437
	Dittoed blocks on same vdev: 1466474

[root@alpina ~]# zdb -b archiv

Traversing all blocks to verify nothing leaked ...

loading concrete vdev 1, metaslab 14 of 15 .....
17.5T completed (14304MB/s) estimated time remaining: 341616hr 56min 05sec        
	No leaks (block sum matches space maps exactly)

	bp count:             111509014
	ganged count:                 0
	bp logical:      14381112954368      avg: 128968
	bp physical:     13922814364672      avg: 124858     compression:   1.03
	bp allocated:    19192156401664      avg: 172113     compression:   0.75
	bp deduped:        710846349312    ref>1: 3355041   deduplication:   1.04
	Normal class:    18481309908992     used: 77.06%

	additional, non-pointer bps of type 0:     197376
	Dittoed blocks on same vdev: 1664068

Rechnet man den Speicherbedarf für den pool raid1 aus (bp count: 35419785 x 320bytes), kommt man auf ~10GB; bei knapp 32GB Ram und der Kausalität, daß für dedup nur ca 25% vom ARC genutzt werden, ist der Hauptspeicher definitiv zu klein.
Der pool archiv mit seinem Time Machine-Volume würde um die 33GB beanspruchen wollen.

Somit habe ich mittlerweile den Entschluss gefasst, auf dem RAID1 keine Deduplikation mehr zu verwenden und das backup-zfs auf das archiv umzuziehen, sowie den L2ARC für archiv auf 96GB zu erweitern.

Das „Ende“ aktuell vom Lied:

[maulwurf@alpina ~]# zpool list
NAME       SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
backup3G  2.72T   497G  2.23T        -         -     0%    17%  1.00x  ONLINE  -
raid1     3.62T  3.19T   443G        -         -    41%    88%  1.19x  ONLINE  -
raid5     21.8T  17.2T  4.60T        -         -     6%    78%  1.16x  ONLINE  -
root       382G   259G   123G        -         -    41%    67%  1.03x  ONLINE  -

References:
zfs dedup or not dedup
zfs, arc overview
memory requirements dedup/L2ARC

Lachsravioli selbst gemacht

Ravioli mit Lachsfüllung

Teig:
200g Mehl, zwei Eier, einen halben Esslöffel Olivenöl, Salz
Alles vermischen und zu einen Teig kneten. Wenn zu bröselig etwas mehr Olivenöl oder auch wenig warmes Wasser dazu geben. Teig in Frischhaltefolie einschlagen und mindestens eine Stunde im Kühlschrank ruhen lassen. Bei mir war es die ganze Nacht, auch egal.

Füllung:
Eine Schalotte klein hacken, ca 150g Lachs klein hacken wie Tartar, eine halbe Knoblauchzehe sehr fein hacken, frischer Dill gehackt, ein paar Esslöffel Frischkäse, Salz und Pfeffer. Alles miteinander abschmecken.

Teig sehr dünn ausrollen, ausstechen rund oder eckig. Unterseite mit Füllung belegen, Rand mit warmen Wasser einstreichen, Oberseite auflegen, Rand zusammendrücken und mit Gabel rundherum eindrücken.

Ravioli in kochendes gesalzenes Wasser legen. Bei Pasta gilt, wenn man meint es wäre genug Salz im Wasser – noch etwas dazu geben.
Kochzeit je nach Größe. Die Ravioli müssen oben schwimmen.

Dazu passt eine helle Dillsoße. Ich habe etwas anderes genommen.

Braune Butter mit Dillaroma:
Butter in einem Topf erhitzen bis sich am Boden braune Kugeln bilden. Dann Butter durch ein Küchkrepp sieben, Topf reinigen, die flüssige Butter wieder zurück in den Topf und mit frischen Dillzweigen erhitzen lassen. Unbedingt beobachten. Der Dill darf nicht verbrennen. Dill entfernen und die flüssige Butter über die Ravioli gießen. Den Rest kann man in ein Glas geben und im Kühlschrank aufbewahren. Aromatisierte braune Butter kann man immer brauchen.

Garnieren kann man die Ravioli noch mit etwas frischem Dill. Ich habe mir das gespart.

Quelle: http://www.rc-network.de/forum/showthread.php/40225-Neue-Rubrik-Kulinarisches?p=3223423&viewfull=1#post3223423

FreeBSD jail update

Update eines FreeBSD jail:

iocage fetch (holt ein neues RELEASE)
iocage upgrade -r 12.2 <jail-name> (Update auf 12.2-RELEASE)
iocage update <jail-name>

FreeBSD 12 und apache im jail

echo "a.b.c.d  wwwhost.guckux.test wwwhost" >> /etc/hosts
iocage create -r 12.1-RELEASE -n www ip4_addr="em0|192.168.178.44"

Erzeugen eines host-Eintrages für den jail.
Erstellen eines jails mit FreeBSD 12.1-RELEASE, mit dem jail-Namen „www“ und einer IP-Adresse gehörig zum interface em0.

iocage start www

Starten des jails „www“.

iocage pkg www install apache24
alternativ:
iocage console www
pkg install apache24
echo "apache24_enable="YES"" >> /etc/rc.conf

Hiermit installieren wir mit dem package tool das apache environment in der iocage „www“.
Alternativ kann man das im jail selbst tun, ich bevorzuge die Installation vom „Hypervisor“ System selbst, da dann Pakete zB für andere jails nicht wiederholt geholt werden (ausser es gibt aktuellere 😀 ). Aktuell bei mir allerdings, wird die Anzeige, zur Bestätigung, ob man die Pakete installieren möchte, nicht angezeigt – heisst blind „Y“ tippen und Enter 😉
Dann muss er noch enabled werden, damit er startet, wenn man den jail startet.

Dann machen wir es gleich richtig machen und wollen das mit SSL konfigurieren:

iocage console www
mkdir /etc/ssl/private
mkdir /etc/ssl/certs
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/selfsigned.key -out /etc/ssl/certs/selfsigned.crt

Die Verzeichnisse gibt es noch nicht, werden aber benötigt – danach generieren wir den key und werden nach verschiedenen Parameter gefragt:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Hessen
Locality Name (eg, city) []:Gross-Gerau
Organization Name (eg, company) [Internet Widgits Pty Ltd]:guckux.de
Organizational Unit Name (eg, section) []:testing
Common Name (e.g. server FQDN or YOUR name) []:wwwhost.guckux.test

vi /usr/local/etc/apache24/httpd.conf
und
LoadModule ssl_module libexec/apache24/mod_ssl.so
LoadModule authn_socache_module libexec/apache24/mod_authn_socache.so
LoadModule ssl_module libexec/apache24/mod_ssl.so
Include etc/apache24/extra/httpd-ssl.conf

Die LoadModule einkommentieren (aktivieren) und das ssl aktivieren.

Wir erstellen eine Sicherheitskopie von der ssl Konfiguration und bearbeiten unsere config:

cp /usr/local/etc/apache24/extra/httpd-ssl.conf \ /usr/local/etc/apache24/extra/httpd-ssl.conf.bak
vi /usr/local/etc/apache24/extra/httpd-ssl.conf

# General setup for the virtual host
DocumentRoot "/usr/local/www/apache24/data"
ServerName wwwhost.guckux.test:443
ServerAdmin user@host
ErrorLog "/var/log/httpd-error.log"
TransferLog "/var/log/httpd-access.log"
ServerName wwwhost.guckux.test:443
ServerAdmin user@host
SSLCertificateFile "/etc/ssl/certs/selfsigned.crt"
SSLCertificateKeyFile "/etc/ssl/private/selfsigned.key"
SSLStaplingCache "shmcb:/var/run/ssl_stapling(32768)"
SSLSessionCache         "dbm:/var/run/ssl_scache"

und die Änderungen im https-ssl.conf vornehmen.

Wenn ich nichts vergessen habe - sollte es das gewesen sein ;)

mousse au chocolat

Zutaten:
3 Tafeln (300g) Stollwerk Herren Schokolade
400ml Sahne
8 Eier
2-3 Kaffeelöffel schwach entölter Kakao
2 Kaffeelöffel feinst gemahlener Espresso

Als Kind liebte ich schon die Mousse au chocolat, und verfluchte es, weil meist nach wenigen Kaffeelöffeln einem der Mund zuklebt.

Also musste etwas gefunden werden, was schokoladiger es nicht gibt und einfach lecker ist.

Zubereitung:

Die Schokolade im Wasserbad langsam erwärmen, sie darf nur flüssig werden, Hinzu gibt man schon am Anfang den Kakao und den fein gemahlenen Espresso. Etwas ziehen lassen, dann kann der Espresso seinen Charakter entfalten.

In der Zwischenzeit trennt man Eigelb vom Eiweiß, schläft das Eiweiß (8) steif, dann die Sahne steif schlagen und zuletzt kann man das Eigelb (von 7 Eiern) schaumig schlagen.

Ist die Schokolade angenehm flüssig, zwischenzeitlich kann man sie mit dem Kakao und Espresso verrühren, gibt man zuerst das Eigelb hinzu, gut verrühren – hurtig hurtig, die Masse fängt schnell an fest zu werden, schwups die Sahne hinzu. Man darf noch flott weiter rühren, bis sich braun/weisse Schlieren durch die Masse ziehen. Jetzt hebt man liebevoll (GRINS) das steif geschlagene Eiweiss unter bis man eine einheitliche braune Substanz hat.

Anschließend mindestens 4 Stunden in den Kühlschrank, ich wünsche Guten Appetit.

Die Masse reicht für etwa 12-14 Personen…Anmerkungen:

Anmerkungen:
– keine Lindt, oder gar die Billig-Milka, alles andere ist unbrauchbar!
– Sahne, ich nehm die ultrahocherhitzte haltbare Beutelsahne aus dem Supermarkt, mit frischer Bio-Sahne gelingt es mir irgendwie nicht so dolle…
– Eier – Anzahldiffereinzierung, wenn man noch ein Eigelb weniger nimmt, wird sie noch „lockerer/luftiger“