nHung dt processes are oftentimes encountered during perturbation (disruptive) type tests (failovers, panics,
etc).
nUsually this is the result of an I/O stack (driver),
adapter firmware, switch, and/or
storage device issue.
nNormally dt will be hung in some system call, e.g. open(), read(), write(), fsync(), etc.
nDepending on the OS, either the kernel debugger or user level debugger can be used to report dt’s stack
trace.
nIn lieu of a stack trace, forcing a system crash to send
the OS vendor for analysis is
usually necessary and required.
nGather OS error logs, switch logs, storage logs,
etc.
nUse dt’s no I/O progress feature to trigger an analyzer.
nFWIW: Oftentimes folks wish to run another I/O tool, to reproduce the original hang. Personally, I believe this is a waste of time, since dt is not the reason for the hang!
nWhether hangs or DC’s, one must learn to trust the tool.
J
n