起動時にfstabを介してNTFSパーティションをマウントすると、まだうまく機能しますが、プロセスは終了しません。

起動時にfstabを介してNTFSパーティションをマウントすると、まだうまく機能しますが、プロセスは終了しません。

mount.ntfsパーティションが正しくマウントされていると思われる場合は、ジョブが完了しないのはなぜですか(CPUが消耗し続けますか?)これをデバッグする方法は?

Linux Mint 19.3では、私のfstab(下)は長い間正常に実行されました。 Windowsと共有したNTFSデータパーティションをマウントしました。 Windowsを長時間使用していないため、確かに休止状態ではありません。起動時にドライブが正しくマウントされ(特定のフォルダがバインドされている)、すべてのデータにアクセスできます。いつものように完全に動作しているようですが、ここではオンラインで他の参照を見つけることができません。

ログイン後に実行されると、ルートプロセスは引き続きmount.ntfsCPU使用率の1つのコアを消費/消費します。 (すでにマウントされているようなので)原因は何であるかわかりませんが、プロセスは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

追跡を見ると、うまく書いて読んでいるようです...それは価値があります。

% 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 -av/mnt/DATA が使用中のため、アンマウントできないというメッセージが表示されます。この問題は、1つのプロセス(このプロセス)がスリープモードを拒否しているため一時停止できない理由でもあると思います。

umountは(タブで実行)/mnt/DATAをターゲットマウントとして提案しますが、mount.ntfsプロセスを終了するとアンマウントするマウントとしても削除されます。詳しく見ると、最初からCPUを多用するdconfサービスが実行されていますが、なぜ/何をするのかわからず、マウントを強制終了すると(言及どおり)スパイクが発生します。 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

ベストアンサー1

おすすめ記事