[kde-linux] How to Get the Combination of NTFS-3g and Konqueror (as a file manager) to consume less CPU

[Duncan]

Kevin Krammer posted on Tue, 18 Sep 2012 13:59:30 +0200 as excerpted:

> On Monday, 2012-09-03, Shlomi Fish wrote:
> 
>> Now, it dual boots between Windows 7 x86-64 (which I hardly use) and
>> Mageia Linux 2 x86-64. Since I have a lot of space in my Windows 7
>> partition, I decided to use it to store many of my music files, so they
>> get stored at /media/win_d/Music/mp3 , which has this as its /etc/fstab
>> entry:
>> 
>> UUID=24A43690A4366488 /media/win_d ntfs-3g defaults,umask=022 0 0
> 
> I have my Windows partition mounted like this:
> /dev/sda5       /data/share     auto
> rw,user,noexec,noatime,umask=002,gid=users,utf8         0       0

FWIW, that noatime option looks interesting; the others (except for utf8) 
are permissions options, and shouldn't have much effect on CPU, but 
access-time updates, which is what noatime disables, could be rather 
signfificant in some usage scenarios.

Another possibility, since you're just using auto for the type, is that 
it's vfat or whatever, but you confirm elsewhere that it's ntfs, so that 
can't be the distinction.

Yet another possibility with type=auto is that it's using the kernel 
module, not userspace.  That's what I suspected might be the case.  But 
you mention a mount.ntfs process showing up in htop, and that /might/ 
indicate the userspace ntfs-3g, tho I don't really know enough about it 
to be sure.

> I am using Dolphin as file manager but my guess is that this doesn't
> make much difference (I think Konqueror is using the same file manager
> library when being used in file manager mode).

That matches what I've read all over as well.  Konqueror in fileman mode 
is using the dolphin "kpart", just with a different application shell 
around it.

Also, somewhere in the thread, SF mentions that he tried dolphin, with 
the same CPU results, so the dolphin/konqueror distinction doesn't matter.

> There is no CPU usage difference between viewing a directory on that
> mount point or not.
> 
> System is Debian, kernel is 3.3.0, ntfs-3g is 1:2012.1.15AR.6-1, Qt is
> 4.8.4, KDE is 4.8.4, Dolphin is 2.0

@ S Fish:

I'd suggest trying the noatime option... or possibly relatime.

The mount (8 and 2) manpages have useful information about all sorts of 
options, including the atime related options (atime, strictatime, 
relatime, diratime, and the no*atime variants thereof).  Relatime was 
made introduced in 2.6.20 and made the kernel default in 2.6.30.  It's 
often a reasonable compromise between full atime (the previous default 
and POSIX standard) noatime, updating atime only if the previous atime 
was before the mtime (modification time) or ctime (status change time), 
or once a day, otherwise, thus keeping apps such as mutt that need to 
know whether a file has been accessed (which mutt considers read, for its 
message files) since it was last modified.

So if the kernel's 2.6.30 or newer, it should default to relatime.  But 
with ntfs-3g being userspace/fuse, I'm not sure whether it would be 
subject to the kernel relatime default or not.

But regardless, I'd suggest trying noatime, unless you /know/ it'll break 
something you use, because noatime works just fine for most things.  If 
that helps, then you know it's atime related, and can try a specific 
relatime if you want to see if it works too, or just stick with noatime.  
Obviously, Kevin's running noatime too.

(FWIW, I've been using noatime here I think since I switched to Linux, 
back in 2001 when MS pushed me off of them with eXPrivacy, but I don't 
have to worry about MS since I couldn't agree to their EULA even if I 
wanted to run proprietary servantware, so I've been running reiserfs for 
almost everything for the same amount of time.  But Kevin's running 
noatime on his ntfs, so there can't be anything specific about the 
filesystem that doesn't like it.)

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