Почему mount.ntfsоперация никогда не завершится (продолжит сжигать CPU), если раздел, кажется, правильно смонтирован? Как это можно отладить?
На Linux Mint 19.3 у меня fstab (ниже) работает правильно уже долгое время. Он монтирует раздел данных NTFS, который я разделяю с Windows. Я давно не пользовался Windows, и он определенно не находится в спящем режиме. При загрузке он правильно монтирует диск (и привязывает определенные папки), и я могу получить доступ ко всем данным. Он полностью работает, как обычно, но это тот момент, когда я не могу найти никаких других ссылок в сети.
После входа в систему, после загрузки, процесс root mount.ntfsпродолжает сжигать / потреблять ресурсы процессора на уровне ядра. Я не могу понять, что вызывает это (так как, похоже, он уже смонтирован), но процесс действительно происходит из 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
Глядя на strace, кажется, что запись и чтение проходят успешно... если это вообще имеет значение.
% 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
Единственная ошибка, которую я смог найти при монтировании (в syslog/dmesg), заключалась в повторном монтировании root / во время загрузки, задолго до монтирования других дисков: [ 4.155258] EXT4-fs (sda9): re-mounted. Opts: errors=remount-ro
Редактировать (перемещаю комментарии с дополнительной информацией сюда):
Если я закомментирую монтирования в fstab и перезагружу, он зависнет только после входа пользователя в систему. (Пришлось перейти в оболочку root, чтобы снова включить монтирование из загрузки). umount -avбудет говорить, что /mnt/DATA занят и не может быть размонтирован. Я думаю, что эта проблема также является причиной того, что я не могу приостановить, потому что 1 процесс (этот) отказывается спать.
umount предложит (из вкладки complete) /mnt/DATA в качестве монтирования для цели, но если я убью процесс mount.ntfs, то он также удалит его как монтирование для размонтирования. Теперь, когда я присмотрелся, есть dconf-service, который работает с хорошей частью CPU с самого начала, и я не знаю, почему/что он делает, и который (как уже говорилось) резко подскакивает, если я принудительно убью процесс mount.ntfs.
Попытка принудительного размонтирования sudo umount -f /mnt/DATAтакже сообщает, что target занят; это приводит к mount.ntfsисчезновению процесса, но делает dconf-serviceпик горячим. Его /proc/cmdline просто /usr/lib/dconf/dconf-service; Я не знаю, как получить больше информации о том, что он на самом деле делает в отношении этой проблемы. Это размонтирование (и другие действия) также вызывают это сообщение в stderr:fatal: unable to access '/[path to now-broken symlink to drive subfolder]': Transport endpoint is not connected