Re: How to Get the Combination of NTFS-3g and Konqueror (as a file manager) to consume less CPU

Hi Duncan,

On Mon, 5 Nov 2012 19:43:16 +0000 (UTC)
Duncan <[email protected]> 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...
> 

OK.

> 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.  

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.
> 
> http://en.wikipedia.org/wiki/Universal_Disk_Format
> 

Also sounds like a lot of hassle. In any case, I filed a bug report about it:

https://bugs.mageia.org/show_bug.cgi?id=7985

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html

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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.