<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi!<div>This patched version of dlm will probably resolve your issue, please try it.</div><div><a href="http://www.bosson.eu/temp/dlm-kmod-1.0-1.el6.src.rpm">http://www.bosson.eu/temp/dlm-kmod-1.0-1.el6.src.rpm</a></div><div>See detailed description in the list earlier ( Subject: <span class="Apple-style-span" style="font-size: 12px; ">[Linux-cluster] [PATCH] dlm: faster dlm recovery )</span></div><div><span class="Apple-style-span" style="font-size: 12px; ">And yes, mounts and umounts with unpatched dlm are proportional to N*N, where N is a number of files.</span></div><div><br></div><div>Sincerely,</div><div>Yevheniy Demchenko</div><div><br><div><div>On Jan 13, 2012, at 00:50 , Scooter Morris wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Greetings all,<br> We've got a 4 node cluster running RHEL 6.2. As part of the cluster, we've got several gfs2 filesystem. We've often noticed that when we reboot a single node in the cluster, the gfs2 mounts take a long time -- eventually getting the 120 second delay messages. When we migrated to 6.2, the default mount script echoed the filesystem being mounted, and we discovered that the long delays were filesystem-dependent. In particular, two filesystems were causing all of the problems, both of which had >1M files in them. We also noticed that dlm_recoverd on one of the other nodes accumulates a lot of time when this is happening. Is this expected? Are there non-ilnear handshaking algorithms between the mounting node and the cluster that are dependent on the number of files?<br><br>Thanks in advance!<br><br>-- scooter<br><br>--<br>Linux-cluster mailing list<br><a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a><br>https://www.redhat.com/mailman/listinfo/linux-cluster<br></div></blockquote></div><br></div></body></html>