WEBVTT 00:00:27.460 --> 00:00:33.390 Ja, wir sind jetzt hier auf dem Open Source Summit 2026 in Prag. 00:00:33.390 --> 00:00:35.970 Bei mir ist Werner Fischer. Hallo Werner. 00:00:36.080 --> 00:00:37.293 Ja, hallo Ingo, grüß dich. 00:00:37.584 --> 00:00:43.190 Du arbeitest bei Thomas Krenn und hast hier einen Vortrag gehalten über Caching, 00:00:43.190 --> 00:00:45.660 über den Caching Layer von Linux. 00:00:46.220 --> 00:00:46.651 Ja, genau. 00:00:47.139 --> 00:00:49.550 Genau, das machst du jetzt eine Weile schon. Du tourst immer so ein bisschen 00:00:49.550 --> 00:00:55.927 durch die Gegend und erzählst ziemlich viel über das, warum, also wie kam es dazu? 00:00:56.299 --> 00:00:57.785 Warum hast du dich dafür interessiert? 00:00:57.919 --> 00:01:00.410 Ja, es ist eigentlich ein bisschen ein Zufall gewesen. Also es ist schon eine 00:01:00.410 --> 00:01:03.108 Weile her. Ich bin schon lange mittlerweile bei Thomas Krenn. 00:01:03.776 --> 00:01:09.569 Und es war auch zufällig hier in Prag 2011, also vor 15 Jahren genau genommen. 00:01:10.214 --> 00:01:13.620 Ich wollte mal verstehen, wie der Linux Storage Stack so funktioniert. 00:01:13.620 --> 00:01:16.976 Was passiert eigentlich, wenn ich eine Datei speichere und die später lese? 00:01:17.627 --> 00:01:20.890 Und das war so der Beginn, dass ich da wirklich tief in den Storage-Thema reingekommen 00:01:20.890 --> 00:01:24.250 bin. Wir hatten damals auch schon viel mit Rate-Controller natürlich zu tun 00:01:24.250 --> 00:01:27.260 und Caching war da auch immer schon ein bisschen ein Thema. 00:01:27.580 --> 00:01:31.590 Ganz zu Beginn gab es ja zum Teil auch Probleme, wie noch keine Bright-Barriers 00:01:31.590 --> 00:01:34.780 waren in Dateisystemen. Wenn da der Cache der Festplatte aktiviert war, 00:01:34.780 --> 00:01:37.520 könnte es zu Datenverlust kommen. Das heißt, das waren immer schon ein bisschen 00:01:37.520 --> 00:01:40.104 Themen, die ein bisschen in der Schwebe waren und mir nicht ganz klar waren. 00:01:40.737 --> 00:01:43.880 Und ja, da habe ich dann begonnen, ein paar Kernel-Lücker zu fragen und das 00:01:43.880 --> 00:01:47.633 war so der Beginn, dass ich da tiefer reingekommen bin. 00:01:48.103 --> 00:01:52.710 Okay, und dann habt ihr euch jetzt zusammengesetzt und habt diskutiert, 00:01:52.710 --> 00:01:57.980 wie das alles funktioniert. Du hast gerade auch diese Write Barriers wehnt. Was bedeutet das? 00:01:58.392 --> 00:02:02.610 Ja, im Endeffekt geht es dabei um Folgendes. Wenn ich jetzt Daten speichere, 00:02:02.610 --> 00:02:08.290 um einen modernen Linux-System sozusagen, dann sind in der Regel ja bei den 00:02:08.290 --> 00:02:11.220 Festplatten schon seit geraumer Zeit Caches involviert. 00:02:11.220 --> 00:02:13.890 Das heißt, ich habe auf der Festplatte ein Cache und wenn es einen Stromausfall 00:02:13.890 --> 00:02:16.499 gibt, dann ist der Inhalt des Caches dann weg, im schlimmsten Falle. 00:02:16.981 --> 00:02:20.830 Jetzt könnte man meinen, naja, wenn wir die letzten 5 oder 10 Sekunden abgehen, 00:02:20.830 --> 00:02:22.041 dann stört mir das nicht sonderlich. 00:02:23.012 --> 00:02:27.893 Allerdings ist es so, dass die modernen Dateisysteme ja mit den Journaling-Mechanismen 00:02:27.893 --> 00:02:31.063 sozusagen auf eine bestimmte Reihenfolge angewiesen sind. Das heißt, 00:02:31.063 --> 00:02:35.033 wenn ich Daten schreibe, ist es dann nicht unbedingt egal, in welcher Reihenfolge 00:02:35.033 --> 00:02:36.568 die dann auf der Festplatte ankommen. 00:02:37.148 --> 00:02:41.033 Und auch schon seit vielen Jahren, also als wir noch jung waren, 00:02:41.033 --> 00:02:45.963 sage ich jetzt einmal, gab es eine neue Technologie, die sich Native Command Queuing nannte. 00:02:45.963 --> 00:02:50.223 Und wo die Festplatten begonnen hatten, die Reihenfolge der Daten zu verändern, 00:02:50.223 --> 00:02:53.003 wenn sie geschrieben wurden, einfach um die Performance zu verbessern. 00:02:53.003 --> 00:02:57.433 Wenn die Festplattenfirma entdeckt hat, naja, die Daten, die ich jetzt schreiben möchte, 00:02:57.893 --> 00:03:00.983 da kann ich jetzt das dritte Datenelement vom zweiten schreiben, 00:03:00.983 --> 00:03:05.433 weil es fliegt mir gerade unter den Schreiblesekopf vorbei, dann passiert das 00:03:05.433 --> 00:03:08.968 automatisch und ich habe damit auch eine schnellere Performance oder höhere Performance. 00:03:09.711 --> 00:03:13.653 Allerdings kann das dann zu Problemen werden, wenn es zu einem Stromausfall 00:03:13.653 --> 00:03:18.293 kommt und dann tatsächlich das Datum 3 geschrieben wurde und das Datum 2 noch 00:03:18.293 --> 00:03:19.573 im Cache sitzt sozusagen. 00:03:19.573 --> 00:03:23.263 Und das war dann der Beginn dieser sogenannten White Barriers, 00:03:23.263 --> 00:03:26.163 dass eben Dateisysteme sagen, okay, wenn ich einen F-Sync mache, 00:03:26.163 --> 00:03:29.163 dann muss mal alles wirklich aus dem Cache rausgeschrieben werden, 00:03:29.163 --> 00:03:30.586 der Cache komplett entleert werden, 00:03:31.074 --> 00:03:35.713 damit die Daten praktisch zu diesem Zeitpunkt mal komplett auf dem permanenten 00:03:35.713 --> 00:03:40.815 Speicher sind, bevor ich dann was schreibe, was von den davor liegenden Daten abhängig ist. 00:03:41.232 --> 00:03:45.543 Okay, ist dann bei mir quasi ein Datum, eine Datei oder was auch immer fertig 00:03:45.543 --> 00:03:47.833 geschrieben habe, bevor ich irgendwas anderes anfange? 00:03:48.169 --> 00:03:50.993 Ja, genau, also konkret geht es da auch um die Metadaten. Also wenn ich jetzt 00:03:50.993 --> 00:03:54.053 im Laufe der Mitreiber einen Stromausfall habe, da war es ja ganz früher so, 00:03:54.053 --> 00:03:56.639 dass das dann ewig gedauert hat, einen File System Check zu machen, 00:03:57.115 --> 00:04:00.253 mit den Journalen geht das dann schneller und dort ist es dann halt wichtig, 00:04:00.253 --> 00:04:02.264 in welcher Reihenfolge die Daten geschrieben werden. 00:04:03.135 --> 00:04:07.412 Und damit kamen dann diese sogenannten White Barriers dann auch ins Spiel. 00:04:07.412 --> 00:04:10.122 Und das war auch schon zu Beginn, wo man erkannt hatte, naja, 00:04:10.122 --> 00:04:11.882 es wäre ganz gut, das ein bisschen zu verstehen. 00:04:12.222 --> 00:04:15.992 Was passiert denn da tatsächlich? Und man konnte und kann nach wie vor an vielen 00:04:15.992 --> 00:04:18.179 Ebenen, an vielen Schrauben drehen. 00:04:18.742 --> 00:04:22.912 Und ja, das war dann der Einstieg, das Ganze mal im Diagramm zu bringen, 00:04:22.912 --> 00:04:26.533 sozusagen einfach für das eigene Verständnis. Und das hat sich dann auch ganz gut bewährt. 00:04:26.776 --> 00:04:31.482 Okay, also du hast ein Diagramm entworfen, wo man quasi für den aktuellen Linux-Körnel oder, 00:04:32.782 --> 00:04:37.032 zumindest für einige verschiedene Versionen sieht, wie dieser ganze Mechanismus 00:04:37.032 --> 00:04:42.332 aufgebaut ist von Linux-Körnel mit allen Caches, mit virtuellen Fallsystemen 00:04:42.332 --> 00:04:44.582 bis hin zu den Festplatten sozusagen. 00:04:44.942 --> 00:04:48.142 Ja, genau. Und das war auch ganz lustig. Das war eben auch da vor 15 Jahren 00:04:48.142 --> 00:04:51.802 in Prag. Da ist man zufällig, damals hat man auch an Stand von Thomas Grenn 00:04:51.802 --> 00:04:55.862 hier, der Christoph Helwig, einen Weg gelaufen. Also viele kennen ihn ja. 00:04:55.862 --> 00:04:58.582 Da ist im NVME-Sable zum Beispiel sehr aktiv. 00:04:59.047 --> 00:05:01.984 Und das war auch ganz lustig. Ich habe ihn dann gefragt, kann man das so zeichnen? 00:05:02.355 --> 00:05:05.602 Und dann kamen weitere Kernentwickler vorbei, der Hannes Reinecke, 00:05:05.942 --> 00:05:09.732 der hat sich dann auch super eingebracht und war die ersten zehn Minuten sehr 00:05:09.732 --> 00:05:12.495 interessant zum Zuhören und dann hat man auch gemerkt, okay, 00:05:13.011 --> 00:05:17.242 dann wurde es von einem normalen Gespräch immer mehr zu einer Diskussion und 00:05:17.602 --> 00:05:21.806 weil man hat natürlich viele Vereinfachungen auch eingezeichnet und aber wir haben dann, 00:05:22.522 --> 00:05:25.582 einen Weg gefunden, wie man das Ganze darstellen kann und da, 00:05:26.242 --> 00:05:29.122 ist es auch netterweise so, dass die Entwickler auch sich immer wieder einbringen, 00:05:29.122 --> 00:05:31.088 immer eine Nachfrage sozusagen und, 00:05:31.692 --> 00:05:35.662 ja, jetzt versuche ich immer das am letzten Stand des letzten LTS-Körnels zu 00:05:35.662 --> 00:05:39.882 halten sozusagen, wenn man noch Linux-Storage-Stack-Diagramm sucht, 00:05:39.882 --> 00:05:42.862 findet man es auch ganz schnell und ist auch CC BY SA lizenziert, 00:05:42.862 --> 00:05:44.388 das heißt man kann es auch abwenden, wenn man möchte. 00:05:45.063 --> 00:05:49.720 Sehr schön, abdrucken, alles möglich. Jetzt habe ich gerade schon Virtual File 00:05:49.720 --> 00:05:54.380 System erwähnt, vielleicht kannst du das nochmal erklären, was versteht man 00:05:54.380 --> 00:05:56.125 bei Linux unter dem Virtual File System? 00:05:56.258 --> 00:05:59.610 Ja, sehr gerne. Also das ist ein Konzept, das gibt es sogar schon länger als 00:05:59.610 --> 00:06:03.462 es Linux gibt. Also es ist schon zu Unix-Zeiten entstanden sozusagen. 00:06:03.956 --> 00:06:08.020 Also ganz früh in den 60er Jahren war es eben so, da mussten die Anwendungen 00:06:08.020 --> 00:06:11.927 selber wissen, welches Dateisystem zum Einsatz kommt, wie in die Datei geschrieben wird. 00:06:12.403 --> 00:06:16.107 Und das virtuelle Dateisystem, sozusagen das VFS, dieser Layer, 00:06:16.496 --> 00:06:20.942 macht immer eine Abstraktion, dass ich sozusagen generisch einen Lesevorgang, einen Schreibvorgang, 00:06:21.389 --> 00:06:24.760 aus der Applikation heraus machen kann und es spielt überhaupt keine Rolle, 00:06:24.760 --> 00:06:29.200 ob es um ein lokales, blockbasiertes Dateisystem geht, ein netzwerkbasiertes 00:06:29.200 --> 00:06:33.082 Dateisystem oder auch um ein Proc-Filesystem oder was ähnliches sozusagen. 00:06:33.535 --> 00:06:37.245 Dieses EOS-Ling-Esser-File, File-Socket unter Linux sozusagen, 00:06:37.809 --> 00:06:41.070 ist damit auch möglich und ich kann nicht sozusagen auf Dateien zugreifen, 00:06:41.070 --> 00:06:44.867 ganz egal, ob das jetzt Device-Driver-Files sind oder ähnliches und, 00:06:45.529 --> 00:06:48.957 Und das ist auch die Basis dafür, dass vieles unter Linux so einfach von der 00:06:48.957 --> 00:06:53.303 Kommandozeile aus funktioniert und dieses Konzept auch aufgeht. 00:06:53.419 --> 00:06:56.207 Also die Applikation muss einfach gar nichts darüber wissen. 00:06:56.547 --> 00:07:01.696 Der kann es auch egal sein, ob das jetzt auf dem Network-File-System liegt oder lokal. 00:07:02.079 --> 00:07:04.937 Es sieht für die Applikation erstmal gleich aus. Für den User fühlt es sich 00:07:04.937 --> 00:07:08.607 vielleicht nicht gleich an, aber immerhin ist es eine Abstraktionsschicht. 00:07:08.950 --> 00:07:14.547 Dann hast du ja ganz viel über Caches jetzt auf deinem Vortrag hier abgezielt. 00:07:15.647 --> 00:07:19.057 An welchen Stellen finde ich dann überall Caches und wie hilft mir das oder 00:07:19.057 --> 00:07:20.307 hilft mir das vielleicht auch nicht? 00:07:20.776 --> 00:07:24.097 Also im Endeffekt geht es bei den Caches im Storage-Stack vor allem darum, 00:07:24.097 --> 00:07:25.936 auch Datenzugriffe zu beschleunigen. 00:07:26.297 --> 00:07:29.987 Das heißt, ich möchte Daten schneller bekommen oder schneller schreiben, 00:07:29.987 --> 00:07:32.687 als es oftmals die relativ langsameren 00:07:33.007 --> 00:07:35.737 Storage-Speicher dann sozusagen tatsächlich dann auch tun können. 00:07:35.737 --> 00:07:38.777 Also auch bei der Festplatte merkt man es ja auch direkt bei den SSDs, 00:07:38.777 --> 00:07:42.337 es ist schon besser geworden. Aber in Relation zum Arbeitsspeicher bin ich natürlich 00:07:42.337 --> 00:07:43.967 trotzdem noch umweltenlangsamer. 00:07:44.787 --> 00:07:48.167 Und da bin ich auch schon beim Stichwort Arbeitsspeicher, also der erste Cache, 00:07:48.167 --> 00:07:49.752 dem mir dann begegnet, ist der PageCache. 00:07:50.252 --> 00:07:55.435 Linux nützt sozusagen den freien Arbeitsspeicher automatisch als Cache. 00:07:56.119 --> 00:08:00.655 Ein Beispiel, wenn ich jetzt ein 2 GB ISO lese und irgendwann das hinkopieren 00:08:00.655 --> 00:08:05.775 möchte, dann wird dieses ISO auch zu Beginn gleich mal in den Arbeitsspeicher, 00:08:05.775 --> 00:08:06.915 in den PageCache geladen. 00:08:07.409 --> 00:08:10.995 Und wenn ich kurz darauf das auf einen zweiten Datenträger oder ins Netzwerk 00:08:10.995 --> 00:08:14.165 rüberschieben möchte, dann liegen die Daten bereits im Arbeitsspeicher. 00:08:14.165 --> 00:08:18.175 Das heißt, Linux muss dann nicht mehr der Kernel auf das langsamere Medium, 00:08:18.175 --> 00:08:22.125 auf die Festplatte beispielsweise zugreifen, sondern hat die Daten sofort parat. 00:08:22.125 --> 00:08:25.015 Also beim Lesen geht es sehr einfach, das bleibt einfach drinnen. 00:08:25.015 --> 00:08:28.085 Und wenn ich so ein weiteres Mal brauche, geht der nächste Lesezugriff extrem 00:08:28.085 --> 00:08:30.199 schnell, weil er aus dem Arbeitssprecher kommt. 00:08:30.634 --> 00:08:33.335 Beim Schreiben sieht es ein bisschen anders aus. Da muss ich natürlich dann 00:08:33.335 --> 00:08:36.486 gewährleisten, dass ich regelmäßig die Daten auch tatsächlich runterschreibe, 00:08:36.991 --> 00:08:41.345 weil beim Stromausfall geht mir der Cache natürlich verloren und da kommen dann 00:08:41.345 --> 00:08:46.435 diese Kernel-Internas zum Einsatz und von der Applikation muss ich es halt insofern 00:08:46.435 --> 00:08:49.155 handeln, wenn ich sage, das muss jetzt wirklich sofort auf Disk gehen, 00:08:49.155 --> 00:08:51.189 dann muss ich ein entsprechendes Sync machen, F-Sync machen. 00:08:52.188 --> 00:08:54.870 Funktion nutzen und dann geht 00:08:54.870 --> 00:08:58.530 es eben weiter runter auf die nächsten Schichten, den Blocklea runter. 00:08:58.925 --> 00:09:01.820 Es könnte auch noch über eine ViseMapper gehen, da könnte ich noch weitere Caches 00:09:01.820 --> 00:09:04.550 dann nützen, die ich gar nicht eben im Vordergrund erwähnt habe. 00:09:05.467 --> 00:09:09.480 Also das wäre dann so Thematiken wie ein SST-Cache vor eine Festplatte zu setzen, 00:09:09.480 --> 00:09:11.237 beispielsweise. Das kann ich damit machen. 00:09:11.655 --> 00:09:15.110 Oder auch mit Dateisystemen wie ZFS, die jetzt nicht Teil des Linux-Kernels 00:09:15.110 --> 00:09:16.502 sind, da kann ich es natürlich auch machen. 00:09:17.176 --> 00:09:20.720 Aber wenn es weiter runter geht, dann wird es auch nochmal spannend eben, 00:09:21.020 --> 00:09:24.720 wie schon eingangs erwähnt, wenn die Devices selber auch Caches haben. 00:09:25.138 --> 00:09:29.260 Genau, die haben auch Caches. Da muss ich auch aufpassen, weil du hast ja gesagt, 00:09:29.260 --> 00:09:31.579 wenn ein Stromausfall ist, sind die dann weg. 00:09:32.160 --> 00:09:36.190 Außer bei Enterprise-Festplatten. Die haben nochmal so einen speziellen Mechanismus, 00:09:36.190 --> 00:09:37.733 dass sie sich davor schützen. 00:09:37.895 --> 00:09:42.420 Ja, genau. Vor allem bei Enterprise-SSDs ist es bekannt und den Namen Paulus 00:09:42.420 --> 00:09:45.912 Protection, das ja verbreitet ist, das sichert im Falle eines Stromausfalls, 00:09:46.748 --> 00:09:52.940 den Cache insofern, ob das sozusagen den Inhalt auf dem SSD-Cache in diesem 00:09:52.940 --> 00:09:56.030 Arbeitsspeicher dann noch mit einer Energie, die in Kondensatoren gespeichert 00:09:56.030 --> 00:09:58.119 ist, auf den permanenten Flash rüberkopiert. 00:09:58.613 --> 00:10:03.602 Manche Enterprise-Button können das auch, ist aber eher dennoch auch die Ausnahme sozusagen. 00:10:04.828 --> 00:10:08.360 Schützend tut man sich in der Regel davor, dass man entweder diesen Cache abdreht sozusagen. 00:10:08.360 --> 00:10:10.790 Das war früher der Fall, wenn ich jetzt einen Rate-Controller gehabt habe, 00:10:10.790 --> 00:10:13.739 der bei sich dann auch wieder einen Cache mit integriert hatte, 00:10:14.232 --> 00:10:17.920 oder integriert hat, den ich wiederum auch mit speziellen Schaltungen, 00:10:17.920 --> 00:10:22.390 mit Kondensatoren beispielsweise schütze, dass dann der hinterliegenden Festplatten 00:10:22.390 --> 00:10:27.040 den Cache abgedreht bekommen, weil diese in der Relation zum Rate-Controller-Cache 00:10:27.040 --> 00:10:28.803 sehr klein sind sozusagen. 00:10:29.470 --> 00:10:32.660 Wenn ich das jetzt nicht habe, keinen Rate-Controller mit dem Software-Defend-Storage, 00:10:32.660 --> 00:10:33.824 hat man das immer seltener ja. 00:10:35.041 --> 00:10:39.361 Dann sollen vor allem diese Whitebears auch davor schützen, aber im Data Center 00:10:39.361 --> 00:10:44.011 trifft man sehr häufig diese Mechanismen an, dass ich eben dort auch den Cache 00:10:44.011 --> 00:10:45.454 nochmal geschützt habe. 00:10:46.232 --> 00:10:50.984 Kommen wir gleich vielleicht nochmal dazu, aber wir hatten ja diesen Linux Page Cache erwähnt. 00:10:51.841 --> 00:10:56.251 Wenn ich jetzt quasi meinen ganzen RAM vollgeladen habe mit irgendwelchem Zeug, 00:10:56.251 --> 00:10:58.701 also ich brauche meinen Arbeitsspeicher auch noch für andere Sachen, 00:10:59.061 --> 00:11:03.561 wie funktioniert das? Wann schmeißt er das wieder weg? Gibt es eine vorgegebene Zeit? 00:11:04.141 --> 00:11:07.041 Ja, also da gibt es insgesamt vier Parameter, die man da auch setzen kann, 00:11:07.041 --> 00:11:11.490 die auch standardmäßig ganz sinnvoll gesetzt sind. Die findet man im Sys-File-System sozusagen. 00:11:11.686 --> 00:11:15.459 Da sind zwei Dinge relevant. Zum einen gibt es so Prozentwerte sozusagen, 00:11:15.800 --> 00:11:19.761 wo der Linux-Kernel dann beginnt, die Daten tatsächlich rauszuschreiben. 00:11:19.761 --> 00:11:24.321 Standardmäßig ist es so, dass er bei 10% des verfügbaren Arbeitsspeichers, 00:11:24.321 --> 00:11:29.641 sobald der mit Dirty Pages belegt ist, sozusagen beginnen die Kernelflasher-Threads, 00:11:29.981 --> 00:11:31.317 die Daten rauszuschreiben. 00:11:31.717 --> 00:11:36.001 Einen weiteren Wert, der standardmäßig bei 20% gesetzt ist, dann muss die Applikation 00:11:36.001 --> 00:11:39.481 dann sozusagen auch schon ein bisschen Performance-Einbußen hinnehmen, 00:11:39.481 --> 00:11:42.221 weil er praktisch während des Schreibvorgangs schon beginnt, 00:11:42.221 --> 00:11:44.482 das Ganze auch tatsächlich runter auf Disk zu schreiben. 00:11:44.976 --> 00:11:49.061 Ansonsten hätte ich ja die Gefahr, dass der Arbeitsspeicher komplett voll läuft sozusagen. 00:11:49.821 --> 00:11:52.611 Und das möchte man natürlich an der Stelle nicht. 00:11:52.611 --> 00:11:57.901 Das heißt, diese beiden Prozentwerte sollen gewährleisten, dass ich immer um 00:11:57.901 --> 00:12:02.971 die 80 Prozent des verfügbaren Speichers auch mit nicht-dirty Pages belegt habe. 00:12:02.971 --> 00:12:05.671 Also ich habe beim Page-Cash nicht nur die dirty Pages, sondern auch die, 00:12:05.671 --> 00:12:07.513 die ich einfach halt gelesen habe sozusagen. 00:12:08.076 --> 00:12:12.030 Die kann ich ja bei Bedarf sehr schnell verwerfen, als Kernel sozusagen, 00:12:12.465 --> 00:12:15.217 weil es ja da nur Daten gibt, die ohne dies. 00:12:15.989 --> 00:12:19.010 Auf dem Storager liegen, die kann ich jederzeit im Cache verwerfen, 00:12:19.010 --> 00:12:21.637 aber bei den Dirty Pages muss ich immer achten, die rauszuschreiben. 00:12:22.066 --> 00:12:24.185 Und zusätzlich gibt es noch Zeitwerte sozusagen. 00:12:24.675 --> 00:12:29.830 Da gibt es zum einen mal einen Wert, wie alt muss ein Dateninhalt, 00:12:29.830 --> 00:12:34.490 eine Page, zwingend alt sein, damit sie mal überhaupt berücksichtigt wird zum 00:12:34.490 --> 00:12:37.090 Schreiben. Das ist in der Standardfall so fünf Sekunden gestellt. 00:12:37.870 --> 00:12:42.645 Und des Weiteren gibt es noch den Wert sozusagen, Irgendwann dann immer wieder 00:12:42.807 --> 00:12:47.744 dieser Kernflasche-Thread aktiviert wird und direkt bei 30 Sekunden sozusagen 00:12:48.127 --> 00:12:50.010 von der Einstellung her. 00:12:50.030 --> 00:12:53.430 Und sind das sinnvolle Defaults, würdest du sagen? 00:12:53.430 --> 00:12:57.310 Ja, genau. Es gibt eigentlich selten den Bedarf, das anzupassen. 00:12:57.310 --> 00:13:00.127 Es gibt manche Distributionen oder wenn man sagt, man möchte es irgendwie für... 00:13:01.234 --> 00:13:05.688 Ja, Power-Safing-Mechanismen ändern, dann kann man sagen, ich erhöhe die 5 Sekunden 00:13:05.688 --> 00:13:11.178 auf 15 Sekunden, um zu vermeiden, dass mein Speichermedium häufiger aus dem 00:13:11.178 --> 00:13:13.167 Schlafmodus aufgeweckt wird sozusagen. 00:13:13.678 --> 00:13:17.888 Das sind so mögliche Tunables, aber in der Regel braucht man da nicht wirklich 00:13:17.888 --> 00:13:21.818 groß Hand anlegen. Und das gilt eigentlich grundsätzlich für die meisten Cache-Einstellungen 00:13:21.818 --> 00:13:24.198 sozusagen. Also es sind da sehr sinnvolle Werte gesetzt. 00:13:25.018 --> 00:13:29.149 Nichtsdestotrotz macht es Sinn zu verstehen, was die einzelnen Werte bedeuten. 00:13:29.839 --> 00:13:32.698 Was noch der Zukunft ist, speziell in virtualisierten Umgebungen, 00:13:32.698 --> 00:13:36.188 habe ich ja noch. Und das Thema, das ich sowohl im Gast als auch am Host der 00:13:36.188 --> 00:13:37.522 Settings habe sozusagen. 00:13:37.969 --> 00:13:41.828 Und dort macht es auch Sinn, eben sinnvolle Werte zu verwenden, 00:13:41.828 --> 00:13:43.960 um nicht Gefahr zu laufen, die Daten zu verlieren. 00:13:44.499 --> 00:13:48.908 Aber sollte ich die Sachen dann nicht anders setzen im Gast als auf dem Host? 00:13:48.908 --> 00:13:52.609 Also ich meine, macht das überhaupt Sinn, wenn ich an beiden Stellen die Caches habe? 00:13:52.940 --> 00:13:56.758 Es geht ja vor allem dann auch darum, sozusagen, nehmen wir jetzt mal so eine 00:13:56.758 --> 00:14:01.385 typische KVM-Umgebung her, da hat man auch die QEM-Mechanismen im Hintergrund, 00:14:01.733 --> 00:14:04.288 da gibt es Cache-Einstellungen, die können etwas verwirrend sein. 00:14:04.288 --> 00:14:07.791 Es gibt da aus historischen Gründen fünf unterschiedliche Einstellungen, 00:14:08.518 --> 00:14:12.498 die aber aktuell nunmehr dann auf drei Tunables dann abzielen, sozusagen. 00:14:12.498 --> 00:14:16.148 Sagen, die sind standardmäßig auch gut eingestellt, aber man sollte da ein bisschen 00:14:16.148 --> 00:14:18.898 einfach schauen, wenn man irgendeine Performance optimieren möchte, 00:14:18.898 --> 00:14:21.408 dass man nicht aus Versehen irgendwas auftritt, was dann vielleicht der Daten 00:14:21.408 --> 00:14:22.403 in Gefahr bringen könnte. 00:14:23.100 --> 00:14:27.538 Das wäre mal QEMO oder eben auch in der Proxmox-Umgebung, was ja auch KVM, 00:14:27.538 --> 00:14:32.578 dann benutzt diese Cache-Einstellung so Right Back, Right Through. 00:14:33.098 --> 00:14:35.788 Genau, das sind die Themen und das ist auch ein Themenbereich, 00:14:35.788 --> 00:14:38.848 der immer wieder für Verwirrung sorgt sozusagen. Deshalb haben wir uns das auch 00:14:38.848 --> 00:14:41.628 im Frühjahr sehr genau angeguckt und auch dokumentiert. 00:14:41.936 --> 00:14:44.708 Das findet man auch dann bei uns im Wiki sozusagen, wenn man danach sucht, 00:14:44.708 --> 00:14:48.998 relativ schnell wichtig ist, auch in Zeiten von AI, wenn man das irgendwie da, 00:14:49.478 --> 00:14:51.195 selber eben im Prompt eingibt. 00:14:51.607 --> 00:14:55.168 Es hat sich doch historisch einiges geändert sozusagen, das heißt einfach darauf 00:14:55.168 --> 00:14:58.148 achten, wenn ich Informationen bekomme, sind die wirklich am aktuellen Stand 00:14:58.148 --> 00:15:02.980 und im Zweifel wirklich auf die QEMO-Dokumentation gehen, wo die neueste Information dokumentiert ist. 00:15:03.732 --> 00:15:07.400 Okay, und was würdest du jetzt einstellen? Wir lassen die Default-Einstellungen bei Boxmux? 00:15:07.973 --> 00:15:10.449 Genau, also wenn ich jetzt ein Boxmux habe, da ist zum Beispiel standardmäßig 00:15:10.449 --> 00:15:15.413 das auf No-Cache aktiv eingestellt und das ist auch ein sinnvoller Wert sozusagen. 00:15:16.379 --> 00:15:21.601 Und ich brauche da eigentlich jetzt nicht wirklich manuell da Hand dran anlegen. 00:15:21.995 --> 00:15:23.879 Und du hattest, glaube ich, auch Tests gemacht 00:15:23.879 --> 00:15:27.296 mit diesen verschiedenen Caching-Einstellungen und dann den Barriers. 00:15:27.719 --> 00:15:31.979 Da gibt es Mechanismen oder Stellen, die man vielleicht nicht miteinander verwenden sollte. 00:15:31.979 --> 00:15:35.219 Ja genau, es ist auch aus historischen Gründen und auch eine lustige Anekdote, 00:15:35.219 --> 00:15:40.219 es gab da oder es gibt nach wie vorhin ein Perl-Skript, das ist 2005 entstanden sozusagen, 00:15:40.779 --> 00:15:43.459 das haben wir auch schon in der Zeit sozusagen vor den Barriers verwendet, 00:15:43.459 --> 00:15:47.409 um zu gucken, okay, wenn ich jetzt ein F-Sync mache auf ein Storage-Medium und 00:15:47.409 --> 00:15:51.059 mir das Storage-Medium sagt, ja, das ist gesynkt, stimmt das wirklich oder stimmt 00:15:51.059 --> 00:15:53.499 das nicht und das zielt darauf ab mit diesem Testszenario. 00:15:53.499 --> 00:15:57.569 Ich habe zwei Maschinen, eine Maschine, die ich testen möchte sozusagen und 00:15:57.569 --> 00:15:59.099 eine zweite, wo ein Dimon läuft. 00:15:59.099 --> 00:16:04.669 Ich starte auf beiden Maschinen sozusagen dieses Skript, beim einen im Server-Modus, 00:16:04.669 --> 00:16:08.619 beim anderen bei der Testmaschine sozusagen werden Daten geschrieben und über 00:16:08.619 --> 00:16:09.879 das Netzwerk teile der anderen mit, 00:16:10.419 --> 00:16:14.151 was eben die lokale Festplatte, das lokale Medium gesagt hat, es wurde geschrieben. 00:16:14.447 --> 00:16:19.239 Ich ziehe dann brutal einen Stecker, starte das dann nach einer halben Minute 00:16:19.239 --> 00:16:21.530 wieder neu und mache einen Verifier und dann sehe ich, okay, 00:16:22.082 --> 00:16:25.929 ich habe dir vorhin gesagt, ich habe die Daten 3, 7, 8 echt geschrieben, sind die wirklich da? 00:16:25.929 --> 00:16:28.939 Okay, sind nicht alle da? Das heißt, mein Storage Medium hat gelogen, 00:16:28.939 --> 00:16:31.838 dann kann ich auf das dann da drauf kommen sozusagen. 00:16:32.395 --> 00:16:36.439 Und ja, das ist ein einfacher Test, um eben sicherzustellen, dass das funktioniert. 00:16:36.439 --> 00:16:39.789 Und man sieht da auch, wie gut die Barriers tatsächlich funktionieren. 00:16:39.789 --> 00:16:44.439 Also wenn ich jetzt ein Next4-Filesystem jetzt mit No-Barrier-Option mounte, 00:16:44.439 --> 00:16:46.487 um halt vermeintlich eine höhere Performance zu bekommen, 00:16:46.998 --> 00:16:50.819 Und ich habe eine normale Festplatte sozusagen, dann habe ich da garantiert 00:16:50.819 --> 00:16:53.409 dann bei diesem Test die Fehlerreports dann anschließend da, 00:16:53.409 --> 00:16:55.635 weil eben sozusagen der Cache verloren geht. 00:16:56.204 --> 00:17:00.189 Wenn ich aber das Ganze mal mit Barriers mounte sozusagen, was der Standardfall 00:17:00.189 --> 00:17:01.830 ist, dann habe ich da auch kein Risiko. 00:17:02.578 --> 00:17:06.984 Da auch einfach halt die Standards haben sich meistens gut etabliert. Es gibt Gründe dafür. 00:17:08.118 --> 00:17:10.994 Also du würdest jetzt nicht empfehlen, die Sachen auszuschalten? 00:17:10.994 --> 00:17:13.824 Ja, also man kann es zum Teil, wenn man sagt, man hat jetzt irgendwie eine temporäre 00:17:13.824 --> 00:17:17.162 Aufgabe oder VMs, die man irgendwie wegschmeißt oder sowas. Also speziell im 00:17:17.580 --> 00:17:22.688 Apoxmox-CoEmo-Umfeld gibt es ja auch die Einstellung sozusagen Unsafe oder Wideback, 00:17:23.054 --> 00:17:25.304 wo eben praktisch gar nichts raussynchronisiert ist. 00:17:25.324 --> 00:17:28.004 Das kann ich jetzt machen, wenn es rein um Testsysteme geht, 00:17:28.004 --> 00:17:31.064 die ich dann wieder wegwerfe oder wenn ich jetzt mehrere VMs installieren möchte, 00:17:31.064 --> 00:17:31.884 das soll schneller gehen. 00:17:32.564 --> 00:17:35.604 Aber da muss ich halt wirklich darauf achten, das anschließend zu ändern, 00:17:35.604 --> 00:17:38.674 weil das tatsächlich beim Stromausfall sonst zum Datenverlust kommt, 00:17:38.674 --> 00:17:42.294 wenn es nicht regelmäßig ausgeschrieben wird, wenn ich ein Sync mache. 00:17:42.294 --> 00:17:44.492 Also Sync soll funktionieren im Produktivbetrieb. 00:17:45.076 --> 00:17:48.664 Und für Tests könnte ich es anders wählen, aber bitte nicht im Produktivbetrieb. 00:17:49.425 --> 00:17:52.364 Würde sich jetzt deine Einschätzung ändern, wenn ich sage, ich habe auf jeden Fall eine USV? 00:17:55.044 --> 00:18:00.143 Nicht unbedingt. Also USV ist auf alle Fälle eine gute Sache und empfehle ich auch auf jeden Fall. 00:18:00.375 --> 00:18:04.644 Nichtsdestotrotz ist die Stromversorgung per se nicht die einzige Gefahrenquelle. 00:18:04.644 --> 00:18:08.914 Ich könnte auch ein Problem am Netzteil haben. Oder wenn ich redundante Netzteile 00:18:08.914 --> 00:18:12.584 habe, gibt es auch eine Power Distribution Unit, wo der Strom der beiden Netzteile 00:18:12.584 --> 00:18:16.210 zusammenläuft. Und überall dort kann es ja theoretisch zu Problemen kommen. 00:18:17.764 --> 00:18:20.104 Mitunter auch praktisch, es kommt nur auf die Anzahl der Systeme an. 00:18:20.104 --> 00:18:23.634 Wenn ich jetzt wirklich eine große Umgebung habe, kann es tatsächlich auch passieren, 00:18:23.634 --> 00:18:26.462 dass ich irgendwo mal einen Fehler hinter der USV habe. 00:18:26.914 --> 00:18:30.884 Und auch dann sollten die Daten konsistent sein. Natürlich in Zeiten von Ceph 00:18:31.204 --> 00:18:34.374 und so weiter hat man ja noch weitere Mechanismen, wo die Daten tatsächlich liegen. 00:18:34.861 --> 00:18:37.201 Nichtsdestotrotz ist ein sauberes Design da sehr sinnvoll. 00:18:38.424 --> 00:18:42.904 Genau, aber jetzt nur einfach mal vom Standardfall, ich habe ein X4 oder ein 00:18:42.904 --> 00:18:46.204 XFS oder was noch immer, dann sollte ich trotzdem da lieber nicht dran rumspielen. 00:18:46.344 --> 00:18:49.194 Ja, also XFS ist ein gutes Beispiel, da kann ich die Barriers seit langem gar 00:18:49.194 --> 00:18:51.544 nicht mehr ausschalten. Also die Einstellung ist schon seit 4, 00:18:51.544 --> 00:18:56.078 können wir 4.19 glaube ich oder sowas draußen. Also da geht es gar nicht mehr zum Deaktivieren. 00:18:56.805 --> 00:19:00.945 Okay, ich kann mich erinnern, früher als wir viel mit Virtualisierung gemacht 00:19:00.945 --> 00:19:03.741 haben, musste man auch immer noch den Disk-Scheduler ändern, 00:19:04.165 --> 00:19:08.185 weil auch das Probleme gemacht hat, aber sowas brauchen wir heutzutage auch alles nicht mehr. 00:19:08.185 --> 00:19:10.865 Ja, genau. Diese Zeiten sind zum Glück auch vorbei. Es hat sich im Blockleer 00:19:10.865 --> 00:19:13.175 eine Menge getan und da ist auch ein Thema, das du ansprichst. 00:19:13.175 --> 00:19:15.702 Das hat die Änderung, die es da gegeben hat sozusagen. Das ist mit dem, 00:19:16.323 --> 00:19:20.055 ja, wann war das? Also so als die NVMe-SSDs da begonnen hatten, 00:19:20.055 --> 00:19:22.038 kam das Ganze da ins Laufen sozusagen. 00:19:22.462 --> 00:19:25.875 Hintergrund ist, früher waren die Skettulareien auf die Festplatten ausgelegt. 00:19:25.875 --> 00:19:30.685 Das heißt, es ging darum, die Datenzugriffe möglichst auf die Funktionsweise 00:19:30.685 --> 00:19:33.345 der Festplatte zu optimieren sozusagen. Ich hatte eine Queue, 00:19:33.345 --> 00:19:36.336 weil ich einen Aktor, also einen Festplattenarm hatte. 00:19:36.957 --> 00:19:40.975 Und zu Beginn hat dann jeder SSD-Hersteller sozusagen dann begonnen, 00:19:40.975 --> 00:19:46.435 eigene Treiber sozusagen zu entwickeln, die für die jeweiligen Karten dann sozusagen 00:19:46.435 --> 00:19:50.295 funktioniert hatten und das ist auch ein gutes Stichwort, das wurde dann auch 00:19:50.295 --> 00:19:51.627 maßgeblich von Christoph Hellwig, 00:19:52.545 --> 00:19:57.315 mit umdesignt sozusagen und seither gibt es sozusagen mit dem Block MQ diesen 00:19:57.315 --> 00:20:01.975 neuen Cueing-Mechanismus sozusagen und ja, 00:20:02.533 --> 00:20:06.795 funktioniert eben insofern, dass man eben pro CPU Core Software Queues hat und 00:20:06.795 --> 00:20:11.094 dann weiter darunter halt pro Device dann nochmal Hardware Dispatch Queues, 00:20:12.138 --> 00:20:14.790 Dort habe ich dann die Möglichkeit zu parallelisieren, sozusagen. 00:20:14.790 --> 00:20:17.590 Also mit einer Festplatte, da habe ich ja nur eine Queue im Endeffekt, 00:20:17.590 --> 00:20:21.580 wo ich die Daten reinschieben kann, sozusagen, wenn es auf die Hardware runtergeht. 00:20:21.580 --> 00:20:26.980 Und bei NVMES, da habe ich ja die Adressierung wie beim Arbeitsspeichel im Endeffekt, 00:20:26.980 --> 00:20:31.442 parallele Kanäle, viel höhere Parallelität. Und das wurde da schon, 00:20:31.709 --> 00:20:34.658 ich glaube, ist schon gut zehn Jahre her halt umgebaut. 00:20:34.983 --> 00:20:38.410 Ja, wie gesagt, ich kann mich nur erinnern, dass wir das früher mal machen mussten. 00:20:38.410 --> 00:20:44.390 Aber dann ist ja auch gut, dass ich eben mit Festplatten und NWMIs oder SSDs 00:20:44.390 --> 00:20:50.486 da einiges getan hat. Und ja, also toll, dass du das auch immer wieder nachpflegst 00:20:50.817 --> 00:20:52.080 in diesem ganzen Diagramm. 00:20:52.720 --> 00:20:55.050 Also wir können es jetzt hier im Podcast nicht so richtig erklären, 00:20:55.050 --> 00:20:57.166 aber ihr könnt euch das auf jeden Fall mal angucken. 00:20:57.439 --> 00:21:00.100 Also das ist schon ganz spannend, dass man dann einfach wirklich von oben nach 00:21:00.100 --> 00:21:03.342 unten sieht, wie die Daten fließen sozusagen. zu sagen. 00:21:04.015 --> 00:21:08.193 Jetzt hatten wir vorhin diese Page-Caches und alles. 00:21:09.020 --> 00:21:13.150 RAM ist ja auch gerade teuer. Ich weiß nicht, was hältst du denn von so Sachen 00:21:13.150 --> 00:21:15.712 wie Z-RAM und Z-Swap? Hast du das schon mal? 00:21:16.234 --> 00:21:20.470 Ja, da bin ich jetzt noch nicht so tief reingekommen. Es gibt einfach so viele 00:21:20.470 --> 00:21:22.390 spannende Themen und irgendwann muss man einen Strich machen. 00:21:22.390 --> 00:21:26.179 Das heißt, das sind Themen, da bin ich jetzt noch nicht so tief reingestoßen sozusagen bislang. 00:21:27.462 --> 00:21:31.580 Genau, weil wäre auch eine Möglichkeit, um Sachen auszulagern und vielleicht 00:21:31.580 --> 00:21:32.621 nochmal schneller zu machen. 00:21:33.376 --> 00:21:38.490 Und ja, Caches bei CPUs gibt es natürlich auch noch. Hat das auch irgendeine 00:21:38.490 --> 00:21:42.171 Auswirkung oder ist es jetzt für dein Diagramm egal? 00:21:42.484 --> 00:21:45.980 Das ist insofern jetzt eher egal, als beim Diagramm geht es rein um den Storage-Stack 00:21:45.980 --> 00:21:49.610 sozusagen, also nicht um die Zugriff-Führung, was ich jetzt innerhalb vom Arbeitsspeicher 00:21:49.610 --> 00:21:53.700 sozusagen oder innerhalb von den Caches in den CPUs habe. Das ist nochmal eine 00:21:53.700 --> 00:21:54.946 Wissenschaft für sich, sage ich mal. 00:21:55.417 --> 00:21:59.600 Und hat jetzt mit dem Storage-Pfad per se jetzt dann nicht mehr direkt so viel 00:21:59.600 --> 00:22:04.900 zu tun sozusagen, weil es dort dann darum geht, sozusagen laufend Daten zu verarbeiten, 00:22:04.900 --> 00:22:07.560 die jetzt vielleicht gar nicht gespeichert werden oder erst später gespeichert werden. 00:22:08.892 --> 00:22:11.453 Sonst müssen wir natürlich bei den aktuellen Preisen gucken, 00:22:11.453 --> 00:22:12.683 dass wir gar nicht so viel speichern. 00:22:14.634 --> 00:22:18.058 Was sagst du dazu? Wie wirkt sich das bei euch aus? 00:22:19.583 --> 00:22:23.993 Werden immer noch genug Festplatten verkauft und Speichermedien allgemein? 00:22:24.003 --> 00:22:27.263 Ja, das ist eine sehr gute Frage und das beschäftigt uns natürlich genauso wie 00:22:27.263 --> 00:22:28.542 jeden anderen auch in der Branche. 00:22:28.919 --> 00:22:32.453 Was uns sehr zugutekommt, ist, dass wir seit Jahren, Jahrzehnten sehr langfristige 00:22:32.453 --> 00:22:34.343 Lieferantenbeziehungen pflegen sozusagen. 00:22:34.343 --> 00:22:36.553 Also man kann sich das so vorstellen, dass man jetzt die Dinge jetzt nicht, 00:22:37.418 --> 00:22:40.263 wenn es um die Lagerhaltung geht, nicht eine Woche vorher einkauft und das ist 00:22:40.263 --> 00:22:43.973 wirklich sehr, sehr langfristig, über viele Monate, Quartale und zum Teil noch 00:22:43.973 --> 00:22:45.585 darüber hinaus sozusagen. 00:22:46.061 --> 00:22:49.893 Und das sichert uns auch dann sozusagen die Möglichkeit, noch weiterhin immer 00:22:49.893 --> 00:22:53.246 verlässlich Ware zu haben. Ist auch nach wie vor der Fall sozusagen. 00:22:53.728 --> 00:22:57.223 Es gab zu Beginn eine große Unsicherheit, wo viele Kunden abgewartet haben, 00:22:57.223 --> 00:23:00.753 weil man nicht einschätzen konnte oder viele Kunden sich schwer getan haben, 00:23:00.753 --> 00:23:02.801 einzuschätzen. Das ist jetzt kurzfristig oder langfristig. 00:23:03.703 --> 00:23:08.483 Und sehr schnell ist dann die Einsicht gekommen, je länger man wartet, 00:23:08.483 --> 00:23:10.400 umso blöder wird es im Endeffekt sozusagen. 00:23:11.138 --> 00:23:14.045 Mir persönlich gefällt die Situation, wo sie jetzt auch nicht, 00:23:14.045 --> 00:23:16.461 sozusagen, ich hoffe auch wieder auf bezahlbare Preise. 00:23:16.996 --> 00:23:20.795 Wir versuchen auch da sehr stark entgegenzuhalten, sozusagen, 00:23:20.795 --> 00:23:23.705 und sehen da aber nach wie vor auch einen guten Bedarf, sozusagen, 00:23:23.705 --> 00:23:26.025 eine gute Nachfrage von Kundenseite. 00:23:26.025 --> 00:23:30.865 Also die Nachfrage und der Bedarf für souveräne IT, die man selber on-premise 00:23:30.865 --> 00:23:33.250 betreibt, die gibt es nach wie vor sozusagen. 00:23:33.750 --> 00:23:36.555 Viele Projekte müssen etwas umgedacht werden. Es ist vor allem, 00:23:36.555 --> 00:23:38.355 was auch interessant ist, viele Optimierungen. 00:23:38.355 --> 00:23:41.655 Das sieht man ja selbst bei Microsoft sozusagen, wo wieder versucht wird, 00:23:41.655 --> 00:23:45.640 das Windows 11 mit weniger RAM, mit 8 GB RAM laufweg zu machen, 00:23:46.076 --> 00:23:48.125 was sicherlich auch nicht schlecht ist, wenn man jetzt. 00:23:49.745 --> 00:23:53.945 Einfach mehr Hardware reinstecken und bezahlen von diesem Paradigmen ein bisschen 00:23:53.945 --> 00:23:56.028 wegkommt und auf Ressourceneffizienz. 00:23:56.481 --> 00:24:00.035 Schaut, ist ja auch aus ökologischer Sicht sinnvoll. Wenngleich das natürlich 00:24:00.035 --> 00:24:03.305 in Zeiten von KI auf anderer Seite wieder rausgepufft wird. 00:24:04.281 --> 00:24:07.565 Das ist auf jeden Fall ein längerfristiges Problem, von dem her auch schön, 00:24:07.565 --> 00:24:10.434 dass es versucht wird, da technische Lösungen wieder zu finden, 00:24:10.863 --> 00:24:12.265 indem man dann vielleicht doch irgendwelche 00:24:12.265 --> 00:24:17.445 Caches noch hinzufügt oder Datendetuplizierung oder sowas macht. 00:24:17.445 --> 00:24:19.285 Ich weiß nicht, ist das auch bei euch ein Thema? Ich glaube, 00:24:19.285 --> 00:24:23.016 für Backups oder sowas werden wir wahrscheinlich Euroserver auch viel benutzt. 00:24:23.491 --> 00:24:26.515 Ja, genau. Das kommt dann auf das Kundenszenario und auch welche Softwarelösungen 00:24:26.515 --> 00:24:27.526 dann zum Einsatz kommen. 00:24:27.792 --> 00:24:31.485 Aber generell ist das Thema der Effizienz bei uns auf allen Ebenen sehr wichtig. 00:24:31.485 --> 00:24:35.155 Also wir haben jetzt beispielsweise auch nicht nur direkt im Serverbereich Konten, 00:24:35.155 --> 00:24:37.855 sondern wir haben auch viele mit speziellen Systemen. Wir haben da eine eigene 00:24:37.855 --> 00:24:43.553 Systems Engineering Abteilung sozusagen, zum Teil auch halt so embedded nahe Systeme sozusagen. 00:24:44.000 --> 00:24:47.165 Und dort treten auch immer wieder ein paar Dinge auf. 00:24:47.165 --> 00:24:50.315 Also was mich vor ein paar Jahren überrascht hat, da hat ja nicht damit gerechnet, 00:24:50.315 --> 00:24:56.445 da hat ein Kunde angemerkt, dass eine 1.2 SATA-SSD wohl kaputt sei sozusagen. 00:24:56.445 --> 00:25:00.925 Ich habe mir das dann näher angeguckt. Das war auf ein Elkhart-Lake-System sozusagen, 00:25:00.925 --> 00:25:05.313 also eine CPU-Architektur von Intel, die eigentlich für den Bällebereich gedacht ist sozusagen. 00:25:06.090 --> 00:25:10.980 Und dann habe ich gesehen, dass die Temperatur des Controllers der SSD relativ 00:25:10.980 --> 00:25:13.276 hoch war. Das war im EIDL-Betrieb etwas ungewöhnlich. 00:25:13.903 --> 00:25:17.980 Und dann hat sich tatsächlich danach herausgestellt, dass eine Standardfunktion, 00:25:17.980 --> 00:25:22.550 das sogenannte SATA-Link-Power-Management, das im EIDL-Fall den SATA-Link einfach 00:25:22.550 --> 00:25:25.530 abschalten soll, nicht aktiviert war sozusagen. 00:25:25.530 --> 00:25:30.240 Und das hindert aber dann daran zum einen mal, dass der Controller der SSD in 00:25:30.240 --> 00:25:34.950 den Stromsparmodus gehen kann und hindert auch das CPU-Teil daran, 00:25:34.950 --> 00:25:39.888 in tiefere C-States zu gehen, weil noch der SATA-Controller aktiv ist. 00:25:40.393 --> 00:25:44.350 Und es war dann auch die Möglichkeit. 00:25:45.350 --> 00:25:48.640 Mein erster Kernel-Patch, es waren nicht besonders viele, es war dann eine oder 00:25:48.640 --> 00:25:50.910 zwei Zeile, ich habe dann mal reingeguckt und damals war es noch so, 00:25:50.910 --> 00:25:54.830 dass das einfach nach der ID vom PCI-Controller ging und ich habe dann gesehen, 00:25:54.830 --> 00:25:58.310 okay, die ID von diesem Embedded-System, die fehlt hier irgendwie, 00:25:58.310 --> 00:25:59.416 ich habe es mir mal reingegeben und, 00:25:59.880 --> 00:26:02.250 auf einmal hat es auf magische Art und Weise funktioniert. 00:26:02.250 --> 00:26:06.890 Im ID-Betrieb war der SSD-Controller um 30 Grad kühler auf einmal und das Problem war weg. 00:26:07.190 --> 00:26:10.770 Und es ist auch ganz interessant und zeigt, wie einfach es auch ist, 00:26:10.770 --> 00:26:14.773 dass man sich wirklich auch aktiv da beteiligen kann, weil ich kann bislang 00:26:14.947 --> 00:26:17.520 leider kaum C-Programmieren. Also ich habe mir das ein bisschen angeguckt, 00:26:17.520 --> 00:26:19.435 aber ich bin jetzt kein C-Programmierer per se. 00:26:19.992 --> 00:26:24.010 Aber solche kleinen Dingen wie ID ergänzend, das geht und auch mit den Kernel-Entwicklern 00:26:24.010 --> 00:26:27.690 reden, das geht und das sind da auch wirklich sehr zuvorkommen und nett sozusagen. 00:26:28.674 --> 00:26:31.100 Fragen, vielleicht auch aus Hintergrund, warum ist diese Funktion eigentlich 00:26:31.100 --> 00:26:32.412 standardmäßig und überall aktiv? 00:26:33.590 --> 00:26:37.040 Dieser Stromsparmechanismus, der ist im Embedded-Bereich, im mobilen Bereich 00:26:37.040 --> 00:26:41.530 und so sinnvoll, aber im Serverumfeld, wenn ich einen Hot Plug machen möchte, ist er da hinderlich. 00:26:41.530 --> 00:26:46.085 Das heißt, wenn ich den Stromsparmechanismus des SataLink Power Management beim 00:26:46.253 --> 00:26:49.591 Server deaktiviere, der Hot Plug hat, dann geht Hot Plug nicht mehr sozusagen. 00:26:50.310 --> 00:26:53.550 Das heißt, es gibt Szenarien, da macht das eine Sinn, Szenarien macht das andere 00:26:53.550 --> 00:26:56.960 Sinn und lustig wird es dann, wenn ich es wie bei AMD habe, dass das gleiche 00:26:56.970 --> 00:27:00.710 Chip-Blett sowohl für einen mobilen Rechner als auch für einen Server zum Einsatz 00:27:00.710 --> 00:27:02.751 kommt, dann kann ich überlegen, okay, soll ich die ID jetzt, 00:27:04.348 --> 00:27:06.538 in die eine Kiste oder in die andere Kiste reinstecken sozusagen. 00:27:06.538 --> 00:27:10.108 Und das hat dann auch den Niklas Kassler von Western Digital bewegt, 00:27:10.108 --> 00:27:13.978 sozusagen das Ganze halt umzuimplementieren im Kernel, sozusagen eine Erkennung 00:27:13.978 --> 00:27:15.822 zu machen, ist das ein Plug-System, ja oder nein. 00:27:16.368 --> 00:27:19.601 Und er hat dann da sozusagen den Mechanismus im Kernel geändert, 00:27:20.692 --> 00:27:23.868 ist durch eine Diskussion halt da entstanden mit ihm. Also da sieht man, 00:27:23.868 --> 00:27:25.659 wie leicht man sich einbringen kann. 00:27:25.949 --> 00:27:28.188 Hat den Nachteil gehabt, dass mein Kernel-Patch dann rausgeflogen ist, 00:27:28.188 --> 00:27:29.368 sozusagen weil es besser implementiert 00:27:29.368 --> 00:27:32.844 hat, aber nicht desto trotz in der History sieht man es ja noch. 00:27:33.311 --> 00:27:36.478 Genau, und ansonsten sind natürlich solche Konferenzen wie hier auch immer die 00:27:36.478 --> 00:27:42.998 Möglichkeit mit Kördel-Entwicklern oder auch mit vielen Programmierern zusammenzukommen 00:27:42.998 --> 00:27:45.178 und mal kurz die Köpfe zusammenzustecken. 00:27:45.178 --> 00:27:49.148 Ja, das kann ich absolut empfehlen. Also unbedingt auf solche Konferenzen gehen. 00:27:49.548 --> 00:27:52.413 Die Leute machen nur Vorträge und man kann die Leute auch nach dem Vortrag ansprechen. 00:27:52.866 --> 00:27:55.955 Die sind immer so offen und entgegenkommen. Da ist meine Erfahrung. 00:27:56.385 --> 00:27:59.648 Und ja, es macht auch Spaß. Und es sieht auch, wie toll die Open-Source-Community 00:27:59.648 --> 00:28:03.258 funktioniert. Ich stehe jetzt nicht da, wenn ich ein Problem habe und kann das 00:28:03.258 --> 00:28:05.998 gar nicht lösen, sondern man kann tatsächlich mit den Leuten reden, 00:28:05.998 --> 00:28:09.307 das nachvollziehen und das ist eine der schönen Seiten von Open Source. 00:28:10.317 --> 00:28:13.353 Du bist auch bald wieder auf einer Konferenz in Bozen. 00:28:13.673 --> 00:28:13.992 Ja, genau. 00:28:14.132 --> 00:28:14.654 Kann man dich sehen? 00:28:14.921 --> 00:28:18.562 Genau, das ist die SFS-Con. Die ist Mitte November, 13., 14. 00:28:18.562 --> 00:28:21.480 November in Bozen. Die South Tirol Free Software Conference. 00:28:22.072 --> 00:28:24.692 Hat ja auch jetzt immer wieder mehr Besuche. Ich war persönlich bislang noch 00:28:24.692 --> 00:28:27.152 nie dort, aber jetzt gelingt es mir. 00:28:27.632 --> 00:28:28.591 Auch mit dem Vortrag? 00:28:28.806 --> 00:28:32.212 Auch mit dem Vortrag. Da geht es um das Thema Linux an die Schulen bringen. 00:28:32.212 --> 00:28:35.832 Also auch ein Thema, das mir jetzt in meiner Arbeit absetzt von Thomas Grenz 00:28:35.832 --> 00:28:39.026 sozusagen auch sehr am Herzen liegt. Beziehungsweise es überschneidet sich ein bisschen. 00:28:39.508 --> 00:28:42.942 Es geht dort mit dem Linux Professional Institute einher, sozusagen, 00:28:42.942 --> 00:28:48.702 also den seit 1999 bestehenden Non-Profit, die eben sozusagen die ersten und 00:28:48.702 --> 00:28:53.353 die längst dienenden sind, die Linux-Zertifizierungen anbieten. 00:28:53.463 --> 00:28:54.812 Genau, APIC, genau. 00:28:54.812 --> 00:28:56.992 Genau, genau. Und das haben wir auch bei Thomas Krenn schon seit vielen, 00:28:56.992 --> 00:28:59.912 vielen Jahren, haben auch intern immer wieder die Kurse, sind schon langjährige 00:28:59.912 --> 00:29:03.892 Partner und das möchte ich da jetzt auch an die Schulen vermehrt tragen. 00:29:03.892 --> 00:29:07.492 Und wir werden dann vom LPI auch dort bei der Konferenz dann ähnlich wie in 00:29:07.492 --> 00:29:11.182 Chemnitz oder Graz oder auf der Frost kann dort auch wieder die Möglichkeit 00:29:11.182 --> 00:29:13.647 für Prüfungen anbieten sozusagen. Ja, und ich freue mich schon drauf. 00:29:14.193 --> 00:29:17.322 Wenn man sich bei sowas engagieren will, also wenn ich jetzt auch sage, 00:29:17.322 --> 00:29:21.901 keine Ahnung, ich habe Kinder in der Schule und die machen doch da irgendwie gar kein Linux. 00:29:23.212 --> 00:29:24.932 Wie bist du da rangegangen? 00:29:25.292 --> 00:29:29.252 Ja, das war auch ähnlich bei mir oder bei uns sozusagen. Also meine Überlegung 00:29:29.252 --> 00:29:31.732 ist, man kann von heute auf morgen jetzt schwer was übers Knie brechen und die 00:29:31.732 --> 00:29:35.568 Lehrer, die haben auch oftmals wirklich sehr, sehr viel zu tun und leisten da tolle Arbeit. 00:29:36.119 --> 00:29:40.382 Und es gibt aber in vielen Schulen oftmals auch Lehrer, die schon mit Linux 00:29:40.382 --> 00:29:42.313 zu tun haben sozusagen, die da sehr offen sind. 00:29:42.749 --> 00:29:45.072 Und was meine Erfahrung ist, eben, wenn man jetzt nicht sagt, 00:29:45.072 --> 00:29:48.272 na, ihr müsst jetzt die IT dort umstellen oder so, weil das ist jetzt nichts, 00:29:48.272 --> 00:29:50.195 was man von heute auf morgen machen kann. Es gibt auch... 00:29:50.979 --> 00:29:55.310 Je nach Land, Region, Bundesland, ja unterschiedliche Vorgaben, die zu erfüllen sind. 00:29:55.675 --> 00:30:00.040 Aber was sehr niederschwellig geht, wenn es zum Beispiel jetzt eine technikaffine 00:30:00.040 --> 00:30:02.345 Schule ist und irgendwas mit Betriebssystemen gemacht wird, 00:30:02.930 --> 00:30:06.260 dass man dort sozusagen der Linux verstärkt mit einbringt und auch die Möglichkeit 00:30:06.260 --> 00:30:10.310 bietet, beispielsweise diese Linux Essentials oder auch was ganz Interessantes, 00:30:10.310 --> 00:30:12.460 die Security Essentials da ins Spiel zu bringen. 00:30:12.460 --> 00:30:16.311 Das sind zwei wirklich Grundlagenzertifizierungen, wo man nur eine Prüfung machen braucht. 00:30:16.903 --> 00:30:19.370 Und da haben dann die Schülerinnen und Schüler auch den Vorteil, 00:30:19.370 --> 00:30:23.428 wenn sie später ins Arbeitsleben übergehen, dass sie auch ein Zertifikat zum Herzeigen haben. 00:30:23.811 --> 00:30:27.430 Also ein Beispiel bei uns, bei der Thomas Gren, wir haben aktuell knapp 30 Kolleginnen 00:30:27.430 --> 00:30:30.365 und Kollegen im Internet Linux Essentials Grundlagenkurs sozusagen, 00:30:30.905 --> 00:30:32.910 wo wir jetzt neue Kollegen aufnehmen und die haben das schon, 00:30:33.310 --> 00:30:35.456 ist das natürlich für alle Seiten ein Vorteil sozusagen. 00:30:36.228 --> 00:30:39.738 Bringen meinen Azubis auch immer mit als erstes so die Grundlage Linux bei, 00:30:39.738 --> 00:30:42.596 sodass man diesen Kurs dann quasi bestehen könnte. 00:30:43.066 --> 00:30:45.058 Also das ist Ja. 00:30:45.058 --> 00:30:47.818 Was ich auch noch erwähnen kann, es gibt auch die Lernunterlagen vom LPI unter 00:30:47.818 --> 00:30:51.524 learning.lpi.org, die gibt es kostenlos zum Runterladen sozusagen, 00:30:51.890 --> 00:30:54.778 sind wirklich sehr empfehlenswert und neben dieser Linux Geschichte auch die 00:30:54.778 --> 00:30:56.678 Security Essentials die ist, 00:30:57.213 --> 00:30:59.368 ja man kann sagen auch wirklich betriebst du dem Unabhängig, 00:30:59.368 --> 00:31:02.898 da geht es um Grundlagen von Verschlüsselung, was ist für Privatsphäre wichtig, 00:31:02.898 --> 00:31:06.308 also auch Dinge, die eigentlich für jedes Unternehmen relevant sind, 00:31:06.308 --> 00:31:08.538 weil mit den Vorgaben von CAA, NIST 2 etc., 00:31:09.548 --> 00:31:12.248 die Unternehmen müssen, die Mitarbeiter und Mitarbeiterinnen schulen und da 00:31:12.248 --> 00:31:15.927 kann man sich sehr viel rausholen und die Unterlagen sind auch kostenlos verfügbar. 00:31:16.246 --> 00:31:19.618 Ich glaube, das wäre nochmal ein Thema für sich, was wir uns dann vielleicht 00:31:19.618 --> 00:31:23.308 nächstes Jahr nochmal vornehmen mit deinen Erfahrungen, die du gemacht hast. 00:31:23.308 --> 00:31:24.642 Das ist, glaube ich, nochmal ganz spannend. 00:31:25.153 --> 00:31:28.268 Ja, wir können vielleicht nochmal auf das Thomas-Krenn-Wiki hinweisen, 00:31:28.268 --> 00:31:32.998 was auch ein wunderbarer Schatz an Informationen ist. 00:31:33.558 --> 00:31:36.118 Wahrscheinlich der ein oder andere, der mal irgendwas zu Linux gesucht hat, 00:31:36.118 --> 00:31:41.358 ist schon mal draufgestoßen. Geht ja auch so ein bisschen mit auf deine Initiative zurück, oder? 00:31:41.778 --> 00:31:44.808 Ja, genau. Das ist auch lustigerweise auch so, es war nicht geplant, 00:31:44.808 --> 00:31:46.718 es ist mehr oder weniger entstanden. Ist auch heute schon bald, 00:31:46.718 --> 00:31:50.198 glaube ich, jetzt werden es bald 20 Jahre, nein, zwei Jahre, ich weiß nicht genau. 00:31:51.138 --> 00:31:54.098 Mittlerweile so gut 2000 Artikel drinnen. Das ist insofern entstanden, 00:31:54.098 --> 00:31:57.818 als wir begonnen haben, bei Thomas Scann halt da aktiv reinzugehen. 00:31:57.818 --> 00:32:02.388 Wir hatten damals auch eine Lösung mit vorinstallierten Linux-Tools sozusagen 00:32:02.388 --> 00:32:03.192 oder Linux-Programm. und. 00:32:04.637 --> 00:32:09.017 Wir haben natürlich daneben auch Windows und andere Dinge auch mit dem Portfolio, 00:32:09.017 --> 00:32:12.237 aber die Überlegung war, wir hatten immer wieder Fragen bekommen und, 00:32:12.797 --> 00:32:15.642 ein Kollege von mir, der Christoph Mittersch und ich, wir hatten halt dann das, 00:32:16.101 --> 00:32:19.977 zuerst bei uns damals im österreichischen Außenbüro lokal als MediWiki installiert, 00:32:19.977 --> 00:32:22.887 um eben dann bei Copy und Paste eine E-Mail des Kunden zu schicken. 00:32:22.887 --> 00:32:27.717 Und dann haben wir dann unseren Vorständen, Gründern dann vorgeschlagen, 00:32:27.717 --> 00:32:30.737 den Max Thomas und den Christoph, wir könnten das einfach ins Internet stellen. 00:32:30.737 --> 00:32:36.187 Dann können die Leute sofort lesen sozusagen und es ist jedem geholfen. 00:32:36.187 --> 00:32:39.267 Wir haben uns bewusst natürlich auch Marktbegleiternis geholfen, 00:32:39.267 --> 00:32:40.407 aber das ist ja auch da gut so. 00:32:40.407 --> 00:32:44.877 Also wenn wer profitiert, ist es uns ja egal, an welcher Stelle das ist. 00:32:44.877 --> 00:32:48.377 Und da auch nochmal ein Dankeschön, das Vertrauen. Der Christoph ist ja noch 00:32:48.377 --> 00:32:51.791 mit an Bord, der Christoph Mayer sozusagen, der hat das von Beginn auch unterstützt. 00:32:52.355 --> 00:32:56.287 Und auch wenn jetzt in Zeiten von KID die Zugriffe natürlich etwas rückläufig 00:32:56.287 --> 00:32:59.785 sind. Wir waren da zum Teil bei 400.000 bis 500.000 Zugriffen im Monat tatsächlich. 00:33:01.027 --> 00:33:04.917 Nichtsdestotrotz führen wir das weiter. Das heißt, weil für uns dokumentieren 00:33:04.917 --> 00:33:10.277 wir es ohne dies, die Dinge und gerade solche Sachen, auch wie das Linux-Deutsch-Deck-Diagramm 00:33:10.317 --> 00:33:13.997 und auch einen guten Platz und werden auch weiter da verfügbar sein. 00:33:14.809 --> 00:33:18.237 Wichtig ist uns da auch, die URLs, die bleiben bestehen. Jeder Artikel, 00:33:18.237 --> 00:33:23.307 den es gibt, die URL das immer gleich sozusagen, also dass man das ja auch immer 00:33:23.307 --> 00:33:26.111 wieder findet und macht nach wie vor auch viel Spaß. 00:33:26.689 --> 00:33:32.067 Vielen Dank, Werner, also für diese ganzen Initiativen, das Wiki und dieses 00:33:32.067 --> 00:33:38.077 Storage, das Storage-Geogramm, schön, dass du da so drin bist und Leuten erklärst, 00:33:38.825 --> 00:33:44.340 wie Linux Storage funktioniert und eben diesen Wissenschafts ja mit angefangen hast. Vielen Dank. 00:33:44.595 --> 00:33:47.807 Ich sage danke, Ingo, auch danke für Radio Tux, auch für deine langjährige Initiative, 00:33:47.807 --> 00:33:51.667 du bist ja auch schon schon viel länger als ich da im Linux-Bereich auch fast 00:33:51.667 --> 00:33:54.493 aktiv, kann man sagen. Also danke auch dazu und danke für das Gespräch.