Huge CPU usage by mount.ntfs process

[Stevo Vukovic]

While copying files from one ntfs partition to second ntfs partition process 'mount.ntfs' use 42 - 49% procesor resources (probably 100% on one core). Second 'mount.ntfs' process use 5% procesor time. (used 'conky' for inspection)

/ and /home on first sata disk (ext4)
file source on the second sata (ntfs)
file target on third sata hdd (ntfs)

Ubuntu 9.10 Alpha 1 (up-to-date)

Athlon 2xCore
nvidia 570 chipset

ProblemType: Bug
Architecture: i386
Date: Thu Jun 25 19:11:54 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/nautilus
NonfreeKernelModules: nvidia
Package: nautilus 1:2.27.2-0ubuntu1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.30-9.10-generic
SourcePackage: nautilus
Uname: Linux 2.6.30-9-generic i686

[Nandan Vaidya (gotunandan)]

Confirmed Bug by copy 2 GB from ntfs-3g partition to another ntfs-3g partition on local disk

This happens because the mount.ntfs process has to handle the file operation on both disks.
Anytime you copy or paste to an ntfs partition, the mount.ntfs proccess takes up a certain amount of CPU usage.

[Mark (darck1)]

My wife and I are running Jaunty 64bit with all updates. I have a ntfs drive shared via Samba. She is copying a 20GB file to my drive from her local ext3 drive. My CPU usages is spiking up to 100%.

[Chris Coulson (chrisccoulson)]

I have just uploaded a version of ntfs-3g in to my PPA linked against its own internal FUSE. Could you please try installing this package and tell me if you still see the high CPU usage?

My PPA (and instructions for installing packages from it) can be found here: https://edge.launchpad.net/~chrisccoulson/+archive/ppa

*** Disclaimer: This package is completely untested by me, so use with caution ***

[MrMur (murrayie)]

I don't know if this is a different bug, but I'll stick it here.

Copy 3.7gb (DVD iso) to a USB hard disk formatted at FAT32 gives a consistent speed of circa 26Mb/s. Reformat to NTFS and repeat: the speed starts similarly, but dwindles down to 11Mb. It can't be fragmentation as the drive is just been formated. I originally had an issue when moving 8gb to an external HD, which started out at 19Mb/s, but ended up at 2Mb/s before the file copy had finished. Am using 9.10 release. I regularly copied stuff to my NTFS partitions under 9.04 and had no problems.

CPU usage very high on mount.ntfs, 70%+

[Mathieu (tangonuevo)]

I confirm here with 9.10 final. Same problem: 100% cpu load by mount.ntfs

[Huygens (huygens-25)]

Here is another scenario which ends up with the same problem.
Downloading using Transmission a DVD ISO of CentOS and storing the downloaded file to an NTFS drive (either internal or via USB).
After a while, the CPU load is so high that Transmission does not download any more, it just waits (freeze mode-like) for the ntfs-3g to do something (high CPU load) and thus the download is kind of stalled... So, as of now, I have downloaded about half (1.7GB) of the DVD ISO, and when I launch Transmission it is just consuming CPU power (and electricity power) for basically nothing significant.

This is a bit frustrating as I do not have the required space on my Linux partition to be able to download the DVD ISO...

Note: with Jaunty, the CPU usage was also remarkably high, however I had managed to download the DVD ISO of the previous CentOS release.

[miniwill (mathieumesnil)]

All the problems above, i had its too. With transmission, same thing, he freeze after downloading few gb of data. I also try to copy 8gb on my ntfs partition but the download rate decreasing from 10Mo/s to 190Ko/s. So it's not thinkable to wait, i return on windows to make the copy.
I have used ubuntu for several years and I never had this problem before.

I also have an other problem. When I open evince(pdf) the pc freeze and I'm obliged tu press the power button to restart.

I think, i'm going to come back to Jaunty.

BYeBYe

[Prashant (tandonprashant)]

I have the same problem 2....
I have 100% CPU usage on 1 core. % some 10% on other.
Problem happening in transmission & copying.
Both are freezing.
Transmission freezes the downloads. & finally crashes. ..
not even 1 DVD can be downloaded completely.
The processor starts getting heated up-to 70´C. Fan keeps running ...
Bug needs to be fixed at earliest.
:(

[chika.tambun (chika)]

ntfs-3g is great... i had been using it since 3 years ago

but when i played rhythmbox then it begin search audio files on my hardisk[ntfs]
automaticaly then ntfs-3g played the main act as the key player on using
the top cpu usage over 99% a long time[3 days uptime]
OMG how cruel

my collection audio files reache 40gb

is there any idea to solve this problem, it doesn't happen on the same way
when i access audio file from ext3?

gnewsense deltah(the latest one)

[raido357 (raido357)]

Same problem here, Karmic Koala. Just downloading couple off torrents directly to NTFS partition. CPU Usage constantly high 88%.

[nigo045 (nigo045)]

When I copy some big files on my NTFS USB hard disk, 80% of my CPU is used and speed decrease to 9Mb/s instead of 30mb/s.

[nemamradfazole (nemamradfazole)]

Sometimes my hard disk begins to work very hard and my CPU is used with 100 % by mount-ntfs. Even if I don't work with a NTFS partition at all (and I don't have installed Tracker). Usually it happens a short time after boot and takes few minutes.

[nicolas kleinklaus (nknico)]

I have the same proble here.

Also it seems that https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/395892 is a duplicate of this bug.

[Filiprino (filiprino)]

I am experiencing same problem. Downloading a 40GB sized torrent with transmission results in random transmission lock-ups and one core at 90% of usage because of mount.ntfs.

[Traz (traz)]

I'm copying a 8 GB file from an Ext4 partition to an NTFS USB drive and CPU load is 80%. The transfer rate is 7 MB/s.

This is Ubuntu Karmic.

[solarsd (dse-ssd)]

I'm also affected by this bug. When copying from or to a ntfs partition the transfer speed starts normally but then falls down to a halt... Then I get 100% CPU usage, 0.2% mem usage and the interesting part is that using iotop I get only 20 K/s disk write activity in total, all due to mount.ntfs process. That's happening on Ubuntu Karmic, kernel 2.6.31-17-generic using ntfs-3g version 1:2009.4.4-1ubuntu4. I wonder if someone is looking into this as it is a real nasty issue...

[[e-mail] (don-borsto)]

There may be an interrelation between ntfsg and the clock-device.
This problem occures on my notebook (ibm t41p) with the boot-option: clock=pit

[zEn (der-eremit)]

Got the Problem too, when transfering large files to or from the ntfs partition, the system becomes barely useable (Core2 Duo).
I can observe high system load in my Gnome Panel system monitor, but can't confirm high cpu load, ( at least not in htop).

my clock is hpet btw.

Did not occur to me in Jaunty as far as I can remember

[macleapa (jp-maclean)]

I have same problem. Transfer large files 4GB+ sized files. Transfer is from one SATA 10K RPM drive to another SATA 10K RPM drive. Speed starts out fine until about the first 4Gb. Then rate drops steadily. CPU stays at about 100% for one CPU (have a Quad core i7 processor). Running Ubuntu 9.10.

[perryizgr8 (perryizgr8-gmail)]

problem here too with transmission inside wubi downloading an iso to the host ntfs partition. i posted a duplicate here: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/551803
transmission becomes unresponsive after a couple of hours (maybe its a data transferred correlation, not a time one, because my internet is really really slow at 256kbps). cpu usage of one core jumps to 100% and the other is 5-10%. the hard drive and cpu gets extremely hot. since its a laptop, the keyboard gets too hot to touch. i had to handle it wearing gloves (not kidding).

[Gary D. Huffman, II (gdhuffman)]

I'm seeing the same issue as comment #20. It slows to a crawl and eats up one core any time you write a really big (4+ GB) file to a NTFS partition. Tested using Ubuntu 9.10 (32 bit) on a dual core P4.

[Gary D. Huffman, II (gdhuffman)]

Additional testing reveals that writing really large files must simply be more likely to reproduce the problem, but in fact is not a requirement. With a NTFS partition near capacity (around 4 GB remaining), I was able to reproduce the problem by writing a file that is just under a GB to it. When I noticed that it slowed way down several seconds into writing the file, I aborted and freed an additional half a GB more (giving a total of ~4.5 GB free). I was then able to write my file not-so-large file at normal speeds. So it seems this may be due to some odd fragmentation corner case.

[Jordan (jordan-d-carter)]

I am also experiencing this problem. Copying ~6 GB, 5 files to a 8GB ntfs usb stick throws my load WAY up to 6-7. All filesystem actions afterwards lock nautilus for ~20 seconds.

Transfer speed starts at about 48MB/s then ramps down to 700KB/s.

[slavic (slavic-oe)]

Also noticed that ntfs-3g is slow at reading and writing. I used Fedora 12 and Ubuntu 9.04, both have the same problem. i also have rtorrent and conky installed on my Ubuntu 9.04, but if i want to download something, i must leave the computer until it finish downloading. Even pointer freeze , not talking about browsing or working when copying information. rtorrent run at 10mb/s only few seconds, just to fill up the entire cache and then speed goes down to 1.5mb/s or 6mb/s if I don't touch anything.

please team up with other linux distros and solve this annoying bug. All type of operation that imply copying, reading, writing on ntfs partitions are incredible slow and freeze the machine.

Hint... utorrent under wine don't have such a problem, maybe someone will use wine knowledge in writing a good driver for ntfs.

[pacanukeha (c-launchpad-pacanukeha-net)]

ntfs-3g also chokes when running a VM for me in Lucid Lynx. This is a regression since the standard VM tweaks solved the problem in 9.10.

[ak_tone (ak-tonfisch)]

Same problem for me in Lucid! Heavy transfer-speed degression when copying large files from ext4 to ntfs (and also FAT32) partitions. Starts at 27MB/s (Laptop HD) and goes down to 1MB/s with 100% CPU constantly. I know ntfs-3g has poor write performance but the described behaviour looks rather like a bug to me. Even writing to FAT32 gives similar symtoms.

[Pioneer (theloveboss)]

Same problem for me in Lucid!

Heavy transfer-speed digression when copying large files from ext4 to ntfs partitions. Starts at 500kB/s , i really can't find any fix for this problem !!

[c mig (b-launchpadopenid-migliorini-fr)]

Same issue with Lucid Lynx.

Copying 3 huge files (80GB total, sparse files) from an external XFS formatted USB2 hard drive to an NTFS partition took over 1500 minutes *CPU time* to mount.ntfs.

in case it really matters: AMD dual core, 3 GB RAM, SATA2 internal drive.

[Nandan Vaidya (gotunandan)]

Maybe the bug should be marked as "confirmed" rather than "incomplete" , since the high CPU usage can be observed on the newer releases as well ?

[Alcher Black (alcherblack)]

Very, very, VERY annoying bug indeed. Has nobody found any workarounds? (other than not using ntfs entirely, but that's almost impossible for me)

[Brian Harkness (maestro-bwh)]

I went to http://www.tuxera.com/community/ntfs-3g-download/ and grabbed the rc.tgz

I made a debian package with the result, modified the version so that it would not be "upgraded" and installed it. mount.ntfs barely makes a blip in System Monitor (ksysguard) on KDE.

One could do a
./configure
make
sudo make install with the extracted tarball, but I like the packaging of a deb so it can be easily removed. I did have to remove the associated "lib" file that accompanies ntfs-3g on ubuntu.

I didn't attach it because I am not completely familiar with the protocol here.

[zzarko (zzarko-gmail)]

I have the same problem on K/Ubuntu 10.04 (2GB Ram, E6750, ASUS P5B Deluxe). I have 4 SATA hard drives, with system on the first one (ext4) and various data on three others (ntfs). Copying 200GB of files from ie. second to third drive makes system nearly unusable. I tried the 2010.8.8 version of ntfs-3g, I got slightly better performance, but still very high: around 50-60% of CPU usage by monut.ntfs and about 20% by mc during file copying from one drive to another.

[Jean-Pierre (jean-pierre-andre)]

Can anybody try the latest advanced ntfs-3g version with improvements when appending data to big or fragmented files or on a close to full disk ?
See http://www.tuxera.com/community/ntfs-3g-advanced/ (currently ntfs-3g-2010.8.8AB.1 a beta test version).

[Steve Brown (sbrown)]

Problem resolves for me after installing:

https://launchpad.net/~x3lectric/+archive/team-iquik-releases/+packages

which is an unofficial (PPA) build of the upstream ntfs-3g 2010.8.8 release.

[Mikko Korkalo (keitsi)]

I maybe have the same problem on 10.04.1 LTS

When moving files from NTFS partition to other (on different drive), I got a speed of 13747 bytes per second (13 KBps).
I see 50-90% CPU usage on one of the mount.ntfs processes, and uptime says:
 15:46:09 up 2:28, 2 users, load average: 2.07, 2.06, 1.94

I have Pentium 4 HT 3GHz on the machine, so there should be plenty of processing power.

root@ksrv:~# top|grep mount
 1198 root 20 0 5212 1680 340 R 26 0.7 14:56.43 mount.ntfs
 3778 root 20 0 8268 4596 332 R 7 1.9 3:15.28 mount.ntfs
root@ksrv:~# cat /etc/motd
Linux ksrv 2.6.32-24-generic-pae #43-Ubuntu SMP Thu Sep 16 15:30:27 UTC 2010 i686 GNU/Linux
Ubuntu 10.04.1 LTS
root@ksrv:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 1
cpu MHz : 2992.845
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips : 5985.69
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 1
cpu MHz : 2992.845
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips : 5985.41
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
root@ksrv:~# free
             total used free shared buffers cached
Mem: 242068 238416 3652 0 134556 48004
-/+ buffers/cache: 55856 186212
Swap: 976888 10876 966012

On difference scenarios, I have seen 50 MB+ performance on the same drives using ntfs-3g.
It looks like it depends on the files, possibly file size.

[Jean-Pierre (jean-pierre-andre)]

Hi Mikko,

You did not indicate which ntfs-3g version you are using.

Anyway the performance indeed depends on the file size, and on the fragmentation of the partition. You should try the improvement for big and fragmented files in ntfs-3g-2010.8.8AR.5 See http://www.tuxera.com/community/ntfs-3g-advanced/

[Dmitry Ostasevich (ostasevich)]

Can confirm this bug in Maverick. This happens when copying some sort of big files from ext4 to ntfs , also when Transmission saves something to ntfs partition. The GUI becomes completely unusable, it freezes till the end of copying or finishing download in Transmission, but still I can use console. I didn't notice such behavior of ntfs-3g in Lucid. What kind of additional info should I post to help solve this bug?

[Jean-Pierre (jean-pierre-andre)]

Hi Dmitry,

Can you post the result of the command (type in a terminal window)
getfattr -e hex -n system.ntfs_attrib <a-slowly-written-ntfs-file>
Obviously replace "<a-slowly-written-ntfs-file>" by the name of an NTFS file you had difficulties writing.

[Dmitry Ostasevich (ostasevich)]

I can't reproduce this bug now. As soon as I will catch it again, I will post that information.

[Pauldb (polichinel8)]

Not only does this happen when we we Transmission, but everytime Ubuntu writes something on the hard drive !
Firefox downloads, apt-get install, youtube buffering... Everything ! Something MUST be done. We should change its importance.

[Jure Sah (dustwolfy)]

Perhaps write an EXT4 driver for Windows. ;)

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

Looks like this is solved with NTFS-3G Version 2011.10.9AR.1 (Nov 7, 2011)

amongst other improvments:

 * fixed huge data writes

http://b.andre.pagesperso-orange.fr/changelog.html

[Jure Sah (dustwolfy)]

AFAIK that revision of the code and all of it's "fixes" is included in this code, and guess what, the bug isn't fixed.

[Fiodor Kupchik (ferimy)]

Bug present in 2012.1.15AR.1-1ubuntu1. Torrent eats the whole core of my CPU.
Attached the strace for driver. The only thing that, I guess, triggered high load was the file decompression in windows system. Some error were fixed by chkdisk as well.

[Fiodor Kupchik (ferimy)]

I just noticed that high load appears only when I start to download very large media file, size is almost 27Gb. And primarily download process was started in windows system then it continued in Ubuntu. I'm using latest 12.04 branch.

[fedsotto (fedsotto)]

The same happens to me extracting a large zip file in 11.10 on a ntfs drive.

[Mihir Mone (monemihir)]

I can confirm that the exact same thing is happening in 12.04 as well. Tried copying 153GB from an external drive to local ntfs partition and it took over 2 days. Did the same thing from Windows and it took only 8 hrs.

[Ivan Gualandri (ivang)]

I can confirm that the problem is still present.
I'm not sure but i notice that it happens not only with huge files, but also when workin with a browser with many tabs opened, i'm not sure if it is related, but when the disk start to swap, i receive also several errors of unresponsive scripts of the browser.

[jno (jnoster)]

Observing this high load/low performance (71.5Kbps) right now in

3.0.0-16-server #28-Ubuntu SMP Fri Jan 27 18:03:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 1434 root 20 0 28032 7836 692 R 35 0.1 116:21.51 mount.ntfs
21912 nobody 20 0 95884 4748 3276 S 32 0.1 50:32.78 smbd

[jno (jnoster)]

PS. It's a 900M set of relatively small files (below 1Mb each)

[bruce (bruce-oy)]

the bug is still present in ubuntu 12.04.
i am using kubuntu. i let neopmuk srigi to index files in the ntfs volume. when indexing start, mount.ntfs process cosumes about 60% cpu time and temperature of cpu go to 70 degree or even higher.

[Kenny Loveall (kenny-7)]

I've recently switched over from Windows to Ubuntu (11.10) and was pulling my hair out trying to figure out why two programs we're hanging and being very unresponsive (Filezilla and VirtualBox). Turns out that it was that I was running them off a NTFS partition (and therefore having ntfs-3g taking 70-100+% of CPU as others have said). I switched them to run off a non-NTFS partition and the transfers in FileZilla (when they worked) jumped from about 5KB/s total to 1,600 KB/s.

Personal anecdote aside, I agree that this bug should be listed a lot higher than medium. For people that have recently switched from Windows and still regularly work with files on their Windows partition it is a huge headache when everything is slow to respond. Not to mention that it's been known since 2009 so isn't it time we fixed it? I would try myself but I don't know enough to even know where to start, however I hope someone else fixes it soon!

[Sam Geen (samgeen)]

I have the same problem (running Wubi with Ubuntu 12.04) and it's rendering my computer virtually unusable. I have also had this problem on a different computer running Wubi with Ubuntu 11.10. I have been using Wubi with Ubuntu 11.04 on the same machine with no problems in the past. All have been clean installs (i.e. not upgraded from previous versions). My version of ntfs-3g is "ntfs-3g 2012.1.15AR.5 integrated FUSE 27" (though the problem has existed for other versions after Ubuntu 11.04).

mount.ntfs appears to run whenever write-to-hard-drive is occurring. Additionally, it blocks most applications from running (presumably as they all eventually need to read/write to HDD), resulting in greying out of the application window for a few minutes. It's especially problematic when doing >1MB file operations (e.g. installing packages with apt-get). The Windows install is barely used, so it's unlikely to be highly fragmented.

I have tried various things mentioned in this thread to no effect (I came unstuck with the suggestion to backport ntfs-3g as Ubuntu refused to backport fuse/fuse-utils for some reason). I agree that it's bizarre that this bug has persisted for so long without a fix, especially since (in my experience) it make Wubi unuseable. I suspect that my solution will eventually be to give up on Wubi and create a new partition for Ubuntu, but it's frustrating that I'd have to do this when previous versions have worked fine.

[Sam Geen (samgeen)]

Quick update on the above: I defragmented my hard drive last night, and it appears to be a little better than before, but I'm still seeing 100% spikes on mount.ntfs coupled with windows / the entire OS freezing for a few minutes at a time (I got the most recent one installing updates and buffering a YouTube video at the same time).

[Lok (lachlan-grogan)]

I struggled with this problem for many days. I am running Ubuntu12.04 on a server and dual RAID1 setups with dual 2TB disks in each. Disks are formatted with NTFS and are used with samba for windows files storage.

A week ago our system started running slow after moving some files. Results of the 'top' utility shows 99% CPU assigned to mount.ntfs-3g. Despite several reboots same problem.

The solution that worked for me was to umount the affected drives and run ntfsck on them. The utility reported the drive was dirty. To fix the dirty flag I run ntfsfix -d /mnt/... and then rechecked using ntfsck.

After the dirty flag was cleared the system is back to normal.

Hope this helps anyone else with the same issues.

[Lok (lachlan-grogan)]

I have another update to my post #77.

We have had the same high-cpu load problem as described above today (Monday morning).
We traced it down to a Windows7 machine doing a Sunday night backup to our server.
Windows backup created a 190,251,249Kb (181GB) single file as part of its backup set.
This file causes the ntfs-3g driver to go into a spin and use 99% cpu.
Wondering if the dev team for this driver can create a file this big and see what happens to the driver.?
This problem is re-creatable. Copy the file back onto the ntfs-3g enabled drivers and the driver goes into 99% mode again.

[Sam Geen (samgeen)]

Out of interest, if I were to create a new partition for Ubuntu, what file system should it use? I'm guessing installing Ubuntu on an NTFS partition would be a mistake.

[jno (jnoster)]

Wrong, Sam.
If you were to create a new "really big" partition for use on a mobile rack or an USB-disk for data exchange with the "outer world", what would be your choice? I think, NTFS as the "common denominator" which is somehow understood by the most OSes (and, what might be even more important) "appliances" like media players (which have a linux on board, but cannot handle anything except of FAT/NTFS on drives attached to them).
Another case (well, my one) is a sorta "legacy" - NTFS disks which were moved from a windoze HTPC to an ubuntu NAS. Would you want me to re-format all those disks?

[Sam Geen (samgeen)]

Well, sure. My issue is that I don't know nearly enough about Linux to look into this bug myself, and have no idea what combination of factors causes it to freeze my laptop every time I copy more than 10-100MB or so onto my root directory (a Wubi Ubuntu 12.04 install over Windows 7). Is it Wubi that's causing the problem (which didn't exist in my previous 11.04 install). Is it a new version of ntfs-3g that caused this bug to occur sometimes? Is it a symptom of multiple causes across Ubuntu, or is it a single problem that people have no interest in fixing?

Since this is the root directory doing this I doubt I can unmount as suggested above. So I'd rather adopt the approach that causes this problem to go away fastest rather than have my system hang every time I want to do something other than edit text files, since it seems like this problem won't be solved any time soon.

[headless (headless-)]

I also would appriciate to put this from medium to high. This bug kept me from using Linux several times, when it was nessesary to share files between windows and linux systems. For example i need to start several vms from a windows and linux host.

[JaSK (gigeclae)]

try enabling big_writes option for ntfs-3g.

I did it on a wubi installation and it seems to have brought a significant improvement, but cpu usage of ntfs-3g is still very high.
in /etc/default/grub write:
GRUB_CMDLINE_LINUX_DEFAULT="rootflags=big_writes quiet splash"

clearing the "dirty flag" improves performance too, I think.

[JaSK (gigeclae)]

...you might have to do sudo update-grub afterwards to apply changes.
I'm new to linux :P

[Zoke (ogmuk)]

I was almost constantly getting ~95% CPU spikes from the mount.ntfs process, according to 'top'. Disk fragmentation or big files (some files as large as 16GB) were not causing the issue. Defragmentation of the disk, using a Windows workstation, didn't change anything performance wise whatsoever.

What fixed it for me was physically mounting the hard drive to a Windows workstation and using CHKDSK. The disk wasn't damaged or anything but apparently ntfs-3g causes 'free space marked as allocated' in both the Master File Table (MFT) and volume bitmap. Once this is fixed the huge spikes are gone. At least for me.

Hopefully this info can shed some light into the CPU spikes and help some others who are having the same problem.

[Zoke (ogmuk)]

Apparently the fix only worked for about an hour and then the ~95% CPU spikes error returned. The solution Lok posted (https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/392204/comments/77) is still working.

[Rus Newtron (techabsorbed)]

I also experience this bug. mount.ntfs will consume 100% CPU (resulting in OS freezing temporarily until whatever process completes). It's usually triggered by untarring large tarballs, or downloading large files to the NTFS partition, moving large files. I'm on 12.04 installed via Wubi from Windows 7. I've tried a variety of the suggestions presented in the comments and on other sites. I've given up now and I'm reinstalling Ubuntu on ext4. Good luck everyone!

[Freddy Angel (fhangel)]

I have the same problem. I'm runing Ubuntu 13.04 on a ext4 partition and it works perfectly. However, when copying files between two external hard drives, I notice 2 "mount.ntfs" processes running and one of them would use 80%+ CPU aprox, according to "top".

[Jean Jordaan (jean-jordaan)]

I ran into this when trying to create a truecrypt volume on a file stored on an NTFS external drive. Format starts out at around 25MB/s and dwindles to around 5MB/s.
Meantime `mount.ntfs` is consuming 80-100% CPU.

[Spiralofhope (spiralofhope)]

This is one of those issues where I can idly conclude that either the developers don't eat their own dog food (use their own product), the issue is a legal or social problem, or intentional.

I don't think my use case is particularly strange, and this problem is a show-stopper.

On top of that, the software I'm using (the game Path of Exile) appears to have some serious filesystem access inadequacies, and it's recommended that people use NTFS (even on Wine). Phooey.

So here's what I've tried:

--

Some of the earlier comments talked about perhaps-related issues being fixed in earlier versions, and about unofficial repository versions. I'm using Lubuntu 13.10, updated recently. My version of ntfs isn't hopelessly outdated.

  ntfs-3g --version

ntfs-3g 2013.1.13AR.1 external FUSE 29

I assume that any mainline fixes found a year or more before 2013.1 would have been included in what I'm using. I really don't want to get into compiling my own version to include anything more recent.

However, perhaps I should take compiling more seriously. Comment 32 gives some hope, even though it's quite old.

--

comment 77 mentions

  ntfsfix -d /path/to/mountpoint

I did this (after unmounting). There was no change.

--

comment 83 mentions using a big_writes flag, which I did via fstab:

UUID=FOO /path/to/mountpoint ntfs-3g defaults,noatime,uid=1000 0 2

There was no change. Perhaps that's to be expected. According to http://b.andre.pagesperso-orange.fr/changelog.html :

Version 2011.4.12AR.1 (May 18, 2011)
> defined a mount option big_writes to use application-defined write buffer sizes

I wouldn't be surprised if my particular use doesn't define some more-optimal write buffer size.

[Yuv (yuv)]

Xubuntu 14.04LTS, still affected. While I do not use NTFS myself, a Windows-using friend brought this NTFS formatted USB harddisk. Needless to say that what he saw has undermined my efforts to convert him to use Linux...

[flamenco108 (flamenco108)]

Confirm the comment above.

Linux 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Xubuntu actually.
MemTotal: 4045588 kB
CPU model name : Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz

Copying 20GB file to USB disk formatted on NTFS I have 50% CPU load eaten by mount.ntfs process and ca. 40% by Thunar, as I made again this mistake and began to copy via GUI.
In fact nothing else can be done during the copying process. Strange.

[Abdusamed Ahmed (sir508)]

Can confirm for it still be occuring on 15/1/2015.

Linux Linux-Mint 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Running Transmission and its torrenting a file into NTFS partition. Extremely high CPU usage from mount.ntfs-3g process. I hope this get fixed sometime soon.

[Edward (edward-kondratiev)]

Had a similar problem - mount.ntfs-3g process uses up to 80% of CPU.
Finally found the reason - large files (40GB).
mount.ntfs has a special option to support large files - big_writes.
I updated my /etc/fstab configuration file and it works now!
CPU load variates from 0 to 45%, but not constant 80% anymore.

Example of /etc/fstab file:

/dev/sda1 /media/USBHDD1 ntfs noatime,big_writes 0 0

[Boris Gjenero (boris-gjenero)]

I'm also having this problem copying to an external USB 3 drive, with Nemo (Cinnamon file manager) copies around 35 MiB/s on my Q6600 CPU. big_writes helped, but although file copying via Nemo sped up to around 60 MiB/s, it was still CPU bound. Copying via pv < source_file > dest_file is faster and not CPU bound, around 130 MiB/s. pv without big writes is CPU bound at 90 MiB/s, so Nemo seems to be the main culprit in my case.

This is in Xenial Xerus (development branch) 16.04 64-bit.

[xennex82 (xennex82)]

Still true today. Copying about 180 MB of smaller files (pictures) to a NTFS partition (filesystem) inside TrueCrypt. It took 20 minutes. I partition the same mapped device -- format it -- to exFAT, and it takes 26 seconds.

So it took 26 seconds to write that same data at 7.2 MB/s and it took 20 minutes to write the same data at 160 kB/s.

Just incredible. Just incredible for something that has been around for so long.

Not eating their own dog-food, I guess.

[Fedon Kadifeli (fedkad)]

It is interesting to note that this problem persists for almost a decade. Ubuntu 18.10 here with the same problem.

[Jerome St-Louis (jerstlouis)]

I seem to be running into this issue on Debian 9.5 here in 2019.
ntfs-3g 2016.2.22.AR.1 integrated FUSE 28

[Jerome St-Louis (jerstlouis)]

In my case, many fopen() operations seems to be what is slow.

[Kapil (kapildverma)]

Same problem with KDE Neon, on Ubunut 20.04, and its more than a decade this bug was created. Its amazing.

[Lena Wildervanck (l-wildervanck)]

Hi, I also encountered this bug.

However, it started fast, and got slower when the file got bigger.

Maybe it's a n^2 bug?

I included the statistics in rates.tsv.