I don't know if will be useful for you, but I have used SystemTap.<div>You can see at least a trace of the functions called.</div><div>Info:</div><div><a href="http://fedoraproject.org/wiki/Features/SystemtapStaticProbes">http://fedoraproject.org/wiki/Features/SystemtapStaticProbes</a></div>
<div><a href="http://sourceware.org/systemtap/wiki/PythonMarkers">http://sourceware.org/systemtap/wiki/PythonMarkers</a></div><div><br></div><div>With </div><div>stap /usr/share/doc/python-libs-2.7.3/systemtap-example.stp  -x pid_datastore</div>
<div>you can see all the functions called in the datastore</div><div>(of course if the process changes is not so easy :( </div><div><br></div><div>Gonzalo</div><div><div><br><div class="gmail_quote">On Wed, Sep 19, 2012 at 6:49 PM, Martin Langhoff <span dir="ltr"><<a href="mailto:martin.langhoff@gmail.com" target="_blank">martin.langhoff@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Sep 19, 2012 at 4:54 PM, Gonzalo Odiard <<a href="mailto:gonzalo@laptop.org">gonzalo@laptop.org</a>> wrote:<br>

> You already have the line<br>
> export SUGAR_LOGGER_LEVEL=debug<br>
> uncommented in .sugar/debug, right?<br>
<br>
</div>Yes. And with that, datastore.log is very chatty, which is good.<br>
<br>
But when the datastore code hits an unhandled exception, the exception<br>
does not get logged. DBus restarts the process transparently, but that<br>
isn't so useful :-/<br>
<br>
In terms of progress, I have these tracks underway,<br>
<br>
 - Add a "ds_clean" flag file, rm it on the start of every<br>
create/update/delete op, create it on completion. Complements<br>
"index_updated", and between the two we get good coverage. Missing<br>
either one, we get an index rebuild. This is done, and working well.<br>
<br>
 - During index rebuild, delete incomplete entries. Not working well yet.<br>
<br>
With the two above, we can operate with the system at ENOSPC, and<br>
essentially we don't lose existing user data. New files fail to save,<br>
and metadata changes fail to get stored (so your edit, ie: a rename,<br>
is reverted in the journal, visibly). But we don't lose the existing<br>
Journal entries -- so behaviour is _almost_ civilized now :-)<br>
<br>
Behind the scenes, however, the datastore is dying and respawning.<br>
Which complicates things because what we are missing is to be able to<br>
delete entries while we are at ENOSPC. A delete is pretty<br>
straightforward, because we are removing files, and that succeeds even<br>
on ENOSPC. Except that we need to be able to maintain the xapian<br>
indexes.<br>
<br>
My plan right now is to catch the Xapian-is-hitting-ENOSPC exception,<br>
and trigger a Xapian index re-creation, putting the Xapian files in<br>
/tmp (which is a tmpfs in our builds and in Fedora upstream too).<br>
We'll make sure that the index_updated file on disk is removed so<br>
after a reboot the index is recreated once more.<br>
<br>
With Xapian index on /tmp, deleting Journal entries should just work.<br>
All dbus sockets are on tmpfs.<br>
<br>
However, to do all of the above with some sense that it's working<br>
correctly... yeah, I need to see the exceptions I hit. Right now I am<br>
guessing "what could be going wrong in this black box...?" which isn't<br>
a productive mode of life.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
m<br>
--<br>
 <a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a><br>
 <a href="mailto:martin@laptop.org">martin@laptop.org</a> -- Software Architect - OLPC<br>
 - ask interesting questions<br>
 - don't get distracted with shiny stuff  - working code first<br>
 - <a href="http://wiki.laptop.org/go/User:Martinlanghoff" target="_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a><br>
</div></div></blockquote></div><br></div></div>