Notiz Kernel 5.14 erreicht EOL: Anwender sollten jetzt auf Linux 5.15 LTS wechseln

0x8100 schrieb:
es geht nicht um anmeldemechanismen, sondern darum, dass bugs im code automatisch mit höchstmöglichen rechten laufen. samba dagegen läuft als user-prozess und kann entsprechend abgeschottet werden.
Da du offensichtlich zu faul bist um dich selbst zu informieren:
KSMBD architecture
==================

The subset of performance related operations belong in kernelspace and
the other subset which belong to operations which are not really related with
performance in userspace. So, DCE/RPC management that has historically resulted
into number of buffer overflow issues and dangerous security bugs and user
account management are implemented in user space as ksmbd.mountd.

File operations that are related with performance (open/read/write/close etc.)
in kernel space (ksmbd). This also allows for easier integration with VFS
interface for all file operations.
 
@greg86

On NUMA systems with different types of memory that differ in performance, in a situation where free space is exhausted, preempted memory pages are transferred from DRAM to slower persistent memory instead of deleting these pages.

Testing has shown that this tactic generally improves performance on similar systems. For NUMA, the ability to allocate memory pages for a process from a selected set of NUMA nodes is also implemented.

Auch Heise+ schrieb vor 2 Tagen:

https://www.heise.de/hintergrund/Li...es-kennenlernen-und-ausprobieren-6271701.html

SMB im Kernel, ein leistungsfähiger NTFS-Treiber, frische NUMA-Features und weitere Neuerungen laden Entwickler, Admins und Power-User zum Experimentieren ein.
 
  • Gefällt mir
Reaktionen: konkretor
Caramon2 schrieb:
Der im Kernel integrierte NTFS-Treiber heißt ntfs3 - und unterstützt leider immer noch kein fstrim: Ich nutze den aufgrund seiner wesentlich höheren Schrribleistung (ntfs-3g limitiert beim schreiben auf ca. 50 MB/s) schon sein Februar (aus dem AUR).
Hm, sicher mit der TRIM-Unterstützung? Es gibt die Mount-Option "discard", die TRIM aktiviert:
https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html
 
wenn ich auf manjaro den 3g deinstalliere, dann werden NTFS HDs nicht mehr erkannt.
sollte dann nich automatisch der neue kerneltreiber verwendet werden?
 
deineMudda schrieb:
Da du offensichtlich zu faul bist um dich selbst zu informieren:
und da du offensichtlich nicht in der lage bist, den verlinkten security-relevanten bug zu verstehen:

KSMBD architecture
==================

The subset of performance related operations belong in kernelspace and
the other subset which belong to operations which are not really related with
performance in userspace. So, DCE/RPC management that has historically resulted
into number of buffer overflow issues and dangerous security bugs and user
account management are implemented in user space as ksmbd.mountd.
File operations that are related with performance (open/read/write/close etc.)
in kernel space (ksmbd).
This also allows for easier integration with VFS
interface for all file operations.

siehe https://git.kernel.org/pub/scm/linu.../?id=707a63e9a9dd55432d47bf40457d4a3413888dcc - das ist im kernel-code. path-traversing mittels ".." ist jetzt nicht gerade neu und sollte bei neuem code - und erst recht bei kernel-code - nicht vorkommen. wirft kein gutes licht auf das ganze vorhaben.
 
  • Gefällt mir
Reaktionen: konkretor
SV3N schrieb:
@greg86

On NUMA systems with different types of memory that differ in performance, in a situation where free space is exhausted, preempted memory pages are transferred from DRAM to slower persistent memory instead of deleting these pages.

Testing has shown that this tactic generally improves performance on similar systems. For NUMA, the ability to allocate memory pages for a process from a selected set of NUMA nodes is also implemented.

Auch Heise+ schrieb vor 2 Tagen:

https://www.heise.de/hintergrund/Li...es-kennenlernen-und-ausprobieren-6271701.html

Alles richtig, Ich habe ja nie behauptet es wurde an der NUMA Unterstützung nichts verändert, aber

Der neue NTFS-Treiber NTFS-3G des deutschen Softwareentwicklungsunternehmen Paragon sowie die Arbeitsspeicherarchitektur Non-Uniform Memory Access (NUMA) sind nur zwei prominente Neuerungen.

NUMA als komplette Neuerung zu bezeichnen ist doch etwas zu viel des guten?
 
greg86 schrieb:
NUMA als komplette Neuerung zu bezeichnen ist doch etwas zu viel des guten?
Sorry, das habe ich nicht richtig formuliert. Ich bessere das nachher aus. Danke für den Hinweis.
 
  • Gefällt mir
Reaktionen: greg86 und konkretor
0x8100 schrieb:
das ist im kernel-code. path-traversing mittels ".." ist jetzt nicht gerade neu und sollte bei neuem code - und erst recht bei kernel-code
Ja genau, auf gar keinen Fall. Das Problem lässt sich unter gar keinen Umständen durch eine Prüfung der Benutzereingabe lösen. Deswegen sollte man auch auf gar keinen Fall Datenbanken benutzen, da kann man ja auch Kommandos einschleusen. Richtige Profis nutzen für solche Aufgaben eine CSV Datei, da kann das alles nicht passieren.
 
du schweifst ab. samba hätte diesen fehler ebenfalls haben können. der wäre aber nicht ausnutzbar gewesen, wenn selinux oder apparmor entsprechend konfiguriert wären. diese möglichkeit gibt es aber mit ksmbd einfach nicht. jeder bug, der im kernel-kontext läuft, ist ungleich gefährlicher als einer im userspace.

vor allem gibt es keine notwendigkeit für den kernel smbd. samba mit iu_uring ist schneller als ksmbd. das gleiche gilt für den kernel nfsd - ganesha als userspace-prozess ist ebenfalls schneller. und vom in-kernel http-server hat linux sich schon lange verabschiedet.
 
chartmix schrieb:
@riloka wieso? Google beim Pixel ganz frisch Kernel 5.10 LTS. Der hat noch lange Support.
Jeder Kernel bringt für andere Geräte ausserhalb der Pixel Reihe Verbesserungen und was da selbst bei neuen Modellen von diesem Jahr unterwegs ist (4.9 anyone?) is nicht gut.
Man will doch die Unterschiede zwischen Google und Mainline Version schrumpfen in der Hoffnung dass man irgendwann sich die Zweigleisigkeit sparen kann.
 
riloka schrieb:
Jeder Kernel bringt für andere Geräte ausserhalb der Pixel Reihe Verbesserungen
Das mag ja sein. Aber warum sollte es für Google Zeit sein? Sie haben eben erst bei den neuen Pixelgeräten einen neuen und für Android recht aktuellen Kernel mit LTS genommen. Da herrscht kein Druck.
Die Unterschiede schrumpfen ja von Version zu Version. Das dauert halt.
Beim Pixel ist jetzt erstmals ein GKI in Betrieb.
 
Google pflegt das Basis Android und vergibt die Zertifizierung für andere Hersteller und bestimmt so die Mindestanforderungen. Wenn jemand die Hersteller zum Upgrade motivieren kann und muss, dann Google.
 
SV3N schrieb:
Sorry, das habe ich nicht richtig formuliert. Ich bessere das nachher aus. Danke für den Hinweis.
@SV3N Steht immer noch missverständlich drin :hammer_alt:
 
Zuletzt bearbeitet:
Und der Abschnitt mit dem NTFS-Treiber ist eigentlich auch noch falsch. NTFS-3G ist der FUSE-basierte Treiber für den Userspace, den es schon "ewig" gibt, nichts mit dem neuen Treiber im Kernel zu tun hat und meines Wissens auch nicht von Paragon stammt (die hatten bisher nur einen kostenpflichtigen NTFS-Treiber für Linux & Mac).
 
Fortatus schrieb:
Hm, sicher mit der TRIM-Unterstützung? Es gibt die Mount-Option "discard", die TRIM aktiviert:
https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html
Die Mount-Option "discard" aktiviert online-discard. Also beim löschen wird der betreffende Bereich sofort getrimmt. fstrim (also offline-discard) funktioniert aber auch damit nicht.

Da Distribution i. d. R. regelmäßig (cronjob, systemd-timer) per fstrim trimmen, funktioniert das bei ntfs3 nicht. - Wenn man sich darauf verlässt, ist man quasi verlassen, da man dann nicht mitbekommt, dass das nicht funktioniert.
 
Caramon2 schrieb:
Also beim löschen wird der betreffende Bereich sofort getrimmt. fstrim (also offline-discard) funktioniert aber auch damit nicht.
Was heißt denn in dem Zusammenhang "sofort getrimmt" ?

Soweit ich weiß bedeutet das TRIM eines Blockes nicht, das dieser sofort gelöscht wird (also ein Löschen der Flashzellen damit die wieder neu beschrieben werden können). Ein TRIM bedeutet viel mehr, das ein Block als 'zu löschen' markiert wird. Wann dieser tatsächlich physisch auch gelöscht wird ist Sache des Controllers (in Form einer GarbageCollection die häufig dann ausgeführt wird, wenn die SSD gerade nix zu tun hat).

Der Sinn des expliziten Löschens besteht darin das wenn Blöcke neu beschrieben werden sollen und festgestellt wird, die Flashzellen sind noch gar nicht "zurückgesetzt" das dann nicht erst umständlich ein Löschen stattfindet bevor neu geschrieben werden kann was dann natürlich Geschwindigkeit kostet.

Ein TRIM bedeutet also nicht, das ein deleteable-Block tatsächlich auch sofort gelöscht wird und sozusagen sofort auch die volle Schreibgeschwindigkeit zur Verfügung steht.

Von "sofort getrimmt" zu sprechen kommt da ein wenig missverständlich rüber.
 
Genau, der Unterschied besteht nur darin, dass bei Discard der Controller direkt beim Löschen von Daten informiert wird, welche Blöcke dadurch frei geworden sind, wohingehen fstrim einmal den kompletten Datenträger zu scannen und gesammelt alle Blöcke an den Controller meldet, in denen effektiv keine Daten mehr liegen.
 
andy_m4 schrieb:
Was heißt denn in dem Zusammenhang "sofort getrimmt" ?
Zu Online-/Offline-Dicard gibt es genügend Dokumentation, wo der Unterschiede erklärt werden.

longusnickus schrieb:
wenn ich auf manjaro den 3g deinstalliere, dann werden NTFS HDs nicht mehr erkannt.
sollte dann nich automatisch der neue kerneltreiber verwendet werden?
ntfs3 muss explizit gemountet werden ("mount -t ntfs3 …" oder "ntfs3" in der fstab. Standardmäßig wird weiterhin mit ntfs-3g gemountet. Deshalb funktioniert es ohne ntfs3 nicht. - Das soll irgendwann geändert werden, habe ich gelesen.

Wie ntfs3 jetzt schon automatisch gemountet werden kann, wird hier beschrieben: https://aur.archlinux.org/packages/ntfs3-dkms/

Damit habe ich mich aber noch nicht beschäftigt: Erst mal muss fstrim funktionieren.
 
Zurück
Oben