Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 09/17/2014 12:09 PM, Lars Ellenberg wrote:
> On Sun, Sep 14, 2014 at 10:15:25AM +0300, Ivan wrote:
>> (side question: I read that the by-res/ naming is 8.x legacy. Will
>> the 9x series drop that and use exclusively /dev/drbd[0-9]+ and
>> /dev/drbd_{resourcename} devices ?)
>
> I guess you are referring to the comment in the rules file
> "legacy rules for 8.3 and 8.4".
> That's just legacy *rules* in the sense that
> those utils did not yet reliably export the SYMLINKS variable.
>
> Much more likely the other way around: the "drbd_{resourcename}" stuff
> would be dropped, and you should use the /by-res/ naming.
Thanks for the clarification.
I indeed understood the udev rules in the opposite way ; I see from the
rc release that you've updated the rules files with a comment that makes
it clearer.
> 8.4 supports volumes, that is multiple minors per resource,
> so it becomes /by-res/<resource>/<volume-number>
> (note: volume-number is per resource, as defined in drbd.conf,
> and usually not the same as minor-number).
>
> an 8.3 /by-res/<resource> would typically become
> 8.4 /by-res/<resource>/<volume>
I'm already using volumes, but IMO when carefully naming devices,
/dev/drbd_blah has the advantage of exposing a meaningful name while
by-res/xyz/{0,1,...} doesn't. It's for instance less error prone when
defining multiple disks in a virtual machine (where a digit swap could
result in data loss); eg.:
disk1=/dev/drbd/by-res/vm-mail/0
disk2=/dev/drbd/by-res/vm-mail/1
...
vs.
disk1=/dev/drbd_vmmail-root
disk2=/dev/drbd_vmmail-data
...
I guess that a custom udev rule could symlink
/dev/drbd/by-res/vmmail/somelabel to /dev/drbd/by-res/vmmail/0, but it'd
be nice if drbd did that automatically. "somelabel" could be defined in
the resource config file.
It's really not important though, with the upcoming 9x I'm sure you have
plenty of other things to think about :)
>> Which leads me to a related issue with pacemaker: if I use
>> /dev/drbd_blah
>
> Better: Don't.
> We should never have introduced that.
>
>> when defining resources without fixing the udv rules,
>> the drbd ocf resource file loops forever in my_udevsettle(). That's
>> normal since /dev/drbd_blah is not created, but there's no error
>> message in pacemaker log files so it took me a while to figure what
>> the problem was until I saw that the drbd ocf was stuck with sleep 1
>> processes (note to others: look at the output of ps axf and any
>> processes stuck under lrmd).
>>
>> Isn't it possible to have more meaningful error reporting (or a
>> documented error code, but I don't see any in the OCF_ ones) ? Is it
>> OK to set a timeout in the ocf filer rather than relying on
>> pacemaker's defined timeout ? It would save some a lot of debugging
>> time for the 8x->9x transition.
>>
>> cheers
>> ivan
>