Re: mmotm 2016-08-02-15-53 uploaded

2017-10-10 Thread Vitaly Mayatskikh
On Tue, 10 Oct 2017 20:48:34 -0400, Changwei Ge wrote: > > Hi Andrew and Vitaly, > > I do agree that patch ee8f7fcbe638 ("ocfs2/dlm: continue to purge > recovery lockres when recovery master goes down", 2016-08-02) introduced > an issue. It makes DLM recovery can't pick up a new master for an

Re: mmotm 2016-08-02-15-53 uploaded

2017-10-10 Thread Changwei Ge
Hi Andrew and Vitaly, I do agree that patch ee8f7fcbe638 ("ocfs2/dlm: continue to purge recovery lockres when recovery master goes down", 2016-08-02) introduced an issue. It makes DLM recovery can't pick up a new master for an existed lock resource whose owner died seconds ago. But this patch

Re: mmotm 2016-08-02-15-53 uploaded

2017-10-10 Thread Andrew Morton
On Tue, 10 Oct 2017 14:06:41 -0400 Vitaly Mayatskih wrote: > * ocfs2-dlm-continue-to-purge-recovery-lockres-when-recovery > -master-goes-down.patch > > This one completely broke two node cluster use case: when one node dies, > the other one either eventually crashes (~4.14-rc4) or locks up (pre

mmotm 2016-08-02-15-53 uploaded

2016-08-02 Thread akpm
The mm-of-the-moment snapshot 2016-08-02-15-53 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You wi