Martin, your response has brought up a number of topics: --------
> About two weeks ago I had this same impression as you do now, though, > before I noticed that it was because the datastore was busy indexing a > few kernel build trees on two usb drives I had plugged in. Well, I have a NUMBER of removable storage devices plugged in. When I first started, I wrote a ticket saying "please give me a way to tell Journal NOT to 'index' these". That ticket was closed with: "that's something we have in mind <for a future implementation>". As it is, when I do an 'olpc-dump', I've seen it be larger than 1MB -- because of the 'datastore.log' files. Obviously, *something* is spending a LOT of time "walking" my removable storage devices. But since this is something NOT DOCUMENTED for users to control, I'm choosing to live with it. [And complain about Sugar responsiveness.] -------- > Are you sure that the machine is otherwise idle when you're > experiencing these undesireable delays? How should I know ? Is there a 'resource monitor' for Sugar ? If I walk up to the machine at a random moment and issue 'top', it typically shows the machine to be 90% idle. But there have been plenty of times when 'top' shows it to be 0% idle. For instance, if I do 'sugar-control-panel -g available_updates' on a recent Joyride, the machine goes 0% idle for 10+ minutes, then gets an OOM. -------- > dbus-send --session --print-reply --reply-timeout=3D2000 \ > --type=3Dmethod_call --dest=3Dorg.laptop.sugar.DataStore \ > /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.unmount \ > string:<datastore mount id> THIS is what I have the greatest amount of difficulty with. I fail to see the necessity of users having to learn the "internals" of dbus usage in order to be able to control their systems. If there is a "knob" that users need to turn, DOCUMENT IT !!! Besides which, I have my removable storage devices mounted __for a purpose__. [They contain software and data which I reference every time I use the system.] I have no intention of unmounting them. mikus _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
