19.06.2018, 20:19 UTC+2

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

31

10.06.2018, 05:20

Mir ist heute aufgefallen dass man innerhalb PCManFM und Dolphin alles machen darf... Datenträger mounten, kopieren, verschieben.... aber wehe man will mit diesen Programmen unmounten. Von diesen Moment an fängt das Unheil zur Laufzeit an mit den 0-Byte Dateien. Ab da bringen mount/umount Befehle auch nix mehr, so als Rettungsanker. Updates verbessert hierbei auch nichts.
Update lt.
sudo apt update
sudo apt install -t unstable pcmanfm libfm4 libfm-tools libfm-modules libfm-gtk4 libfm-gtk-data libfm-data libfm-extra4

durchgeführt?

32

10.06.2018, 09:43

Mir ist heute aufgefallen dass man innerhalb PCManFM und Dolphin alles machen darf... Datenträger mounten, kopieren, verschieben.... aber wehe man will mit diesen Programmen unmounten. Von diesen Moment an fängt das Unheil zur Laufzeit an mit den 0-Byte Dateien. Ab da bringen mount/umount Befehle auch nix mehr, so als Rettungsanker. Updates verbessert hierbei auch nichts.
Welche Updates wurden gemacht?

33

10.06.2018, 13:37

Genau die von ihnen empfohlenen updates



Können Sie nebenbei auch hier mal kurz ein Auge drauf werfen? - Hab zwar dazu einen Workaround gefunden... aber ja, wäre toll wenn in der nächsten Ausgabe wieder mit mit den Bootparameter funktionieren würde.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Sittich« (10.06.2018, 13:56)


34

10.06.2018, 22:15

Hallo,

Zitat

Gerade getestet mit der neuen KNOPPIX 8.3.......... hat sich nichts geändert!!!

und das Update scheint auch nichts zu bringen, schade.
Habe hier die 8.1 laufen.
Das ist natürlich schon ein Problem, wo man die Ursache finden sollte.
Gerade bei einem Rescue System sollte der File Manager 100% zuverlässig funktionieren.
Es macht ja Hoffnung, dass Sie sich jetzt auch mit dem Thema befassen, Herr Knopper. :)
Also auf jeden Fall schon einmal "Danke"!

MfG

35

12.06.2018, 00:09

Guten Abend,
ich habe das mit 8.1 und jetzt mit 8.2 getestet...
Als einzige funktionierende Abhilfe hat sich bei mir herausgestellt: FAT-Datenträger mit sync-Option neu einhängen (sudo mount -o remount,sync), sodaß der Schreibcache komplett umgangen wird.
Dann geht es zwar zuverlässig, ...aber sowohl allgemein leistungsmäßig als auch insbesondere für Flash-Speicher hat der Schreibcache ja schon einen Sinn.

Getestet mit 128MB- und 16GB-Stick -- selbes Ergebnis.
Kommandozeile, Nautilus oder PCManFM -- spielt keine Rolle.
Aber nur bei FAT -- exFAT oder NTFS gehen problemlos.
Irgendwas ist da komisch -- und schade, weil ich von Knoppix immer sehr begeistert war!
P.S.: Habe mir ein kleines Skript zum Neueinhängen geschrieben...

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash

echo "FAT-Datenträger neu einhängen ohne Schreibpuffer (sync statt async)"

FAT_DATENTRAEGER=$(findmnt --types vfat --noheadings --output TARGET)

if [[ -n $FAT_DATENTRAEGER ]] ; then
   select DATENTRAEGER in $FAT_DATENTRAEGER ; do break ; done
   sudo mount -o remount,sync $(findmnt --noheadings --output SOURCE,TARGET --mountpoint $DATENTRAEGER)
   findmnt --list --output SOURCE,TARGET,OPTIONS --notruncate --mountpoint $DATENTRAEGER ;
else
  echo "Keine eingehängten FAT-Datenträger gefunden." ;
fi

read -p "Zum Fortsetzen <Eingabe> drücken..."

pit234a

Fortgeschrittener

36

12.06.2018, 19:29

auch insbesondere für Flash-Speicher hat der Schreibcache ja schon einen Sinn.


wo ich die Wahl habe, schalte ich externe Medien, vor allem USB-Sticks, immer ohne Cache, also mit direktem sync.
Das hängt natürlich vom Gebrauch ab und bei einer externen Festplatte kann das natürlich vollkommen anders sein, aber meiner Ansicht nach überwiegen die Vorteile bei Sticks. Meist werden da eher kleine Mengen von Daten in einer einzigen Richtung geschrieben oder sogar nur gelesen und fertig. Da ist der Vorteil eines Caches eher gering bis gar nicht vorhanden. Die möglichen Nachteile sind aber schon deutlich, wenn man sich vorstellt, dass die Verbindung zum Datenträger mal verloren geht. besonders bei USB-Sticks ist die Gefahr ja sehr groß, alleine durch mögliche mechanische Einflüsse.
Dein Workaround würde ich also bedenkenlos nehmen.

bei mir rücken aber NTFS-Systeme immer stärker in den Vordergrund als Austausch-Systeme, wegen der 4G Größe und weil ich überhaupt nicht exFat will. Da habe ich dann quasi auch einen Workaround.

37

Gestern, 14:30

Analyse und Workaround

Ein paar technisch versierte Besucher und ich haben auf der Cebit am Knoppix-Stand mit verschiedenen Szenarien experimentiert. Dabei haben sich folgende Erkenntnisse herauskristallisiert:
  1. Das Problem tritt auf (oder kann auftreten), wenn ein USB-Stick mit der "eject" bzw. der "Auswerfen"-Funktion des Dateimanagers entfernt, und anschließend der gleiche Stick wieder eingesteckt und wieder eingebunden wird. Erst beim erneuten Mount passiert irgendwas, das dazu führt, dass Dateien nicht auf dem Stick ankommen. Beim ersten Kopieren hingegen landen die Dateien immer korrekt auf dem Stick (auch wenn in diesem Thread mitunter anderes berichtet wurde), unabhängig von FAT32 oder ext2. NTFS haben wir nicht getestet.
  2. "Schuld" am Effekt nach dem zweiten Mounten scheint das "eject"-Kommando bzw. der entsprechende System-Call zu sein. Es lässt sich in der gleichen Reihenfolge auch in der Shell nachvollziehen: mount - Kopieren - umount (optional) - eject (!): Alle Dateien in Ordnung, aber danach erneutes mount des gleichen Datenträgers -> Problem tritt auf.
  3. Update des eject-Kommandos hilft nicht.
  4. Beim normalen "umount" und Abziehen des Sticks OHNE eject-Aufruf tritt das Problem nicht auf, erst nach (!) eject und erneutem mount.

Die Ursache des Problems konnten wir bislang nicht herausfinden, v.a. warum sich der Kernel nach dem Auswerfen des Sticks, wenn das Dateisystem auch offenbar gar keine Fehler hat, den Stick irgendwie "merkt", und beim erneuten Mounten des gleichen Sticks erst einen Fehler "einbaut". Auch dann, wenn der Stick zwischenzeitlich entfernt und neu eingesteckt wurde. Sehr misteriös. Könnte ein Kernelfehler sein, der müsste aber schon seit etlichen 4.x-Kernel-Releases existieren, und man findet nur wenig hilfreiches über den charakteristischen __mark_inode_dirty Eintrag in "dmesg".

Workaround nach aktuellem Stand der Dinge:
  • Den Stick von Anfang an NIE mit "Auswerfen" entfernen, sondern nur "Dateisystem aushängen" (im Dateimanager rechte Maustaste und entsprechenden Menüpunkt anklicken, siehe Screenshot).
  • Sicherheitshalber mit "sudo apt --purge remove eject" das "eject"-Kommando entfernen, das vom Dateimanager aufgerufen wird. Dadurch ist das "Auswerfen" nicht mehr möglich, umount funktioniert aber.




Weiteres:
  • Wenn ein Stick schon mehrmals durch "eject" entfernt wurde, wird der Speicherplatz der kopierten Dateien belegt, auch wenn diese mit 0 Bytes abgezeigt werden, kann aber wieder durch einen Dateisystem-Check freigegeben werden (fsck.vfat /dev/sdXY).


Wir bleiben dran, leider ist das Phänomen nicht so einfach zu tracen. Kann sein, dass es mit einem neuen Kernelrelease von alleine "verschwindet".

pit234a

Fortgeschrittener

38

Heute, 09:31

auf einem Ubuntu mit Linux 4.13.0-45-generic und mit FAT und NTFS habe ich das nun nicht nachvollziehen können.
pcmanfm lief unter opnbox und ich nutzte die "eject"-Funktion des Browsers mehrmals und kopierte Dateien per drag_n_drop aus einem pcmanfm-Fenster ins nächste und sie landeten immer vollständig im Ziel. Pro Stick absolvierte ich etwa ein halbes Dutzend Versuche.

Quellcode

1
2
3
4
pit@ubuntu-air:~$ uname -a
Linux ubuntu-air 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
pit@ubuntu-air:~$ eject -V
eject Version 2.1.5 von Jeff Tranter (tranter@pobox.com)


aktuelles Knoppix habe ich gerade keines.

39

Heute, 18:27

auf einem Ubuntu mit Linux 4.13.0-45-generic und mit FAT und NTFS habe ich das nun nicht nachvollziehen können.
pcmanfm lief unter opnbox und ich nutzte die "eject"-Funktion des Browsers mehrmals und kopierte Dateien per drag_n_drop aus einem pcmanfm-Fenster ins nächste und sie landeten immer vollständig im Ziel. Pro Stick absolvierte ich etwa ein halbes Dutzend Versuche.

Quellcode

1
2
3
4
pit@ubuntu-air:~$ uname -a
Linux ubuntu-air 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:18:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
pit@ubuntu-air:~$ eject -V
eject Version 2.1.5 von Jeff Tranter (tranter@pobox.com)


aktuelles Knoppix habe ich gerade keines.
4.13 ist aber ein älterer Kernel. Hier: Kernel >= 4.15 (Knoppix 8.1) und 4.16 (Knoppix 8.3). Ich baue gerade eine Version mit Kernel 4.17 zum Testen.

Linux HardwareLinux Computer & PCs | Linux Notebooks & Laptops | Geek Shirts | Geek und Nerd Shirt Shop