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