On Wed, Jul 24, 2013 at 08:28:42AM -0500, Mark Tinguely wrote:
> If you could please redo the test and get the stack traces with
> /proc/sysrq-trigger and if you kernel works with crash, a core dump.
> For the stack trace, I mostly want to know if it has several
> "xlog_grant_head_wait" entries in it, because ...
> ...I seemed to have triggered a couple log space reservation hangs
> with fsstress one XFS partition and a mega-copy on another
> partition, but will have to graft the new XFS tree onto a Linux 3.10
> kernel to get crash (and one of my sata controllers) to work again.
They are unrelated to this patchset.
Somewhere in the code there
is a mismatch between what we reserve as the base requirement for an
actual log write and what the CIL actually steals, and that is, most
likely, what is leading to log hangs.
This is demonstratable in the fact that generic/070 on 512 byte
block size filesystems regularly hits a transaction reservation
exhausted assert failure on transaction commit of the periodic log
dummy transaction on my test rigs.