最近養動物時 突然發現mount.ntfs 100% CPU usage https://imgur.com/G2NY6Nohttps://imgur.com/G2NY6No



爬文後不太能理解，能否請前輩先進開示，感謝

sudo lsof <path_to_NTFS_mount>

[/color][/size]

sudo lsof /path/to/NTFS

Thanks to the following command (executed when the problem shows up):
Code:
sudo lsof <path_to_NTFS_mount>


As Jaromanda X said in the comments, a few google searches on NTFS Linux performance shows this is not uncommon.

Probably the first step gleaned from several threads on the topic is to use lsof to verify which process is slamming your NTFS partition: we're assuming Transmission but maybe it's something else:

sudo lsof /path/to/NTFS

One thread suggests that disabling updatedb.mlocate from cron was a big help. Another thread suggest small writes to the Linux NTFS FUSE driver are particularly CPU intensive, and that would be exactly what a BitTorrent client would be doing. One option might be to look into increasing cache sizes in Transmission to have less frequent writes.

Additional reading suggests more fragmentation makes the CPU utilization worse, and certainly a larger filesystem with lots of small writes (ie. BitTorrent) is likely to have high fragmentation.

So the short answer to your question of "is this a common occurrence" is: yes, high CPU is a known problem with NTFS drivers doing writes on Linux. There are any number of things you might be able to do to help tune to make it better, but you've got a lot of trial and error testing ahead of you, there doesn't seem to be any consistent "fix all" answer for the performance issues you are seeing.

I easily found that the 100% CPU load is created by the updatedb.mlocate script run by cron once per day to update the locate database (man updatedb for more info).

For some reason, updatedb.mlocate thinks that all directories on the NTFS partition have been changed and performs a full rescan of the partition which creates high CPU load due to the limitation of the free version of the ntfs-3g driver used in Ubuntu (this limitation is well known and described somewhere else).

A possible workaround is to append the path to the NTFS mount point to the PRUNEPATHS variable in /etc/updatedb.conf to exclude this mount point from the process of updating the locate database.

The fact that updatedb.mlocale thinks all directories on an NTFS partition are always new is probably related to the way how inodes are represented by ntfs-3g. It's just a guess -- I haven't looked into details; if someone does and has a solution preventing full rescanning on each run, I would like to hear it here as this would be a more correct solution than excluding the whole mount point from updating.https://imgur.com/G2NY6No

附件:

---

  螢幕快照_2018-06-21_02-40-59.bmp (252.51 KB)


  螢幕快照_2018-06-21_02-38-12.jpg (436.36 KB)

用這個

https://www.paragon-software.com/home/ntfs-linux-professional/

下面有 free version