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 <div> On 12/22/06, Robert Peterson <<a href="mailto:rpeterso@redhat.com">rpeterso@redhat.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Robert Peterson wrote: > <a href="mailto:bigendian+gfs@gmail.com">bigendian+gfs@gmail.com</a> 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 <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster </a> </blockquote></div>