Doug Ledford wrote:
>
> ...
>
> If told to hold a reservation, then resend your reservation request once every
> 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a
> deal as requesting a reservation every 2 seconds might sound). The first time
> the reservation is refused, consider the reservation stolen by another machine
> and exit (or optionally, reboot).
Umm. Reboot? What do you think this is? Windoze?
Really, You can NOT do clustering well if you don't have a consistent locking
mechanism. The use of a hardware locking method like 'reservation' may be a
good way to avoid race conditions, but it should be backed up by the
appropriate exchange of messages to make sure everybody has the same view of
the system. For example, you might use it like this:
1. Examine the lock list for conflicts. If a conflict is found, the lock
request fails.
2. Reserve the device with the lock on it. If the reservation fails, delay
a short amount of time and return to 1.
3. Update the lock list for the device.
4. When the list update is complete, release the reservation.
In other words, the reservation acts as a spin-lock to make sure updates
occur atomically.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
