[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 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,oopses_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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]