Por que uma mount.ntfsoperação nunca terminaria (continuaria a queimar CPU) se a partição parece estar montada corretamente? Como isso poderia ser depurado?
No Linux Mint 19.3, tenho um fstab (abaixo) funcionando corretamente há muito tempo. Ele monta uma partição de dados NTFS que compartilho com o Windows. Faz algum tempo que não uso o Windows e definitivamente não está hibernando. Na inicialização, ele monta a unidade corretamente (e vincula determinadas pastas) e posso acessar todos os dados. Parece estar funcionando perfeitamente, como sempre, mas é neste ponto que não consigo encontrar nenhuma outra referência online.
Após o login, após a inicialização, o processo raiz mount.ntfscontinua a queimar/consumir o uso da CPU de um núcleo. Não consigo descobrir o que está causando isso (já que parece já ter sido montado), mas o processo vem do 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
Olhando para o strace, parece estar fazendo gravação e leitura com sucesso... pelo que vale a pena.
% 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
O único erro que encontrei para montagem (em syslog/dmesg) foi apenas remontar o root/no momento da inicialização, muito antes de montar outras unidades: [ 4.155258] EXT4-fs (sda9): re-mounted. Opts: errors=remount-ro
Editar (movendo comentários com mais informações aqui):
Se eu comentar as montagens no fstab e reiniciar, ele só trava após o login do usuário. (Tive que ir para o shell root para reativar a montagem na inicialização). umount -avdiria que /mnt/DATA está ocupado e não pode ser desmontado. Acho que esse problema também é o motivo pelo qual não consigo suspender, porque 1 processo (este) se recusa a dormir.
umount irá sugerir (da guia completa) /mnt/DATA como uma montagem para o destino, mas se eu encerrar o processo mount.ntfs, ele também o removerá como uma montagem para desmontar. Agora que olho de perto, há um serviço dconf que roda com uma boa parte da CPU desde o início, que não sei por que/o que está fazendo, que (como disse) aumenta se eu matar a montagem à força. processo NTFS.
Tentar forçar a desmontagem sudo umount -f /mnt/DATAtambém informa que o alvo está ocupado; isso faz com que o mount.ntfsprocesso desapareça, mas dconf-serviceaquece o pico. Seu /proc/cmdline é apenas /usr/lib/dconf/dconf-service; Não sei como obter mais informações sobre o que realmente está fazendo em relação a esse problema. Esta desmontagem (e outras ações) também faz com que esta mensagem seja stderr:fatal: unable to access '/[path to now-broken symlink to drive subfolder]': Transport endpoint is not connected