Hi Max, On Sun, 21 Oct 2007, Max wrote:
> I'm using ntfs-3g v1.0004 (and used older versions for almost a year). My > current FUSE driver is v2.6.5. Distro is Slackware-12 with 2.6.21.5-smp > kernel. Recently I found out that ntfs-3g eats a lot of CPU time in user > space while intensive read operations in progress. All file systems use sometimes very significant CPU time but they are not directly visible since it's counted in the overall system CPU time. High (>80%) NTFS-3G CPU usage during read was not known so far. The driver has the 128 kB readahead feature which reduces CPU usage by at least an order compared to write operations and typically either the disk I/Os or the memory copies are the real bottleneck. > I read the FAQ here: http://www.ntfs-3g.org/support.html#questions and > there are questions only about slow writing. There is an entry about "Why does the driver use 100% CPU time?" which may give some help: http://ntfs-3g.org/support.html#cpu100 You may need to CTRL+reload or SHIFT+reload the web page. For example some software bug (e.g. ignored error handling) could cause flooding ntfs-3g with the same invalid file system requests what ntfs-3g may log (/var/log/messages) and this can also cause high CPU usage. For example recent thunderbird versions have such problems. > I checked other stuff: DMA is on; switching between IO schedulers doesn't > change anything. I noticed slowdown using linuxdcpp p2p client, it > calculates hashes of all shared files and all my files are on ntfs > volumes. The issue could be linuxdcpp related. Could you please do the below mount -t ntfs-3g -o debug <device> <mountpoint> &> /tmp/ntfs-3g.log reproduce the problem and send me the compressed /tmp/ntfs-3g.log file? > So, when hashing, the driver's CPU usage jumps periodicaly hanging the > whole system (even mouse cursor lags for a moment). I user space process shouldn't be able to hang the system. If this is true then there is a kernel, probably process scheduler problem. > This is very irritating. I tested linuxdcpp hashing process on reiserfs > volume too - as I expected it went fine, no lags at all (even when > hashing speed reaches 7Mb/s). The dynamic of the system is different with more active user space processes. No (minimal) context swithces are involved using an in-kernel file system. What you write sounds to me that a hidden(?) kernel scheduler problem was exposed by your workload. Quite a lot of work is going on in this kernel area recently. > BTW, it seems older versions of ntfs-3g didn't have this bug or it was > not that much visible (sorry, but I don't remember which version was last > good, because I upgrade my software often). Could be perhaps also a linuxdcpp upgrade which has changed its algorithm recently? > I really appreciate your work, only the ntfs-3g driver presence made it > possible for me to migrate from windows to linux. And I hope this "bug" > will be squashed in further versions. Sure but we need more info about the nature of the bug. > As a developer myself I wish you luck ;) Excuse me for my imperfect > English. TIA. Thanks, Szaka ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
