Multitasking- / Dateioperationen-Bug

[curt123]

Hallo,

bei verschiedenen Auffälligkeiten im Umgang mit Linux habe ich zunächst einen deutlichen Zusamenhang mit einem vorstellbaren Hardwareproblem nicht ausschliessen können.
Zudem habe ich Dateioperationen, die durch große Datenmenge, kleine Dateigrößen usw., und auch verschiedene Dateisysteme oder Gemeinheiten wie unter Linux nicht erlaubte Dateibezeichner. Und natürlich die Schwierigkeiten der Ursachenzurodnung, wenn ein Kopiervorgang nach 10 Stunden unverändert ist, oder wenn gar die USB-Verbindung oder der eingehängte Zustand nicht mehr besteht.

Nun habe ich aber zwei Rechner, bei denen ähnliche Fehler auftreten. Deshalb gehe ich davon aus, dass es offenbar doch Linux-Probleme sein dürften, inzwischen habe ich den Eindruck, dass bei zahlreichen beobachteten Fehlern ein grundlegendes Problem von Linux/Xfce/Thunar bestehen dürfte. Auf hardwareseite sind zwei verschiedene PCs mit ähnlicher Intel (Atom-Nachfolger) Architektur beteiligt. OS ist aktuelles Debian. Die kritischen Vorgänge gehen mit Bearbeitung, Kopieren großen Datenvolumens und auch CPU-Auslastung einher.

Dabei kommt es zum dauerhaften Blockieren etwa bei Thunar (oder durch Thunar deutlich werdend). Schlimmstenfalls noch zu unbemerkten Dateifehlern, ansonsten beim nächsten Rechnerstart der Hinweis, fsck einzusetzen. Typisch auch der nötige refresh bei Thunar, alternativ schonmal relativ lange Wartezeiten bis zu einer Minute.

Der Zustand ist nach 10 Stunden unverändert, die kopierte Datenmenge auch:


Das Ganze scheint mir nur so erklärbar, dass bei Linux/Xfce/Thunar nötige Abfragen, ob etwa ein Objekt exsitiert, eher durch etwas wie fehlerhafte Timeouts ersetzt sein könnten. Und dass weiterhin dann, wenn das Problem aufgetreten ist, z.B. Thunar oder eine dahinterliegende Schicht entweder die Situation nicht auflösen, oder die nötige Fehlermeldung (mit nötiger Antwort) gar nicht mehr ausliefern kann, also m.E. wohl ein Programmierfehler.

Wahrscheinlich gibt es unter Linux zwei Varianten, diese Fehleranfälligkeit einfach zu umgehen: Brute Force per deutlich leistungsfähigerer Hardware, oder am PC auf jegliches Multitasking zu verzichten und nach jedem Arbeitsschritt schon präventiv erstmal Tee trinken. Diese beiden Varianten möchte ich eigentlich vermeiden

Mich interessiert aber z.B., welche Rolle Xfce/Thunar spielen kann.
Ausserdem frage ich mich, ob z.B. die (Atomnachfolger, z.B. J4205, Apollo-Lake ) Intelarchitektur anfällig oder per se für Linux ungeeignet sein könnte.

LG

[Livingston]

Das Stichwort könnte "übergroße Datenmengen" lauten. Es muss noch nicht mal Thunar Schuld sein. Auch das Bash-Kommando $cp * <irgendwohin> kann crashen, wenn im aktuellen Verzeichnis bspw. 100000 Dateien herumliegen und das "*" mal eben expandiert wird. Dann sieht sich der Befehl mit 100001 Parametern konfrontiert. Gut denkbar, dass GUI-Tools wie Thunar auch an sowas scheitern. Da hilft nur eine gut durchdachte Strategie. Um bei cp zu bleiben: Eine Verzeichnisebene höher gehen und rekursiv kopieren:

Code: Alles auswählen

$cd ..
$cp -r <von hier> <nach da>

in Thunar entsprechend eine Ebene höher und das Verzeichnis statt Einzeldateien schaufeln.
Auf der Bash-Ebene ist xargs immer sehr hilfreich, um monströse Parametermengen zu bändigen. Speziell fürs Kopieren lässt sich auch rsync gut einspannen.

[curt123]

Das Stichwort könnte "übergroße Datenmengen" lauten. Es muss noch nicht mal Thunar Schuld sein. Auch das Bash-Kommando $cp * <irgendwohin> kann crashen, wenn im aktuellen Verzeichnis bspw. 100000 Dateien herumliegen und das "*" mal eben expandiert wird. Dann sieht sich der Befehl mit 100001 Parametern konfrontiert. Gut denkbar, dass GUI-Tools wie Thunar auch an sowas scheitern.

Die Datenmenge erreiche ich mindestens, aber die Dateien verteilen sich nochmals auf (auch verschachtelt) Unterverzeichnisse, z.B.:

Code: Alles auswählen

$ du -sh www/
17G	www/
$ find www/ | wc -l
151059
$ find www/ -type d | wc -l
13596

[MSfree]

Das Stichwort könnte "übergroße Datenmengen" lauten. Es muss noch nicht mal Thunar Schuld sein. Auch das Bash-Kommando $cp * <irgendwohin> kann crashen, wenn im aktuellen Verzeichnis bspw. 100000 Dateien herumliegen und das "*" mal eben expandiert wird.

Nein, da crasht nichts. Wenn der nötige Speicher für die Argumentenliste nicht ausreicht, wird das Programm mit "zu viele Kommandozeilenparameter" oder "too many arguments" beendet.

Dann sieht sich der Befehl mit 100001 Parametern konfrontiert.

Na und? bei einer durchschnittlichen Länge eines Dateinamens von unter 16 Buchstaben wären das 1.6MB für die Argumentenliste. An solchen Datenmengen scheitert es nicht.

Aber davon abgesehen, es gibt eine maximale Größte für die Länger der Kommandozeile. Abfragen kann man das mit

Code: Alles auswählen

getconf ARG_MAX

Bei mir unter Bullseye liefert das 2097152 (= 2MiB). Dein Beispiel mit 100001 Dateinamen würde da also noch funktionieren. Dieses Limit gilt aber nur auf der Kommandozeile. Thunar nutzt das überhaupt nicht. Wenn dort alle Dateien mit Strg-A markiert werden, dann baut Thunar intern eine Liste der markierten Dateien auf, und die kann so groß werden, wie RAM und Swap vorhanden sind, im Zweifelsfall zig GByte.

Zudem habe ich Dateioperationen, die durch große Datenmenge, kleine Dateigrößen usw., und auch verschiedene Dateisysteme oder Gemeinheiten wie unter Linux nicht erlaubte Dateibezeichner.

Es gibt unter Linux fast keine unerlaubten Dateibezeichner. Jedenfalls kann man wirklich fast jeden Blödsinn in einen Dateinamen einbauen, inklusive "*" und Backspace.

Auch große Dateimengen sind völlig problemlos. Welche Datenmenge kann größer sein als die der Google-Cloud oder der von Amazon Web Services? Und die laufen großteils unter Linux mit Billionen (10^12) von Dateien.

Mir scheint, du suchst verzweifelt nach eine möglichst "wissenschaftlich" klingenden Ausrede.

Und natürlich die Schwierigkeiten der Ursachenzurodnung, wenn ein Kopiervorgang nach 10 Stunden unverändert ist, oder wenn gar die USB-Verbindung oder der eingehängte Zustand nicht mehr besteht.

Das dürfte dein Problem sein.

Auf die Logs deiner Systeme hast du natürlich noch nicht geschaut, oder? Schreib- und Lesefehler werden dort nämlich immer protokolliert. Und wenn da mal das ein oder andere USB-Gerät nach einer Zeit austeigt, steht das dort drin. Das löst zwar das Problem nicht, aber das ist auch ein Hardwareproblem, an dem Linux inklusive aller Benutzeranwendungen keine Schuld angelastet werden kann.

Auch die CPU ist nicht dein Problem. Apollo-Lakes werden von namhaften Herstellern wie Synology oder QNAP (beides Linuxsystem) gerade für Storage-Lösungen wie NAS-Systeme mit 4 bis 8 Platten genutzt, was zu respektablen 112TB Plattenplatz führt, wenn man 8 Platten zu 16TB im RAID5 einsetzt. Wenn die ständig ein Problem wären, gäbe es diese Geräte nicht.

[curt123]

Es gibt unter Linux fast keine unerlaubten Dateibezeichner. Jedenfalls kann man wirklich fast jeden Blödsinn in einen Dateinamen einbauen, inklusive "*" und Backspace.

Kann ich noch nachschauen, es waren welche mit Doppelpunkt, und ist vmtl. ein bekanntes Problem. Gibt aber normalerweise wohl eine Fehlermeldung ohne crash.

Mir scheint, du suchst verzweifelt nach eine möglichst "wissenschaftlich" klingenden Ausrede.

Unfug, ich habe zwei verschiedene PCs mit ähnlichen Auffälliglkeiten unter bestimmten Bedingungen, sowie bei USB diverse verschiedene beteiligte USB-Laufwerke, USB-Hub usw..

Und natürlich die Schwierigkeiten der Ursachenzurodnung, wenn ein Kopiervorgang nach 10 Stunden unverändert ist, oder wenn gar die USB-Verbindung oder der eingehängte Zustand nicht mehr besteht.

Das dürfte dein Problem sein.

Auch, aber nicht nur, und unter einem anderen OS hat sowas mit gleicher Hardware geklappt, bis auf einen (andere Symptome) Fall über eine extrem langsame WLAN-Verbindung der Laufwerke.
Und kann da ein Henne-Ei Problem ausgeschlossen werden, was ist Ursache, was Symptom?

Auf die Logs deiner Systeme hast du natürlich noch nicht geschaut, oder?

Etwas, aber wohl nicht auf die richtigen.

Wo muß ich suchen? Ggf. auch, nachdem ich den Stecker ziehen mußte, was sollte ich suchen, oder muß ich Protokollspeicherung aktivieren?

Ich müßte dann schauen, wie ich das Verhalten reproduzieren kann, oder mit etwas Geduld abwarten.

Vielleicht etwas wie Umbenennen des Zielordners während der Kopiervorgang läuft, wenn es dann nur eine Fehlermeldung gibt, war meine Simulation nicht gut genug.

Auch die CPU ist nicht dein Problem. Apollo-Lakes werden von namhaften Herstellern wie Synology oder QNAP (beides Linuxsystem) gerade für Storage-Lösungen wie NAS-Systeme mit 4 bis 8 Platten genutzt, was zu respektablen 112TB Plattenplatz führt, wenn man 8 Platten zu 16TB im RAID5 einsetzt. Wenn die ständig ein Problem wären, gäbe es diese Geräte nicht.

Es soll auch Menschen geben, die zweimal sechs Richtige im Lotto hatten, also könnten theoretisch sogar auch beide PCs Macken haben, gehe ich aber dennoch nicht von aus (ausser der ähnlichen Architektur).

Ansonsten halte ich dein Argument insofern für eher unzutreffend, als gerade die o.g. Storage-Lösungen eine deutlich andere Belastung und ganz andere HD-Perfomance der eingebauten Laufwerke darstellen/aufweisen, als (universal-dektop-typische) übliche Multitaskingvorgänge, die m.E. immer beteiligt waren, und z.B. die häufigen Symptome des überfälligen refresh bei Thunar.

Wenn Apollo-Lake ok ist, soll es mir recht sein, hab ich schließlich, und soviel Angebot an kleinen sparsamen Boards gibt es ja auch nicht. Bei den folgenden Fragmenten von Fehlermeldungen dürften die eigentlichen Ursachen vmtl. eher nicht beschrieben sein, bestenfalls wohl Symptome oder spätere Folgen, etwa beim USB-Aushängen:


A stop job is running for Session 2 of...
A stop job is running for clean the media mount point
Failed unmounting /media
Syncing Filesystems and ..
.. issuing SIGKILL to PID 3114
Remounting timed ou ...
Failed to remount "/" readonly: device or resource busy
systemd-shutdown[1] : Failed to finalize file systems ignoring

// Nachtrag: