Hi Duncan, On Mon, 5 Nov 2012 19:43:16 +0000 (UTC) Duncan <1i5t5.dun...@cox.net> 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.
