[Ocfs2-tools-devel] [PATCH 03/39] umount.ocfs2: Add umount.ocfs2 to pair mount.ocfs2

Joel Becker Joel.Becker at oracle.com
Thu May 15 19:52:54 PDT 2008


On Thu, May 15, 2008 at 05:21:42PM -0700, Joel Becker wrote:
> On Thu, May 15, 2008 at 04:11:01PM -0700, Sunil Mushran wrote:
> > Fair enough. But I want to hold off on my signoff till we don't resolve
> > the bind mounts v heartbeat issue.
> >
> > ocfs2-tools-devel subscribers:
> > The issue is that umount.ocfs2 is called for all umounts, the first of
> > which will result in a stop hearbeat in the new scheme, even if there
> > are active bind mounts.
> >
> > Joel will discuss this with Al Viro.
> 
> 	More with Mark - I'll talk with Al if and when we can't do this
> inside our own code.

	And we have an answer.  umount.<fstype> is a useless program -
it can't always be called on all mountpoints.  In fact, it is impossible
to keep track of mountpoints from userspace -- consider a mount --rbind
that trips over an ocfs2 submount.
	So, given that we can't rely on umount.ocfs2, we have to have
something that disconnects the cluster stack at ->put_super().  After
some discussion, Mark and I agreed we should go back to ocfs2_hb_ctl.
	This returns to our problem with refcounting multiple mounts of
the same filesystem.  That problem came from a refcounting scheme that
expected global heartbeat.  We're not doing global heartbeat anymore, so
we can drop that.
	So, what is the plan?  We want to merge the stack-user code as
soon as possible, but we don't want to break o2cb.  So we came up with a
staged approach.

1) Before merging, we re-enable ocfs2_hb_ctl for o2cb, but otherwise
   leave the tools code unchanged.
 A) Change the kernel to call_usermodehelper() in stackglue.c.  It will
    call the helper for both o2cb and userspace cluster stacks.  This
    leaves the smallest number of kernel revisions that *require*
    umount.ocfs2 for stack-user.
 B) Change ocfs2_hb_ctl to exit immediately if the stack is not o2cb.
    Thus we can always call it safely from put_super().
 C) Change umount.ocfs2 to exit right after calling umount(2) if the
    stack is o2cb.  Thus it will clean up userspace clusters but not
    o2cb clusters; those are handled by ocfs2_hb_ctl.

2) Merge the code.  This allows users to use stack-user with merely the
bind-mount caveat and does not affect o2cb users.

3) Fix the mount refcount problem.  This is where mounting one device in
   two places had a refcounting error for o2cb.
 A) Add an extra semaphore as a flag - 0 is no mounts, 1 is mounted.
 B) When libo2cb is asked to start heartbeat, it will increment the
    refcount only once for all mounts of a device.  The first mount of a
    device will increment the refcount as well as set the 'mounted'
    semaphore.  Subsequent mounts of the same device will see the
    'mounted' semaphore and do nothing.  When a tool (tunefs, fsck)
    wants to start heartbeat, the refcount is always incremented.
 C) When libo2cb is asked to stop heartbeat from a umount, it knows that
    this comes from put_super().  There is only one final stop call for
    all mounts.  It clears the 'mounted' semaphore and drops the
    refcount.  When a tool wants to stop heartbeat, the refcount is
    always decremented.  If the refcount hits 0, heartbeat is stopped.

4) Move userspace stacks to ocfs2_hb_ctl.
 A) Change the 'service' for mounts to 'mount' and unmounts to 'umount'
    instead of the mountpoint.
 B) Change mountpoint tracking in ocfs2_controld to track services -
    this is analogous to tools vs mounts in the heartbeat refcount.
 C) Verify that ocfs2_hb_ctl can connect to the daemon and call an
    unmount.  This should pretty much work already.
 D) Remove umount.ocfs2
 E) Have ocfs2_hb_ctl work for all stacks.

Joel

-- 

"Same dancers in the same old shoes.
 You get too careful with the steps you choose.
 You don't care about winning but you don't want to lose
 After the thrill is gone."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127



More information about the Ocfs2-tools-devel mailing list