Re: [PATCH 2/2] votequorum: implement qdevice name registration barrier with cluster locking

["Fabio M. Di Nitto" <fdinitto@xxxxxxxxxx>]

On 02/25/2012 05:26 PM, Steven Dake wrote:

>> diff --git a/exec/votequorum.c b/exec/votequorum.c
>> index 3765a69..a5c9883 100644
>> --- a/exec/votequorum.c
>> +++ b/exec/votequorum.c
>> @@ -64,10 +64,12 @@ static struct corosync_api_v1 *corosync_api;
>>  
>>  #define DEFAULT_QDEVICE_TIMEOUT 10000
>>  
>> +static char qdevice_name[VOTEQUORUM_MAX_QDEVICE_NAME_LEN];
> 
> Is this a filename?  IF so, PATH_MAX would be better choice for define

No, it's just a name to identify the quorum device.

Historically qdiskd used the path to disk device (that was rarely over
255 bytes even when using disk-uuid and alike).

If I'll ever port qdiskd to the new world, I'll probably add a udev rule
+ helper to identify the device label and use /dev/by-label/ or
something, that would be always shorter than 255, or simply register the
label there. A full path is overkilling anyway since mkqdisk -L is a lot
more detailed about the device information. In the current world, there
are at least 5 paths for each real device (by-uuid, by-id, by-path, dm-*
and the real device sdXY...) so representing them all in there is just
overkilling.

A quorum_pingd could write the target IP for example..

Fabio
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss