Ocfs2 devel - Aug 2022 - [PATCH 4/4] ocfs2: introduce ext4 MMP feature

On 7/30/22 9:14 AM, Heming Zhao wrote:
> MMP (multiple mount protection) gives filesystem ability to prevent
> from being mounted multiple times.
> 
> For avoiding data corruption when non-clustered and/or clustered mount
> are happening at same time, this commit introduced MMP feature. MMP
> idea is from ext4 MMP (fs/ext4/mmp.c) code. For ocfs2 is a clustered
> fs and also for compatible with existing slotmap feature, I did some
> optimization and modification when porting from ext4 to ocfs2.
> 
> For optimization:
> mmp has a kthread kmmpd-<dev>, which is only created in non-clustered
> mode.
> 
> We set a rule:
> If last mount didn't do unmount, (eg: crash), the next mount MUST be
> same mount type.
> 
> At last, this commit also fix commit c80af0c250c8 ("Revert
"ocfs2:
> mount shared volume without ha stack") mentioned issue.
I suggest we re-split this series (especially patch 3 and 4), but not
revive a buggy commit first and then another commit fixing it BTW.

Thanks,
Joseph

On Mon, Aug 08, 2022 at 04:19:22PM +0800, Joseph Qi
wrote:
> 
> 
> On 7/30/22 9:14 AM, Heming Zhao wrote:
> > MMP (multiple mount protection) gives filesystem ability to prevent
> > from being mounted multiple times.
> > 
> > For avoiding data corruption when non-clustered and/or clustered mount
> > are happening at same time, this commit introduced MMP feature. MMP
> > idea is from ext4 MMP (fs/ext4/mmp.c) code. For ocfs2 is a clustered
> > fs and also for compatible with existing slotmap feature, I did some
> > optimization and modification when porting from ext4 to ocfs2.
> > 
> > For optimization:
> > mmp has a kthread kmmpd-<dev>, which is only created in
non-clustered
> > mode.
> > 
> > We set a rule:
> > If last mount didn't do unmount, (eg: crash), the next mount MUST
be
> > same mount type.
> > 
> > At last, this commit also fix commit c80af0c250c8 ("Revert
"ocfs2:
> > mount shared volume without ha stack") mentioned issue.
> 
> I suggest we re-split this series (especially patch 3 and 4), but not
> revive a buggy commit first and then another commit fixing it BTW.
> 
No problem. I remembered this fixing style, and won't make this kind of
mistake again.

Do we need to wait for Mark's further comment?
It looks Mark didn't like non-clustered mount at his first reply, but he
showed another idea for non-clustered mount on the second reply. And I
am sure what's his meaning/attitude for non-clustered mount.

Thanks,
Heming