Ocfs2 users - Jun 2006 - Being prepared for problems: how?

Over the week-end we have upgraded to the latest kernel in our SLES9 servers, 
so we're running OCFS2 1.2.1.  It all went very smooth and easy (we had 
tested everything, beforehand, on a test-cluster).  No problems whatsoever so 
far, but it's only been two days.

But we want to be prepared in case something bad pops up.  We want to be able 
to obtain some debugging information.

Unfortunately, the SLES kernel does not include debugfs.  Is there anything we 
can do?

debugfs is useful when one wants to quickly identify the
offending lock. But not much beyond that. Yes, I would prefer
to have it, but that's life. (SuSE will be bundling it with SLES10.)

However, the rest of the debugging infrastructure is still in place. Like,
tracing in kernel, dlm lock dumps and alt-sysrq-t. Ensure your servers
are configured with a netdump/netconsole server so that if you get an
oops, you capture the full oops trace.

Silviu Marin-Caea wrote:
> Over the week-end we have upgraded to the latest kernel in our SLES9
servers,
> so we're running OCFS2 1.2.1.  It all went very smooth and easy (we had
> tested everything, beforehand, on a test-cluster).  No problems whatsoever
so
> far, but it's only been two days.
>
> But we want to be prepared in case something bad pops up.  We want to be
able
> to obtain some debugging information.
>
> Unfortunately, the SLES kernel does not include debugfs.  Is there anything
we
> can do?
>
>
> _______________________________________________
> Ocfs2-users mailing list
> Ocfs2-users at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-users
>