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