Control: severity -1 critical
On Sat, Oct 27, 2012 at 12:54:11PM +0200, Philipp Hug wrote:
control: severity -1 important
Josip,
Please don't upgrade the severity of this bug.
The defaults actually prevent further data loss for the majority of drbd
users.
In the normal setup the drbd
In fact, if you had been listening to me from day one, you'd realize
that I'm not even asking you to actually fix this problem.
I'm merely asking you to make the users who aren't using your personally
preferred use case, but are nevertheless using an apparently valid and
supported use case,
On Mon, Oct 29, 2012 at 11:02:39AM +0100, Philipp Hug wrote:
In fact, if you had been listening to me from day one, you'd realize
that I'm not even asking you to actually fix this problem.
I'm merely asking you to make the users who aren't using your personally
preferred use case, but are
Following on Philipp's comment, I went looking for explanation in the old
template config file changes, and found the sysrq calls added with no
obvious explanation here:
http://git.drbd.org/gitweb.cgi?p=drbd-8.3.git;a=commitdiff;h=3b4452d69b4371dbeee5a38f2e248a6360c14c77
But this is still
control: severity -1 important
Josip,
Please don't upgrade the severity of this bug.
The defaults actually prevent further data loss for the majority of drbd users.
In the normal setup the drbd device is the main storage device so the
defaults make sense.
If you have a suggestion for a better
Control: severity -1 critical
On Tue, Oct 23, 2012 at 11:40:43AM -0400, Michael Gilbert wrote:
control: severity -1 important
These defaults are really bad.
I understand your concern, but you should not override the
maintainer's opinion on bug severities. These are upstream defaults I
On Wed, Oct 24, 2012 at 04:29:47PM +0200, Philipp Hug wrote:
It should probably be changed into something like this:
/usr/lib/drbd/notify-emergency-reboot.sh; reboot -f ; sync ; sleep 30;
echo
b /proc/sysrq-trigger;
So, we'd have at least time to sync other file systems and try to shutdown
Hi Josip
Actually, I think a general sync wasn't previously added in that situation
because it might cause a problem with the filesystem on the faulty DRBD
device itself, thereby causing the problem b) you described.
That's why I put in sync then sleep and reboot. But it's just an idea.
Hi everyone,
I agree that the default config is not perfect. It should probably be
changed into something like this:
/usr/lib/drbd/notify-emergency-reboot.sh; reboot -f ; sync ; sleep 30; echo
b /proc/sysrq-trigger;
So, we'd have at least time to sync other file systems and try to shutdown
as
control: severity -1 important
These defaults are really bad.
I had this happen to a machine running DRBD yesterday:
block drbd0: PingAck did not arrive in time.
block drbd0: peer( Secondary - Unknown ) conn( Connected - NetworkFailure )
pdsk( UpToDate - DUnknown )
block drbd0: asender
Dear maintainers,
To be clearer, the reboot is ordered in catastrophic conditions where
data loss will happen on the DRBD device whatever you do, because DRBD
has lost all the usable storage device - this is much like unplugging a
hard drive.
So rebooting is probably a good option when DRBD is
Package: drbd8-utils
Version: 2:8.3.7-1
Severity: normal
/etc/drbd.d/global_common.conf ships with the following lines enabled:
handlers {
pri-on-incon-degr /usr/lib/drbd/notify-pri-on-incon-degr.sh;
/usr/lib/drbd/notify-emergency-reboot.sh; echo b /proc/sysrq-trigger ; reboot
-f;
12 matches
Mail list logo
