{"id":41679,"date":"2026-06-15T07:54:00","date_gmt":"2026-06-15T05:54:00","guid":{"rendered":"https:\/\/overcentral.com\/de\/?p=41679"},"modified":"2026-06-15T07:54:00","modified_gmt":"2026-06-15T05:54:00","slug":"linux-71-ntfs-ki-entwicklung-kernel","status":"publish","type":"post","link":"https:\/\/overcentral.com\/de\/linux-71-ntfs-ki-entwicklung-kernel\/","title":{"rendered":"Linux 7.1 bringt NTFS-Revival und KI-getriebene Entwicklungswende"},"content":{"rendered":"

Linux 7.1 ist da \u2013 und die neue Version des Kernels birgt weit mehr als nur die \u00fcblichen Treiber-Updates und Bugfixes. Linus Torvalds<\/a> ver\u00f6ffentlichte die stabile Version am 14. Juni von unterwegs aus, wie er in gewohnt lockerem Ton im Release-Notice vermerkte: \u201eZu Hause ist es erst Sonntagmorgen, aber hier, wo ich gerade bin, ist es bereits Sonntagnachmittag.\u201c Hinter dieser fast schon ikonischen Lakonie verbirgt sich ein Entwicklungszyklus, der so turbulent war wie kaum ein anderer. Denn Linux 7.1 ist nicht nur ein technisches Update \u2013 es ist ein Statement. Es markiert die R\u00fcckkehr<\/a> eines verl\u00e4sslichen NTFS-Treibers, die Folgen des KI-Booms f\u00fcr die Kernel-Entwicklung und den Abschied von Technologien, die \u00fcber 30 Jahre alt sind.<\/p>\n

NTFS-Revival: Der lange Weg zu einem vollwertigen Treiber<\/h2>\n

Das mit Abstand wichtigste Feature in Linux 7.1 ist die vollst\u00e4ndige Neufassung des NTFS-Dateisystemtreibers. Entwickelt wurde sie vom s\u00fcdkoreanischen Kernel-Entwickler Namjae Jeon<\/a>, der zuvor bereits f\u00fcr den exFAT-Treiber und den SMB-Server KSMBD verantwortlich zeichnete. Viereinhalb Jahre Arbeit stecken in der Neuimplementierung, die den alten, rein lesenden NTFS-Treiber derart grundlegend modernisiert, dass Torvalds beim Merging von einer \u201entfs resurrection\u201c \u2013 einer Auferstehung des NTFS \u2013 sprach.<\/p>\n

Die Geschichte der NTFS-Unterst\u00fctzung unter Linux war lange eine von Flickschusterei und Frustration. Der jahrzehntealte, fest im Kernel verankerte Treiber konnte nur lesen. Wer schreiben wollte, musste auf NTFS-3G ausweichen, eine FUSE-Implementierung im Userspace, deren Performance naturgem\u00e4\u00df begrenzt war. Als Paragon Software 2021 mit ntfs3 einen eigenen, lesenden und schreibenden Treiber beisteuerte und dieser in Linux 5.15 einzog, schien eine L\u00f6sung gefunden \u2013 doch die Wartung des Treibers verlief danach schleppend.<\/p>\n

Der neue Treiber in Linux 7.1 setzt nun grundlegend an. Er setzt auf moderne Kernel-Konzepte wie Lazy-Writing, die iomap- und folio-Schnittstellen und kommt ohne das veraltete buffer_head<\/code>codecodecodecodecode-System aus. Der Qualit\u00e4tsnachweis: Im xfs-Testsuite-Durchlauf erreicht der neue Treiber 326 bestandene Tests \u2013 deutlich mehr als die 273 von ntfs3. Er besteht s\u00e4mtliche Tests des Vorg\u00e4ngers und bietet dar\u00fcber hinaus zus\u00e4tzliche Absicherung. Die dazugeh\u00f6rige Userspace-Toolbox namens ntfsprogs-plus mit fsck.ntfs<\/code>codecodecodecodecode und mkfs.ntfs<\/code>codecodecodecodecode wird ebenfalls mitgeliefert.<\/p>\n

F\u00fcr alle, die regelm\u00e4\u00dfig zwischen Windows und Linux wechseln oder NTFS-formatierte USB-Sticks nutzen, bedeutet dieser Schritt: Die \u00c4ra des \u201egeht nicht, weil NTFS\u201c k\u00f6nnte endg\u00fcltig vorbei sein. Dennoch gilt: Der Treiber ist brandneu. Wer produktive Daten auf NTFS-Partitionen liegen hat, sollte vorsichtig sein und die Distributionstests abwarten.<\/p>\n

Die KI-Wende: Wie LLMs den Kernel-Entwicklungsprozess ver\u00e4ndern<\/h2>\n

Mindestens so folgenreich wie der NTFS-Treiber ist das, was nebenbei im Entwicklungsprozess von Linux 7.1 geschah: die Konfrontation des Kernel-Teams mit den Nebenwirkungen k\u00fcnstlicher Intelligenz. In der RC4-Phase warnte Torvalds, dass die Sicherheits-Mailingliste durch eine Flut von KI-generierten Bug-Reports nahezu lahmgelegt worden sei. Das Problem ist simpel: Mehrere Personen lassen dasselbe KI-Tool<\/a> \u00fcber denselben Code laufen, finden dieselben Schwachstellen und melden sie jeweils unabh\u00e4ngig voneinander \u2013 ohne Patch. Die Kernel-Maintainer ertrinken in doppelten und dreifachen Reports, deren Dringlichkeit kaum noch zu priorisieren ist.<\/p>\n

In RC5 zog Torvalds die Konsequenz: \u201eNicht-kritische Patches, insbesondere KI-generierte, werden zur\u00fcckgewiesen.\u201c Die Patch-Menge in dieser Phase war ungew\u00f6hnlich gro\u00df \u2013 Torvalds selbst sprach von \u201eziemlich gro\u00df\u201c. Erst ab RC6 beruhigte sich die Lage wieder, sodass der Zeitplan eingehalten werden konnte. Torvalds schrieb im Release-Notice: \u201eNichts wirklich Be\u00e4ngstigendes\u201c \u2013 ein Satz, der nach diesem Zyklus nach tiefer Erleichterung klingt.<\/p>\n

Doch die KI-Wirkung beschr\u00e4nkte sich nicht auf St\u00f6rungen. Sie l\u00f6ste auch eine der folgenreichsten Aufr\u00e4umaktionen der Kernel-Geschichte aus. Netzwerk-Subsystem-Maintainer Jakub Kicinski l\u00f6schte im Merge Window \u00fcber 138.000 Zeilen Legacy-Code \u2013 das gesamte ISDN-Subsystem, die Amateurfunk-Protokolle AX.25, ATM-Treiber, sowie Ethernet-Adapter aus der PCMCIA- und ISA-\u00c4ra. Diese Technologien waren einst das R\u00fcckgrat der Vernetzung, heute haben sie praktisch keine Nutzer mehr. In seinem Pull-Request schrieb Kicinski: \u201eWenn wir den LLM-pocalypse \u00fcberleben wollen, m\u00fcssen wir entweder einen dedizierten Maintainer f\u00fcr diesen Code finden oder ihn l\u00f6schen.\u201c Seine Begr\u00fcndung ist so pr\u00e4zise wie unangenehm: In einer Zeit, in der LLMs den Quellcode nach Bugs durchforsten, kostet das Halten ungepflegten Legacy-Codes die Maintainer wertvolle Zeit, die f\u00fcr echte Arbeit fehlt. Die L\u00f6schung war kein Akt der Willk\u00fcr, sondern eine rationale Schutzma\u00dfnahme.<\/p>\n

Intel: Abschied von der i486 und Neustart mit FRED<\/h2>\n

Im Bereich Hardware-Unterst\u00fctzung pr\u00e4gen zwei Entwicklungen das Bild \u2013 eine, die nach vorne blickt, und eine, die Schluss macht. Intel FRED (Flexible Return and Event Delivery) wird ab der n\u00e4chsten Mobilprozessor-Generation Panther Lake standardm\u00e4\u00dfig aktiviert sein. FRED modernisiert die Art, wie die CPU Interrupts und Exceptions behandelt, beschleunigt das Interrupt-Handling auf Kernel-Ebene und erh\u00f6ht die Sicherheit.<\/p>\n

Das Ende einer \u00c4ra markiert der parallel eingeleitete Entzug der Unterst\u00fctzung f\u00fcr den Intel i486-Prozessor, der 1989 auf den Markt kam. Ingo Moln\u00e1r entfernte die Kconfig-Optionen CONFIG_M486SX<\/code>codecodecodecodecode, CONFIG_M486<\/code>codecodecodecodecode und CONFIG_MELAN<\/code>codecodecodecodecode. Kernel-Images f\u00fcr die i486 lassen sich nicht mehr bauen. Im n\u00e4chsten Kernel-Zyklus werden die eigentlichen i486-spezifischen Codestellen folgen.<\/p>\n

Auch die Grafikseite profitiert: Die Intel Arc B580 (Battlemage) erh\u00e4lt verbesserte Treiber, die im Vergleich zu Linux 7.0 h\u00f6here Performance bieten. \u00c4ltere AMD-GPUs der GCN-1.0\/1.0-Generation werden vollst\u00e4ndig in den AMDGPU-Treiber-Stacks migriert, was eine Leistungssteigerung von rund 30 Prozent bringen soll.<\/p>\n

io_uring trifft BPF: Ein Quantensprung f\u00fcr I\/O und Sicherheit<\/h2>\n

Ein technisches Highlight, das in seiner Tragweite noch untersch\u00e4tzt werden k\u00f6nnte, ist die Integration von BPF-Programmen in die io_uring-Schnittstelle. W\u00e4hrend Linux 7.0 bereits cBPF-basierte Filter einf\u00fchrte, um io_uring-Operationen mit einem seccomp-\u00e4hnlichen Mechanismus zu erlauben oder zu verbieten, geht 7.1 einen Schritt weiter: Mit struct_ops<\/code>codecodecodecodecode lassen sich BPF-Programme direkt in die Completion-Schleife von io_uring einh\u00e4ngen. Das erm\u00f6glicht es, Ereignisse zu verarbeiten und Folge-Requests auszul\u00f6sen, ohne den Userspace zu verlassen. Entwickler messen in Tests bis zu 50 Prozent<\/a> schnellere Durchl\u00e4ufe. F\u00fcr Container-Umgebungen, in denen Sicherheit und Performance Hand in Hand gehen m\u00fcssen, ist dies ein bedeutender Fortschritt.<\/p>\n

Erg\u00e4nzend dazu wurde der ublk-Userspace-Block-Treiber um das Flag UBLK_F_SHMEM_ZC<\/code>codecodecodecodecode f\u00fcr Zero-Copy-I\/O erweitert, und das Ceph-Dateisystem erh\u00e4lt eine Basis f\u00fcr Subvolume-bezogene I\/O-Metriken.<\/p>\n

Weniger spektakul\u00e4r, aber f\u00fcr viele Nutzer relevant: Btrfs verliert das \u201eexperimental\u201c-Label f\u00fcr den Shutdown-Vorgang, exFAT unterst\u00fctzt fallocate()<\/code>codecodecodecodecode zur Vorab-Reservierung von Speicherplatz, und der CIFS-Client kann nun tempor\u00e4re Dateien \u00fcber O_TMPFILE<\/code>codecodecodecodecode anlegen.<\/p>\n

Ausblick: Der n\u00e4chste Merge Window \u00f6ffnet sich sofort<\/h2>\n

Am Ende des Release-Notices vermerkt Torvalds lakonisch, dass der Merge Window f\u00fcr Linux 7.2 bereits am n\u00e4chsten Tag beginne \u2013 auch wenn mehrere Fl\u00fcge anstehen und er zeitweise offline sein wird. Er spielte kurz mit dem Gedanken, die Ver\u00f6ffentlichung um eine Woche zu verschieben, verwarf ihn aber wieder: \u201eDer Aufwand lohnt nicht.\u201c RC1 wird um den 28. Juni erwartet, die stabile Version von Linux 7.2 dann Mitte bis Ende August.<\/p>\n

Linux 7.1 ist ein Kernel, der Geschichte schreibt \u2013 nicht nur, weil er NTFS endlich vollst\u00e4ndig abbildet, sondern weil er die ersten sichtbaren Narben der KI-Revolution im Kernel-Entwicklungsprozess zeigt und gleichzeitig den Mut hat, sich von jahrzehntealtem Ballast zu trennen. Es ist ein Release, das die Frage \u201eWas f\u00fcgen wir hinzu, was werfen wir weg?\u201c mit klaren, teils schmerzhaften Antworten beantwortet.<\/p>\n","protected":false},"excerpt":{"rendered":"

Linux 7.1 ist da \u2013 und die neue Version des Kernels birgt weit mehr als nur die \u00fcblichen Treiber-Updates und Bugfixes. Linus Torvalds ver\u00f6ffentlichte die stabile Version am 14. Juni von unterwegs aus, wie er in gewohnt lockerem Ton im Release-Notice vermerkte: \u201eZu Hause ist es erst Sonntagmorgen, aber hier, wo ich gerade bin, ist […]<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"","fifu_image_alt":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-41679","post","type-post","status-publish","format-standard","category-artikel"],"_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/41679","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=41679"}],"version-history":[{"count":3,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/41679\/revisions"}],"predecessor-version":[{"id":41683,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/41679\/revisions\/41683"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=41679"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=41679"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=41679"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}