[kde-linux] How to Get the Combination of NTFS-3g and Konqueror (as a file manager) to consume less CPU

[Duncan]

Shlomi Fish posted on Mon, 05 Nov 2012 17:40:10 +0200 as excerpted:

> replying to myself in the same thread, I wanted to inform everyone that
> after upgrading to Mageia Linux Cauldron (the Mageia development branch
> that is going to become Mageia 3), the problem has worsened. Now,
> mount.ntfs sometimes consumes over 50% of CPU (27%-60%), and gam_server
> consumes 20%. I don't get anything of this sort with Nautilus.

Repeating my earlier caveat, I don't do ntfs, so my knowledge/experience 
is extremely limited there...

Your mention (again) of gam_server, above, triggered a memory.  Some time 
ago, I /think/ clear back in the kde 4.2/4.3 era when kde4 was still very 
buggy and I was in the process of upgrading from kde3, I had a gam_server 
problem.  I believe it was due to a bug in the (Linus/mainline prerelease) 
kernel I was running at the time and for me the resolution was that the 
bug was found and fixed in the kernel, before its full kernel version 
release.

The gam_server thread would go unresponsive, and because kde (kded, the 
component that notifies running kde apps when the config changes) depends 
on it for config file change detection, that meant kded went 
unresponsive, which had "interesting" (bad-way interesting) effects on kde 
apps.

But more than that, bits of kde would start using serious CPU time, I 
guess in spin-locks, waiting for config queries to return, which they 
never did, because kded was unresponsive.

Killing gam_server would often break the jam, but of course, then the app 
that had queried/changed the config wouldn't have correct config 
information, and would often go pear-shaped.  Additionally, the stability 
of kde as a whole was pretty bad as a result, and I ended up frequently 
killing kde, killing kded (which wouldn't die on its own due to the 
problem, killing any remaining gam_servers, and restarting kde, quite 
often.

As I said, that was a short-term kernel bug, at least on the reiserfs I 
normally run, made more severe in that case because I WAS still 
transferring from kde3, and thus changing the config rather frequently, 
thus making the problem MUCH worse than it'd have been otherwise, since I 
was constantly triggering it due to config changes that I'd not normally 
have been doing.  But, being a reasonably quickly caught pre-release-only 
kernel bug, I didn't have to deal with it for that long.

But gam_server may be simply incompatible with ntfs, at least userspace 
ntfs-3g.  If that's the case, it's no /wonder/ you're having problems.  
As I did, you may find killing gam_server kills the problem as well... 
until the next trigger anyway.  But you may simply have to find a way to 
kill gam_server on your ntfs mount, either by changing what you store 
there, or by disabling whatever it is triggers gam_server on that mount, 
or whatever.

But... I don't know any way to turn it off...

Another possibility might be to switch to FAT32 for that mount, since it 
has to be shared with MS.  Since it's a kernel-space driver, I suspect 
it'll be far more efficient with gam_erver.

Yet another possibility would be putting those files on ext3/4 or the 
like, accessing them natively on Linux, and using the MS Windows ext*fs 
drivers to access the files on the ext3/4 filesystem when you're on MS.  
If you spend more time on Linux anyway, and/or don't access those files 
much from the MS side, that's probably the most effective option.  OTOH, 
it does make the MS side more hassle, so if you spend a lot of time 
accessing those files from there, and a lot of time in MS, then it's 
probably not a particularly useful idea at all.

Yet another possibility that I just though of and have little idea how 
practical it may or may not be as I've never tried it... UDF, universal 
disk format, which DVDs among other things use.  This is most commonly 
used for optical media (it's the standard for DVDs as I said), but at 
least on Linux, I believe it's possible to create and use on standard 
hard drives as well.  MS definitely understands UDF too, but I'm not sure 
if it can deal with it on standard hard drives or only on optical media.  
And, I'm not sure how efficient UDF is for ordinary hard drive use in 
normal read/write mode it is, either.  But if MS supports it on standard 
hard drives, and if as you say your primary use is music/media, your 
usage may be mostly write-once, read-many, in any case, and UDF should 
work quite well for that, since that's an assumption for optical media, 
it's primary use case.

Here's a link to UDF on wikipedia, since I'm looking at it ATM and thus 
have it handy.

http://en.wikipedia.org/wiki/Universal_Disk_Format

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman