Hi Chris, On Mon, Sep 17, 2012 at 09:51:37AM -0600, Chris Friesen wrote: > We're running 2.6.27 (upgrading not currently possible, embedded product). > > We had a situation arise where we could see in stack traces that a > number of tasks were stuck in vn_iowait(). That function takes a > pointer to xfs_inode_t. Given that, would it be possible to work > backwards to determine a filesystem path corresponding to that > inode? I realize it would likely only go back to the head of the > filesystem, but that would be fine. Yep, it's possible. echo t > /proc/sysrq-trigger won't give you the full stack, but you may be able to get an idea of what is going on, well enough to make some guesses as to the culprit. That's probably your best first step. If you have crash installed: 1) disassemble vn_iowait and find out which register the xfs_inode_t pointer is in. 2) print out the full stacks of all the processes in the system. 'bt -f', I think. 3) grep for the xfs_inode_t pointer on those stacks. Regards, Ben _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
