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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
