Hi, On Tue, 2010-08-17 at 08:15 -0400, rhurst@xxxxxxxxxxxxxxxxx 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. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
