Topic
  • 2 replies
  • Latest Post - ‏2012-10-26T17:11:07Z by SystemAdmin
HajoEhlers
HajoEhlers
253 Posts

Pinned topic callback ( order of execution )

‏2012-10-23T09:43:04Z |
Hi
the man page of mmaddcall gives a short explaination of the available callbacks but not in which order they are executed or if they are executed in all cases or only in certain circumstances.
( A matrix like

Callback    normal_start normal_shutdown panic preSTart    x ... unmount                  x                x
whould be nice.

For LOCAL EVENTS i assume the following order: ( Questions are directly attached to the callack ) and i assume that they are executed during GPFS startup or GPFS recovery ( GPFS daemon restarts itself or GPFS panic )

preStartup
preMount
mount
startup

preShutdown ? Only during failure or also during normal shutdown invoked since the man page mentioned only "failure"?
preUnmount
unmount
shutdown
GLOBAL EVENTS
nodeLeave ? Is the evnet triggered for each node leaving the cluster or is it a list of leaving nodes

Another question:
In can not find any documenation about the mmfsup and mmfsdown GPFS events within the documenation.

tia
Hajo
Updated on 2012-10-26T17:11:07Z at 2012-10-26T17:11:07Z by SystemAdmin
  • esj
    esj
    104 Posts

    Re: callback ( order of execution )

    ‏2012-10-26T05:11:47Z  
    If you have an event called XXX and an event called preXXX, then you can assume
    that preXXX will be called before XXX.

    The very first event that you can get is prestartup. The very last event is shutdown.
    The rest of the events can come pretty much in any order depending on what happens
    in the system at any one moment.

    The premount and mount events will normally come after the startup event. This includes
    the mounting of file systems that have -A yes (mount at daemon startup) in effect.
    But if the daemon recycled and there are still active mount points in the VFS layer,
    those file systems will be internally remounted and the corresponding mount events
    will be triggered before the startup event.

    The preshutdown and shutdown will always be called when the daemon goes down.

    The %reason variable can be used to help figure out what caused the event to be triggered.

    nodeJoin and nodeLeave can be called for a number of nodes. Note that the %eventNode
    variable can be a comma-separated list of nodes.

    mmfsup and mmfsdown are functionally equivalent to startup and shutdown.
    preStartup is functionally equivalent to the old gpfsready user exit.
    If you are currently using any of mmfsup, mmfsdown or gpfsready, consider
    phasing them outs and replacing them with the new style callbacks.

    Eugene
  • SystemAdmin
    SystemAdmin
    2092 Posts

    Re: callback ( order of execution )

    ‏2012-10-26T17:11:07Z  
    • esj
    • ‏2012-10-26T05:11:47Z
    If you have an event called XXX and an event called preXXX, then you can assume
    that preXXX will be called before XXX.

    The very first event that you can get is prestartup. The very last event is shutdown.
    The rest of the events can come pretty much in any order depending on what happens
    in the system at any one moment.

    The premount and mount events will normally come after the startup event. This includes
    the mounting of file systems that have -A yes (mount at daemon startup) in effect.
    But if the daemon recycled and there are still active mount points in the VFS layer,
    those file systems will be internally remounted and the corresponding mount events
    will be triggered before the startup event.

    The preshutdown and shutdown will always be called when the daemon goes down.

    The %reason variable can be used to help figure out what caused the event to be triggered.

    nodeJoin and nodeLeave can be called for a number of nodes. Note that the %eventNode
    variable can be a comma-separated list of nodes.

    mmfsup and mmfsdown are functionally equivalent to startup and shutdown.
    preStartup is functionally equivalent to the old gpfsready user exit.
    If you are currently using any of mmfsup, mmfsdown or gpfsready, consider
    phasing them outs and replacing them with the new style callbacks.

    Eugene
    'mmshutdown -a' generates an indeterministic set of events. In particular, some nodes will receive a quorumLoss event, depending on whether or not they 'shutdown' before the cluster loses quorum.