On Wed, Oct 12, 2016 at 03:50:36PM -0400, CAI Qian wrote: > > > ----- Original Message ----- > > From: "Dave Chinner" <david@xxxxxxxxxxxxx> > > Sent: Monday, October 10, 2016 5:57:14 PM > > > > > http://people.redhat.com/qcai/tmp/dmesg > > > > It's a page lock order bug in the XFS seek hole/data implementation. > So reverted this commit against the latest mainline allows trinity run > hours. Otherwise, it always hang at fdatasync() within 30 minutes. > > fc0561cefc04e7803c0f6501ca4f310a502f65b8 > xfs: optimise away log forces on timestamp updates for fdatasync Has nothing at all to do with the hang. > PS: tested against the vfs tree's #work.splice_read with this commit > reverted is now hanging at sync() instead which won't be reproduced > against the mainline so far. > http://people.redhat.com/qcai/tmp/dmesg-sync It is the same page lock vs seek hole/data issue. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
