[Linux-cluster] GFS volume already mounted or /mnt busy?

[bigendian+gfs at gmail.com]

Thanks Robert.  I'm sorry, but I put you a little off track do to a typo.  I
meant to say that gfs_fsck completes without errors.  I've run it twice.
The first pass did make a number of corrections, but completed through stage
5.  A subsequent gfs_fsck completed with no errors.

The "gfs_tool sb /dev/etherd/e1.1 proto" does return lock_dlm as the lock
protocol.

Which package contains the gfs_edit tool?

Thanks again,
Tom

On 12/22/06, Robert Peterson <rpeterso at redhat.com> wrote:
>
> Robert Peterson wrote:
> > bigendian+gfs at gmail.com wrote:
> >> Hello Robert,
> >>
> >> The other node was previously rebuilt for another temporary purpose
> >> and isn't attached to the SAN.  The only thing I can think of that
> >> might have been out of the ordinary is that I may have pulled the
> >> power on the machine while it was shutting down during some file
> >> system operation.  The disk array itself never lost power.
> >>
> >> I do have another two machines configured in a different cluster
> >> attached to the SAN.  CLVM on machines in the other cluster does show
> >> the volume that I am having trouble with though those machines do not
> >> mount the device.  Could this have caused the trouble?
> >> More importantly, is there a way to repair the volume?  I can see the
> >> device with fdisk -l and gfs_fsck completes with errors, but mount
> >> attempts always fail with the "mount: /dev/etherd/e1.1 already
> >> mounted or /gfs busy" error.  I don't know how to debug this at a
> >> lower level to understand why this error is happening.  Any pointers?
> Hi Tom,
>
> Another thought.  If someone went in there without your knowledge and
> did something bad
> like mkfs.ext3 /dev/etherd/e1.1 (or mkfs.vfat, reiserfs, xfs, jffs2, or
> whatever)
> or worse, the underlying device, it would also manifest itself as the
> problem you're seeing.
>
> If it were me, I'd do: "gfs_edit /dev/etherd/e1.1" and have a look at
> block 0.
> The gfs_edit tool starts you out on block 0x10 (the superblock), so
> you'll have to do 16
> "b" keystrokes or else arrow up and change block number to 0 and press
> enter.  The first
> 16 blocks of the file system should be all zeros, 0x00.  If they look
> like a bunch of numbers
> instead, then maybe somebody overwrote your file system.  BTW, gfs_edit
> is a dangerous
> tool so don't change anything with it.
>
> Regards,
>
> Bob Peterson
> Red Hat Cluster Suite
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20061222/61e7b172/attachment.htm>