Red Hat Bugzilla – Bug 445632
mount.ntfs-3g CPU usage is up while transmission is downloading
Last modified: 2008-05-20 16:54:22 EDT
Description of problem: "mount.ntfs-3g" CPU usage is up while "transmission" is downloading Version-Release number of selected component (if applicable): 1.1120 How reproducible: Steps to Reproduce: 1. All last updates must be installed by "yum update". 2. Run "wget -c http://mirror.yandex.ru/centos/5.1/isos/i386/CentOS-5.1-i386-LiveCD.torrent". 3. Run "wget -c http://mirror.yandex.ru/centos/5.1/isos/i386/CentOS-5.1-i386-bin-DVD.torrent". 4. Run Transmission and open these (steps 2-3) torrents for downloading to a big busy NTFS partition (see attachment). 5. After CentOS-5.1-i386-LiveCD.torrent was ended and CentOS-5.1-i386-bin-DVD.torrent is downloaded approximately for 25%, then CPU FAN noise level is up, and CPU usage for "mount.ntfs-3g" process is 52-99%. 6. When PAUSE both of these torrents, "mount.ntfs-3g" process is returns to normal low CPU usage. Actual results: Expected results: Additional info: Transmission Version is "Transmission 1.04 (4888)" CPU is Intel Pentium 4 3.00GHz 1Mb L2 Cache Socket478
Created attachment 304832 [details] logs of bug reproducing
Hello, Similar problem here (close to 100% CPU usage when downloading F9 via torrents). kernel-2.6.25-14.fc9.i686 ntfs-3g-1.2506-1.fc9.i386 azureus-3.0.4.2-14.fc9.i386 When torrents stopped, CPU usage returns to normal (8-10%).
Roman: I have checked your logs. The problem is the third one from the list at http://ntfs-3g.org/support.html#cpu100 Namely: http://ntfs-3g.org/support.html#slowwrite
Btw, writing at many locations in the same large file at the same time (many peers at the same time, etc) can be also a major factor for very high CPU usage. NTFS-3G tries to counteract it but this can't be done when the disk is highly fragmented which is usually always the case when the disk is close to full (90% in your case).
I forgot to mention that you should __REALLY__ use at least 1.2506 instead of 1.1120: http://ntfs-3g.org/releases.html http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/536
Hello Szabolcs, I would tend to agree with your comments; however I was using ntfs-3g-1.2506-1.fc9.i386, and the ntfs partition was empty (far from the fragmentation stage). I just formated that partition to fat32 and restarted the same torrents resulting in NO high CPU usage (i.e. normal CPU load). Just for my 2¢ Cheers
Szabolcs, thank you! Successfull update ntfs-3g to the latest 1.2506 version was fixed my problem. After this update I was downloaded other torrents and run Transmission to download to the same partition with normal CPU usage (mount.ntfs-3g usage less than 10%). 2all: Can I close bug status?
Hi Eric! I replied to Roman. There are over nine trillion reasons for high CPU usage and http://ntfs-3g.org/support.html#cpu100 lists only the most common ones. Roman provided quite a lot of very useful debug logs (bug submission and comment #1) which helped to analyze the problem. You provided none, so it's not possible to tell what is your problem. One thing is sure. Unlike NTFS, FAT doesn't support sparse files so data allocation is either simple sequential or the file is preallocated which completely avoids the problem I described. Some torrent clients detect file system capabilities and work differently. I also bet that you can't save bigger than 4 GB files on FAT ;-)
Hello Szabolcs, Sorry for the delay in replying (I did reply but was not logged-in I guess!! So much for the new guy on Bugzilla). I thank you for your comments, and will provide more solid/factual information next time on Bugzilla. @Roman, go ahead and change bug status to closed if OK with other participants. Regards, Eric