Re: [kde-linux] How to Get the Combination of NTFS-3g and Konqueror (as a file manager) to consume less CPU
- Date: Mon, 5 Nov 2012 19:43:16 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] How to Get the Combination of NTFS-3g and Konqueror (as a file manager) to consume less CPU
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
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
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
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,
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.
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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.