New branch 'work' available with the following commits: commit df377940ead9a4d773f16e544847ae47f67caac3 Author: David Teigland teigland@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@redhat.com

commit 6a319f01f303c953938fd04c3cbbdb194c429f75 Author: David Teigland teigland@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@redhat.com

commit c35933fd8a78ae7bbe9158c0390d1a7d1097d7f6 Author: David Teigland teigland@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@redhat.com