mount.ntfsパーティションが正しくマウントされているように見えるのに、なぜ操作が終了しない (CPU を消費し続ける) のでしょうか? これをデバッグするにはどうすればよいでしょうか?
Linux Mint 19.3 では、fstab (下記) が長い間正常に動作していました。これは、Windows と共有している NTFS データ パーティションをマウントします。しばらく Windows を使用していませんが、休止状態になることは絶対にありません。起動時に、ドライブが正しくマウントされ (特定のフォルダーがバインドされ)、すべてのデータにアクセスできます。通常どおり完全に動作しているように見えますが、この点についてはオンラインで他の参照を見つけることができません。
ログイン後、起動後、ルート プロセスはmount.ntfsコア相当の CPU 使用率を消費し続けます。何が原因かはわかりません (すでにマウントされているようです) が、プロセスは 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 内) は、他のドライブをマウントするずっと前に、起動時にルート / を再マウントするだけのことでした:[ 4.155258] EXT4-fs (sda9): re-mounted. Opts: errors=remount-ro
編集 (詳細情報を含むコメントをここに移動):
fstab のマウントをコメント アウトして再起動すると、ユーザーのログイン後にのみハングします (ブートからマウントを再度有効にするには、ルート シェルに切り替える必要があります)。/ umount -avmnt/DATA がビジー状態であり、アンマウントできないと表示されます。この問題は、1 つのプロセス (これ) がスリープを拒否するため、サスペンドできない理由でもあると思います。
umount は (タブ補完から) /mnt/DATA をマウント先として提案しますが、mount.ntfs プロセスを強制終了すると、アンマウントするマウントとしても削除されます。よく見ると、最初から CPU のかなりの部分を消費して実行される dconf サービスがあり、それがなぜ/何をしているのかはわかりませんが、(前述のように) mount.ntfs プロセスを強制終了すると、急上昇します。
強制的にアンマウントしようとするとsudo umount -f /mnt/DATA、ターゲットがビジー状態であると報告されます。これによりプロセス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