¿Por qué una mount.ntfsoperación nunca finaliza (continua quemando la CPU) si la partición parece estar montada correctamente? ¿Cómo se podría depurar esto?
En Linux Mint 19.3, he tenido un fstab (a continuación) funcionando correctamente durante mucho tiempo. Monta una partición de datos NTFS que comparto con Windows. No he usado Windows por un tiempo y definitivamente no está en hibernación. Al arrancar, monta correctamente la unidad (y vincula ciertas carpetas) y puedo acceder a todos los datos. Parece estar funcionando completamente, como siempre, pero este es el punto en el que no puedo encontrar ninguna otra referencia en línea.
Después de iniciar sesión, después del arranque, el proceso raíz mount.ntfscontinúa grabando/consumiendo el uso de CPU de un núcleo. No puedo entender qué lo está causando (ya que parece que ya se ha montado), pero el proceso proviene de 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
Mirando la ruta, parece estar haciendo escritura y lectura exitosamente... por lo que vale.
% 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
El único error que pude encontrar al montar (en syslog/dmesg) fue simplemente volver a montar root/en el momento del arranque, mucho antes de montar otras unidades: [ 4.155258] EXT4-fs (sda9): re-mounted. Opts: errors=remount-ro
Editar (Mover comentarios con más información aquí arriba):
Si comento los montajes en fstab y reinicio, solo se bloquea después de que el usuario inicia sesión. (Tuve que bajar al shell raíz para volver a habilitar el montaje desde el arranque). umount -avdiría que /mnt/DATA está ocupado y no se puede desmontar. Creo que este problema también es el motivo por el que no puedo suspender, porque 1 proceso (este) se niega a dormir.
umount sugerirá (desde la pestaña completa) /mnt/DATA como montaje para apuntar, pero si elimino el proceso mount.ntfs, también lo elimina como montaje para desmontar. Ahora que miro de cerca, hay un servicio dconf que se ejecuta con una buena cantidad de CPU desde el principio, que no sé por qué/qué está haciendo, que (como se dijo) aumenta si mato la montura a la fuerza. proceso ntfs.
Al intentar forzar el desmontaje sudo umount -f /mnt/DATAtambién se informa que el objetivo está ocupado; esto hace que el mount.ntfsproceso desaparezca, pero dconf-servicecalienta la punta. Su /proc/cmdline es simplemente /usr/lib/dconf/dconf-service; No sé cómo obtener más información sobre lo que realmente está haciendo con respecto a este problema. Este desmontaje (y otras acciones) también provoca que este mensaje aparezca en stderr:fatal: unable to access '/[path to now-broken symlink to drive subfolder]': Transport endpoint is not connected