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
