[Linux-cluster] GFS2 mounts taking a *very* long time

[Scooter Morris]

Hi Patricio,
     Sure thing -- which logs would help?  I don't think the kernel logs 
would be of much use, and when the dlm_recoverd process is going it 
doesn't log anything, so it's not clear what would be useful, here.

-- scooter

On 01/12/2012 03:40 PM, Patricio A. Bruna wrote:
> Hi scooter,
> Logs would be welcome
>
> ------------------------------------
> Patricio Bruna V.
> IT Linux Ltda.
> www.it-linux.cl <http://www.it-linux.cl>
> Twitter <http://twitter.com/ITLinux>
> Fono : (+56-2) 333 0578
> Móvil: (+56-9) 8899 6618
>
>
>
> ------------------------------------------------------------------------
>
>     Greetings all,
>          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?
>
>     Thanks in advance!
>
>     -- scooter
>
>     --
>     Linux-cluster mailing list
>     Linux-cluster at redhat.com
>     https://www.redhat.com/mailman/listinfo/linux-cluster
>
>
>
>
>
>
> --
> 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/20120112/9557afe7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2893 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20120112/9557afe7/attachment.png>