[Linux-cluster] GFS nolock mount on top of existing GFS2 shared mount -- won't umount

[rhurst at bidmc.harvard.edu]

Thanks for the quick concise reply, Steven!  I got a RH Support ticket open on this -- any chance the umount.gfs2 binary could be updated (or built from newer source on RHEL 5.5) to safely allow this to un-mount?  Or this have more software dependencies than that?

Unfortunately for us, it is on a production server; but fortunately, it is something that could wait until a future maintenance window to address.

-----Original Message-----
From: linux-cluster-bounces at redhat.com [mailto:linux-cluster-bounces at redhat.com] On Behalf Of Steven Whitehouse
Sent: Tuesday, August 17, 2010 9:01 AM
To: linux clustering
Subject: Re: [Linux-cluster] GFS nolock mount on top of existing GFS2 shared mount -- won't umount

Hi,

On Tue, 2010-08-17 at 08:15 -0400, rhurst at bidmc.harvard.edu wrote:
> I have a new RHEL 5.5 cluster running and created a new GFS2 filesystem to rsync the old filesystem over (leaving the original intact in case we had to do a fail-back for whatever reason).
> 
> I made a pilot error by pasting the GFS local mount command on the wrong ssh session window, resulting in:
> 
> /dev/mapper/VGCCC-lvolshare55
>               gfs2    6.5G   34M  6.5G   1% /cluster/share
> /dev/mapper/VGCCC-lvolshare47
>                gfs    6.5G   34M  6.5G   1% /cluster/share
> 
> No worries, I'll just umount it and do the mount on the correct sesssion.  ACK!!  The umount fails:
> 
> $ umount /cluster/share
> /sbin/umount.gfs: /cluster/share is not a gfs filesystem
> /sbin/umount.gfs2: /cluster/share is not a gfs2 filesystem
> /sbin/umount.gfs: /cluster/share is not a gfs filesystem
> 
> >From /proc/mounts:
> 
> /dev/mapper/VGCCC-lvolshare55 /cluster/share gfs2 
> rw,noatime,hostdata=jid=1:id=131078:first=0 0 0
> 
> /dev/mapper/VGCCC-lvolshare47 /cluster/share gfs 
> rw,noatime,nodiratime,lockproto=lock_nolock,localflocks,localcaching,o
> opses_ok 0 0
> 
> Is this a "bug" or is there another way to force this umount?
> 
It is really a "feature" and one that is gone in more recent versions of
GFS2 (but not in RHEL5 unfortunately). It is down to the umount helper which can't (in this case) work out which is the correct fs for this mount point.

It is more or less the same issue as when GFS/GFS2 filesystems are bind mounted. In that case the original mount has to persist until all he bind mounts have gone, otherwise something similar occurs. Again this is fixed in more recent versions of GFS2,

Steve.


--
Linux-cluster mailing list
Linux-cluster at redhat.com
https://www.redhat.com/mailman/listinfo/linux-cluster