<div dir="ltr">Hi Bob. Thanks for the reply once again.<br><br>Yes lvm_test2 is the mount point - but in my explanation of the problem I used /lvm2 for clarification. I haven't rebooted the node yet, and now that I try, it hangs. I will have to bring crash cart to the data center and check it out sometimes today. That is why I haven't been able to check dmesg for potential DLM problems.<br>
<br>I am rebooting the cluster (not desired outcome but have to bring it to a stable state), and will post the dmesg afterwards.<br><br><div class="gmail_quote">On Thu, Sep 25, 2008 at 5:49 PM, Bob Peterson <span dir="ltr"><<a href="mailto:rpeterso@redhat.com">rpeterso@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">----- "Alan A" <<a href="mailto:alan.zg@gmail.com">alan.zg@gmail.com</a>> wrote:<br>
</div><div class="Ih2E3d">| Hello Bob, and thanks for the reply.<br>
|<br>
</div><div class="Ih2E3d">| gfs-utils-0.1.17-1.el5<br>
</div>(snip)<br>
<div class="Ih2E3d">| Let me know if you need any additional information. What would be<br>
| suggested<br>
| path to recovery. I tried gfs_fsck but I get:<br>
| Initializing fsck<br>
| Unable to open device: /lvm_test2<br>
<br>
</div>Hi Alan,<br>
<br>
The good news is that gfs-utils-0.1.17-1.el5 has the latest fixes for<br>
the gfs_grow program (as of the time of this post), so in theory<br>
it should not have caused any corruption.<br>
<br>
The fix to gfs_fsck for repairing that kind of corruption does not appear<br>
until gfs-utils-0.1.18-1.el5, but in theory, the gfs_grow should not<br>
corrupt the file system, so you shouldn't need the repair code.<br>
<br>
Are you sure you're specifying the right device? I would expect<br>
something more like /dev/test2_vg/lvm_test2 rather than just /lvm_test2.<br>
So that doesn't look like you specified a valid device.<br>
<br>
If you did specify the correct device, and I'm just not understanding,<br>
it looks to me like gfs_fsck can't open the SCSI device. That likely<br>
means the device is locked up, perhaps by SCSI fencing or something,<br>
which is why I suggest looking in "dmesg" for kernel problems.<br>
<br>
If you got a message in dmesg that looks something like this:<br>
<br>
lock_dlm: yourfs: gdlm_lock 2,17 err=-16 cur=3 req=5 lkf=3044 flags=80<br>
<br>
then you might be a victim of this bug:<br>
<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=438268" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=438268</a><br>
<br>
(I apologise in advance if you can't view this record; that's out<br>
of my control). There is a fix for that bug in the kernel's dlm code<br>
that's scheduled to go in to 5.3, but it has only been released in<br>
the source code so far.<br>
<br>
I don't know much about SCSI fencing or SCSI reservations, but<br>
maybe booting the whole cluster will free things up.<br>
<div><div></div><div class="Wj3C7c"><br>
Regards,<br>
<br>
Bob Peterson<br>
Red Hat Clustering & GFS<br>
<br>
--<br>
Linux-cluster mailing list<br>
<a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alan A.<br>
</div>