Warum wird ein mount.ntfsVorgang nie abgeschlossen (und belastet weiterhin die CPU), wenn die Partition scheinbar korrekt gemountet ist? Wie kann man das debuggen?
Unter Linux Mint 19.3 funktioniert eine fstab (unten) seit langem einwandfrei. Sie mountet eine NTFS-Datenpartition, die ich mit Windows teile. Ich habe Windows eine Weile nicht verwendet und es befindet sich definitiv nicht im Ruhezustand. Beim Booten mountet es das Laufwerk korrekt (und bindet bestimmte Ordner ein) und ich kann auf alle Daten zugreifen. Es scheint wie üblich vollständig zu funktionieren, aber das ist der Punkt, an dem ich online keine andere Referenz finden kann.
Nach dem Anmelden und nach dem Booten mount.ntfsverbraucht der Root-Prozess weiterhin die CPU-Leistung eines Kerns. Ich kann nicht herausfinden, woran das liegt (da es anscheinend bereits gemountet ist), aber der Prozess kommt aus der fstab: cat /proc/[id of mount.ntfs process]/cmdline: /sbin/mount.ntfs /dev/sda7 /mnt/DATA -o rw,noatime,locale=en_US.utf8,umask=007,uid=1000,gid=1000.
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda9 during installation
UUID=xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 noatime,errors=remount-ro 0 1
# /boot/efi was on /dev/sda2 during installation
UUID=xxxx-xxxx /boot/efi vfat umask=0077 0 1
# swap was on /dev/sda10 during installation
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none swap sw 0 0
# Data Partition, on /dev/sda7
UUID=xxxxxxxxxxxxxxxxx /mnt/DATA ntfs noatime,defaults,locale=en_US.utf8,umask=007,uid=1000,gid=1000 0 2
# Bind directories correctly
/mnt/DATA/Downloads /home/me/Downloads none bind,x-systemd.requires=/mnt/DATA 0 0
/mnt/DATA/Desktop/LinDesktop /home/me/Desktop none bind,x-systemd.requires=/mnt/DATA 0 0
/mnt/DATA/Documents /home/me/Documents none bind,x-systemd.requires=/mnt/DATA 0 0
/mnt/DATA/Media/Music /home/me/Music none bind,x-systemd.requires=/mnt/DATA 0 0
/mnt/DATA/Media/Pictures /home/me/Pictures auto bind,x-systemd.requires=/mnt/DATA 0 0
/mnt/DATA/Media/Videos /home/me/Videos auto bind,x-systemd.requires=/mnt/DATA 0 0
/mnt/DATA/Workspace /home/me/Workspace auto bind,x-systemd.requires=/mnt/DATA 0 0
Wenn man sich Strace ansieht, scheint es, als ob das Schreiben und Lesen erfolgreich funktioniert ... was auch immer das bedeutet.
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
30.51 1.392332 3 518018 pread64
26.86 1.225702 3 416749 pwrite64
18.16 0.828499 4 232782 1 writev
15.72 0.717149 3 236584 read
7.22 0.329389 86 3846 fsync
0.98 0.044537 3 15188 sendto
0.55 0.025258 2 15188 getpid
------ ----------- ----------- --------- --------- ----------------
100.00 4.562866 1438355 1 total
Der einzige Fehler, den ich beim Mounten (in Syslog/Dmesg) finden konnte, bestand darin, root / beim Booten erneut zu mounten, lange vor dem Mounten anderer Laufwerke: [ 4.155258] EXT4-fs (sda9): re-mounted. Opts: errors=remount-ro
Bearbeiten (Kommentare mit weiteren Informationen hierher verschieben):
Wenn ich die Mounts in fstab auskommentiere und neu starte, bleibt es nur nach der Benutzeranmeldung hängen. (Musste zur Root-Shell wechseln, um das Mounten vom Boot aus wieder zu aktivieren). umount -avwürde bedeuten, dass /mnt/DATA beschäftigt ist und nicht ausgehängt werden konnte. Ich denke, dieses Problem ist auch der Grund, warum ich nicht anhalten kann, weil 1 Prozess (dieser) sich weigert, in den Ruhezustand zu wechseln.
umount schlägt (über die Registerkarte „Vervollständigen“) /mnt/DATA als Zielmount vor, aber wenn ich den mount.ntfs-Prozess beende, wird dieser auch als Mount zum Unmounten entfernt. Wenn ich jetzt genauer hinschaue, sehe ich einen dconf-Dienst, der von Anfang an mit einem guten Stück CPU läuft, von dem ich nicht weiß, warum/was er tut, und der (wie gesagt) hohe Spitzen erreicht, wenn ich den mount.ntfs-Prozess zwangsweise beende.
Beim Versuch, die Bereitstellung zu erzwingen sudo umount -f /mnt/DATA, wird auch die Meldung „Ziel ist beschäftigt“ angezeigt. Dadurch verschwindet der mount.ntfsProzess, aber der dconf-serviceSpike wird heiß. Seine /proc/cmdline ist einfach /usr/lib/dconf/dconf-service; ich weiß nicht, wie ich mehr Informationen darüber bekomme, was es in Bezug auf dieses Problem tatsächlich tut. Diese Bereitstellung (und andere Aktionen) verursachen auch diese Meldung an stderr:fatal: unable to access '/[path to now-broken symlink to drive subfolder]': Transport endpoint is not connected