I did truss several of the gnome applications that where consuming cpu time (gnome-settings-daemon, nautilus, gnome-panel), and at least in one of the truss output files I noticed that /etc/mnttab was re-read. But I don't remember any more which of the three processes did re-read /etc/mnttab.
It's possible that /etc/mnttab is among the files that receive bogus file time attribute changes from the kernel, but I think this is just one file out of many others that receive these events. 2009/6/22 Ghee Teo <Ghee.Teo at sun.com>: > Hi Jurgen, > > Does the kernel changes cause the /etc/mnttab to be updated in its time > stamp? > > Could that be, > > http://monaco.sfbay.sun.com/detail.jsf?cr=2174138 > more details here > http://bugzilla.gnome.org/show_bug.cgi?id=585360 > > exacerbated by the kernel change? > > -Ghee > > Ju"rgen Keil wrote: >> >> I'm not 100% sure what exactly is broken, but since a day or two (after I >> bfu'ed my system >> from current onnv-gate sources), the idle gnome desktop has started to >> consume *lots* of >> cpu time. ?The system is a SX:CE snv_111, bfu'ed with current onnv-gate >> bits. I've never noticed such a problem with bfu of older onnv-gate bits >> (onnv before 2009-6-16). >> >> I see several gnome processes (gnome-settings-daemon, nautilus, >> gnome-panel) each trying >> to consume 100% cpu time; the processes perform stat system calls all over >> the place >> (e.g. in /etc/xdg/, my home directory, ~/.local/, ...), and they are >> reading /etc/mnttab >> quite often. >> >> >> Looking through the change log for the last 2-3 days I noticed the putback >> for bug 6539657 >> "touch(1) does not set the nanosecond timestamp of a file correctly". >> >> >> When I disable the stat microsecond workaround[*] that was added to the >> kernel with the >> putback for 6539657, the gnome desktop returns to sane behaviour; the idle >> gnome desktop >> does not consume lots of cpu time any more. >> >> >> I suspect that gnome is detecting bogus file system changes and is >> re-scanning start menu >> entries, folder contents, local setting files, etc. >> >> Can anyone else reproduce this? ?Is this a known problem? >> >> >> >> [*] ? ?echo stat_force_usec_granularity/W0 | mdb -wk >> > >
