This DB2 APAR has been created to reference an RSCT APAR deemed
critical to DB2 pureScale operations.
RSCT APAR IV68484
http://www-01.ibm.com/support/docview.wss?uid=isg1IV68484
There were 2 fundamental issues with TB_BREAK , RSCT APAR
IV68484
(http://www-01.ibm.com/support/docview.wss?uid=isg1IV68484) is
supposed to resolve on Linux :
1. Return RC=0 when both parent map + all slave paths does not
hold any reservations .. Without the fix, any PR OUT RELEASE
sys-call will return -1 if there are no existing reserves from
that path, which is then incorrectly interpreted by
IBM.TieBreaker class as a failure and exit with RC=104.
2. Re-discover the path map right before any PR OUT service
action is issued. ... Without the fix, the path map (list of
slave-paths under the parent DM device) is only discovered right
at the start of tb_break run-time. This fix is supposed to
handle cases where there is brief a path/controller failure
which cause Linux kernel to remove-and-reinstantiate the path(s)
potentially causing DM device path map changes (i.e /dev/sdd
under dm-5 can be become /dev/sdz for example) during the
run-time of tb_break ..
The net affect from a pureScale customer scenario is that during
DB2 instance creation, the validation of the RSCT tie breaker
disk could fail resulting in no tie breaker. A second issue, and
of much higher concern, during runtime of DB2 pureScale if a
cluster failure occurs , the reservation of the tie breaker disk
could incorrectly fail potentially resulting in a complete
cluster outage. From a DB2 perspective, this is a HIPER APAR. |
