Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi
It could be, I guess, because the drive is busy re-syncing, so
operations are taking longer than GFS likes. It's just a simple bench
test setup with single drives, just so I can stabilise the setup before
using real servers for deployment.
I'd have thought the volume would be clean for the mount as it's GFS2,
the other node still has it mounted okay, or am I missing something?
Maybe I just need to leave for a long time ? Or I wonder because you
have "noquota" in your mount options and the oops is in gfs2_quotad
modules you never see it?
I have a number of services, but a representative one from my
cluster.conf is below. I think I'm doing pretty much what you are
doing.
Though I don't see why you are adding the /etc/init.d/gfs2 service to
the cluster.conf, as all that does is mount gfs2 filesystems from fstab
(and you say these are noauto in there), so will this do anything? The
inner "clusterfs" directives will handle the actual mount?
Thanks again
Colin
<resources>
<clusterfs device="/dev/CluVG0/CluVG0-projects" force_umount="0"
fstype="gfs2" mountpoint="/mnt/projects" name="projects" options="acl"/>
<nfsexport name="tcluexports"/>
<nfsclient name="NFSprojectsclnt" options="rw"
target="192.168.1.0/24"/>
<ip address="192.168.1.60" monitor_link="1"/>
</resources>
<service autostart="1" domain="clusterA" name="NFSprojects">
<ip ref="192.168.1.60"/>
<clusterfs fstype="gfs" ref="projects">
<nfsexport ref="tcluexports">
<nfsclient name=" " ref="NFSprojectsclnt"/>
</nfsexport>
</clusterfs>
</service>
On Fri, 2010-10-22 at 18:19 +0100, J. Ryan Earl wrote:
> On Wed, Oct 20, 2010 at 10:41 AM, Colin Simpson
> <Colin.Simpson at iongeo.com> wrote:
> Oct 20 15:47:44 testnode2 kernel: "echo 0
> > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message.
>
>
> That timeout is a warning from khungtaskd, it's not actually an
> error. Just let's you know a kernel-thread was blocked for
> 120-seconds, but that may be OK, some tasks can take awhile to
> complete. I've only seen those when I do software raid resyncs. If
> you didn't unmount the volume cleaning, it could be doing some
> recovery which is why you get the long-running thread.
>
>
> I don't know what's going on with your setup. I've never had that
> issue, it could be something else in your configuration, corrupt data,
> etc. It's not clear this is a DRBD issue, it could be cluster or GFS
> configuration.
>
>
> I have rgmanager control all my GFS2 resources, example cluster.conf
> bits:
>
>
> <resources>
> <script file="/etc/init.d/httpd"
> name="httpd"/>
> <script file="/etc/init.d/gfs2" name="GFS2"/>
> <clusterfs device="/dev/ClusteredVG/gfs-vol"
> force_unmount="0" fsid="12345" fstype="gfs2" mountpoint="/content"
> name="/content" options="rw,noatime,nodiratime,noquota"
> self_fence="0"/>
> </resources>
> <service autostart="1" domain="failover1"
> name="content" recovery="restart">
> <script ref="GFS2">
> <clusterfs fstype="gfs"
> ref="/content">
> <script ref="httpd"/>
> </clusterfs>
> </script>
> </service>
>
>
> The file system is also in fstab with "noauto" set for clean
> dismounting when rgmanager is shutdown. It could be that you're not
> cleanly shutting down and recovering on startup for >120 seconds.
>
>
> -JR
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.