2:12 p.m.
New branch 'work' available with the following commits:
commit df377940ead9a4d773f16e544847ae47f67caac3
Author: David Teigland <teigland(a)redhat.com>
Date: Fri Apr 11 14:10:25 2014 -0500
sanlock: shutdown reply
A wait option (-w 1) can be added to sanlock shutdown.
The shutdown command will wait for a result from the
daemon indicating success (exiting), or failure (not
exiting because lockspaces exist).
Signed-off-by: David Teigland <teigland(a)redhat.com>
commit 6a319f01f303c953938fd04c3cbbdb194c429f75
Author: David Teigland <teigland(a)redhat.com>
Date: Thu Apr 10 16:37:22 2014 -0500
sanlock: lockspace callbacks
sanlock_reg_lockspace() returns an fd that the caller should
use in poll(2), and when ready should call sanlock_get_callback()
to read the callback.
Currently, the only callback type is host message. When a host
receives a message from another host, the host message is sent
to the callback fd.
Signed-off-by: David Teigland <teigland(a)redhat.com>
commit c35933fd8a78ae7bbe9158c0390d1a7d1097d7f6
Author: David Teigland <teigland(a)redhat.com>
Date: Tue Jan 14 11:24:52 2014 -0600
sanlock: host_message
A host can send a predefined message code to another host.
The destination host is identified by host_id and generation number.
(These are typically 64 bit values, but the host message system uses
only the lower 32 bits of these values because of space limitations
in the leader record, so host messages should not be used with
host_ids or generation numbers larger than 32 bits.)
The message code is combined with a sequence number used to identify
the message. If the caller does not provide a sequence number (uses 0),
sanlock will generate a sequence number using a local counter, and
return this number to the caller.
The host messages are sent from one host to another via a lockspace that
both hosts are using. The lockspace used to transmit the message may or
may not have any other relation to the message itself. The message data
is included in the leader record for each host's delta lease.
The message code and sequence number are placed in the sending host's
delta lease, and remain there until replaced with another. The caller
must take care to not overwrite one message with another before the first
has been written.
A message is written by the next scheduled delta lease renewal.
When the receiving host next renews its own delta lease, it reads the
delta leases of all other hosts, and sees itself addressed for the
message in the sending host's lease. It then processes the message
from the sending host. It will only process the message if the
sequence number is larger than the previously seen sequence number
from the same host.
When the destination host reads a message from the source host,
it saves the source host_id and the sequence number of the message.
This host_id and seq number are included in the destination host's
next delta lease renewal. This can act as an acknowlegement that
that destination has seen the message. The sending host can monitor
the destination host's delta lease to see if the message has been
received.
The sanlock_read_lockspace_message() function reads the delta lease
of any host and returns the last host message that the given host
has sent, and the last host_id/seq that the given host last received.
Host messages sent around the same time, from the same host, using
the same lockspace may clobber each other and cause earlier messages
to not be written/sent.
Host messages sent around the same time from different hosts to
the same destination host may cause earlier acknowledgement records
from the destination to clobber each other and not be written/sent.
The host_message msg code is a bitfield, so multiple messages can be
combined.
msg code SEQ_DATA means that the sequence number is treated as
opaque caller-specific data. These messages are not acked by the
receiving host.
msg code WD_RESET means that the host receiving the message should
use its watchdog device to reset itself as soon as possible.
The sanlock daemon uses the watchdog to do this. The WD_RESET message
has no effect on any lockspaces or resources that may exist.
Existing lockspaces and resources continue to operate as usual until
the reset. (A watchdog reset due to "standard" lockspace failure could
in fact occur before the watchdog reset caused by the host message.)
Because host messages may not be received if the destination host fails,
or loses storage access, there are no guaranteed times associated with
the delivery, processing or effect of a host message. Guaranteed times
for another host being dead should continue to be based on either acquiring
a resource, or sanlock_get_hosts().
Signed-off-by: David Teigland <teigland(a)redhat.com>