Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sun, Sep 14, 2014 at 10:15:25AM +0300, Ivan wrote:
> Hello fellow drbd users
>
> First post on the mailing list - thanks to the drbd devs and
> contributors for this great piece of software. I've been using it
> for years, it's been working flawlessly since then.
>
> I have a production two-node pacemaker cluster (centos6) hosting a
> bunch of virtual machines and I'm doing some tests for a planned
> upgrade to centos7. With the elrepo rpm as well as the latest
> drbd-utils git, I get the following syslog error message after
> "drbdadm up someresourcename":
>
> NAME="$env{DEVICE}" ignored, kernel device nodes can not be renamed;
> please fix it in /usr/lib/udev/rules.d/65-drbd.rules:8
>
> Which effectively prevents /dev/drbd_blah from being created (eg,
> "/dev/drbd_vm-mail-data"). This is easily fixed by symlinking:
>
> -NAME=="", ENV{DEVICE}!="", NAME="$env{DEVICE}"
> +ENV{DEVICE}!="", SYMLINK+="$env{DEVICE}"
That rule was meant to provide a "default" for NAME,
in case NAME was empty. And I can see nothing wrong with that.
But we'll have a look.
> (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.
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>
> 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
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed