Re: [kde-linux] How to Get the Combination of NTFS-3g and Konqueror (as a file manager) to consume less CPU
- Date: Sun, 11 Nov 2012 00:23:18 +0200
- From: Shlomi Fish <shlomif@xxxxxxxxxxxxxx>
- Subject: Re: [kde-linux] How to Get the Combination of NTFS-3g and Konqueror (as a file manager) to consume less CPU
On Mon, 5 Nov 2012 19:43:16 +0000 (UTC)
Duncan <1i5t5.duncan@xxxxxxx> wrote:
> 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.
Killing gam_server causes it to start again almost immediately.
> 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.
This mount is the entire Windows 7 x86-64 partition (including C:\Program
Files, C:\Windows, etc.) which needs to be NTFS.
> 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.
OK, I'd rather have one single C:\ partition with all the space there. I can
put these files on the networked computer anyway.
> 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.
Also sounds like a lot of hassle. In any case, I filed a bug report about it:
Shlomi Fish http://www.shlomifish.org/
Nobody expects the Randal Schwartz condition!
â David Fetter
Please reply to list if it's a mailing list post - http://shlom.in/reply .
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.