Bugzilla – Bug 219929
kde menu -> system seems to stat mount points
Last modified: 2009-05-14 11:56:43 UTC
selecting 'System' from the KDE menu seems to trigger a stat on all mount points. It did have for a few seconds until it displayed the actual contents of the 'System' submenu. Now imagine if any of the mount points were a hanging NFS mount point... Luckily there was only a scsi drive in stand by mode.
Created attachment 104708 [details] sles10-kde-menu-system-tries-to-access-mount-points.png
that would be strange, and I could only think that it searches for icons or desktop files there. what are your mountpoints? can you reproduce it, what is it stat'ing for?
how do I know? what process do I have to strace? olaf@nectarine:~> cat /proc/mounts rootfs / rootfs rw 0 0 udev /dev tmpfs rw 0 0 /dev/hda11 / ext2 rw,nogrpid 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 debugfs /sys/kernel/debug debugfs rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/sda7 /abuild ext2 rw,nogrpid 0 0 /dev/hdb11 /install/hdb reiserfs ro 0 0 nfsd /proc/fs/nfsd nfsd rw 0 0 automount(pid3263) /mounts autofs rw 0 0 automount(pid3265) /suse autofs rw 0 0 automount(pid3267) /secret autofs rw 0 0 usbfs /proc/bus/usb usbfs rw 0 0 wotan:/real-home/olh /suse/olh nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,nolock,proto=tcp,addr=wotan 0 0
it should be either kicker (unlikely) or kded (likely). those are unique apps, so try strace -p $(pidof kicker) / strace -p $(pidof kded). from the mountpoints I see nothing wrong. my current guess is that it is the hal backend of the media manager that is causing the stat of the mountpoint.
I tried this, kicker, kded or the both hald processes did not do the stat.
can you trigger it by running "dcop kded mediamanager fullList" ?
kicker does for sure. It does a statfs to display the size and amount of free space on the media. And I see no way to not do that on power saved media ;( Greg, do you see one?
either the kernel should provide a way to say "only do statfs if you it is expected to return fast" or the kernel should cache the root inode, superblock and whatever else it needs for statfs to succeed before powering down a device.
or perhaps hald can supply an event that we can abuse for "this device is going to power down soon, run statfs if you want to cache it".
No, I don't see a way to not do that on media that is plugged in, unless you want to look at the property in HAL that shows it is a removable device.
Which won't help as builtin disks can powerdown too. But we can at least make the menu not stall when this happens, but not for 10.2
just wondering.. this is the same like with running "df" and a powered-down drive, correct? I would consider this to be a generic kernel bug and don't think it is worth adding a workaround for it to the kickoff menu.
one could argue that it is fixed in 10.2 because the kde menu looks now different.
huh? it should still have a list of partitions together with its size, nothing should have changed. anyway, does df also wake up your drive?
no, df does not do that. at least it never caused any IO errors as shown in the screen shot.
I see it in 10.2 when clicking on the kde menu.
does stat <mountpoint> trigger them? it really does nothing more than a stat and a statfs() call..
*** Bug 271307 has been marked as a duplicate of this bug. ***
https://bugs.kde.org/show_bug.cgi?id=184062