Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Mar 19, 2009 at 03:30:00PM -0700, tracymtaylor wrote: > > Under 8.2.6 we have used a script to switch from one mirror host to another > creating a new drbd.conf file under a different name, using it, and if all > of the other parts of the procedure go well, making it the permanent > drbd.conf file. (Otherwise we roll back using the old one). We’re switching > while disconnected and change resource names that refer to our /dev/drbd > devices, nodenames, ipaddresses. The underlying /dev/sda partitions and > meta data partitions always continue to map to the same drbd devices. > > We’ve changed to 8.2.7 and now drbdadm is giving us a warning like: > > Warning: resource monoblock_1 > last used config file: /var/opt/foo/etc/drbd.conf.tmp > current config file: /etc/drbd.conf > > Do you want to proceed and register the current config file? > *** confirmation forced via --force option *** > > My question is, have we been in danger all along? What exactly is this > trying to protect me from? a number of state transitions in drbd (kernel) trigger a user space callback, via drbdadm. basically it spawns a "drbdadm <handler> minor-#", and puts some things in the environment of that command. drbdadm then parses the config file, and calls the appropriate command from there. now, if it does not find any resource definition in the default config file for that minor number, drbdadm will terminate with some stupid exit code, complaining that the corresponding resource was not found. this may prevent resync from happening, as a failed pre-sync-target handler causes drbd to drop the connection. if it _does_ find a resource section in the default config file that matches this minor, handlers and configuration of that resource section would be used for this drbdadm callback run, instead of the settings in the alternate config file used to actually configure it. depending on usage, that might mean that it marks the wrong meta data outdated, or does other more or less harmful, but at least "unexpected" things. it may even do "the right thing" accidentally, if default drbd.conf and alternate drbd.conf are similar enough. the other caveat with using alternate config files is, that you have to give the correct "-c tmp.conf" with every invokation, otherwise it would use the default drbd.conf. drbdadm -c tmp.conf attach that; drbdadm adjust that; is most likely not what you want. in 8.2.7 we introduced symlinks in /var/run/drbd, that point to the last config file used to configure this resource. these symlinks are maintained by drbdadm. now drbdadm is able to find the configfile again when called from kernel, and to warn for the usage example given above. that warning is what you quoted above. depending on how you actually use "-c tmp.conf" in your deployment, yes, you might have been in danger all along. -- : Lars Ellenberg : LINBIT HA-Solutions GmbH : 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