mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Akiyama, Nobuyuki" <akiyama.nobuyuk@jp.fujitsu.com>
Cc: fastboot@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] [PATCH] kdump: add a missing notifier before crashing
Date: Fri, 16 Jun 2006 10:37:05 -0600	[thread overview]
Message-ID: <m1odwtnjke.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060616211555.1e5c4af0.akiyama.nobuyuk@jp.fujitsu.com> (Nobuyuki Akiyama's message of "Fri, 16 Jun 2006 21:15:55 +0900")

"Akiyama, Nobuyuki" <akiyama.nobuyuk@jp.fujitsu.com> writes:

>> I am sympathetic but this interface seems to set expectations that
>> we can the impossible, and it still appears unnecessary to me.
>
> As I mentioned many times, this notifier is very effective in the
> clustering system. Actually the Red Hat's kernel has a notifier
> at the same point like this patch.

Ok.  Then maybe someone at redhat can help you convince me.
Why is the appropriate redhat person not sending this patch
upstream?

> I know a real system that failover
> of DB server is immediately done by using this notifier.

Agreed the code can be used.  I'm asking if this makes sense,
and if it is reliable, and if it typically meets the deadline.

> It takes much cost to keep consistency of transaction processing
> on DB system. Therefore, to shorten down time, it is very important
> to immediately know that the system dies. In a mission critical system,
> millisecond order or less is demanded.

I'm not arguing against your requirements.  I'm arguing that I don't
see how this allows you to meet your requirements when you can't
with the current kernel code.

If you are an existing user of a panic notifier I can see how
this removes the need to convert code, because the technique
does not change.  Unfortunately this is the only advantage I see
to this patch.

> The processing of the notifier is to make a SCSI adaptor power off to
> stop writing in the shared disk completely and then notify to standby-node.

The kernel has called panic no new SCSI operations were execute.
I'm not saying don't notify your standby-node

> But as you think, it is sure not to necessarily become this scenario.
> For instance, if the kernel hangs, the failure can be detected only
> by heart-beat. In this case the detection time becomes longer.
>
> Anyway this notifier is very effective and important in the actual world. 
> Another example is as follows:

Please walk me through a real world kernel failure, and show me how
your millisecond requirement is met.

In the example please answer:
- What causes the kernel to call panic?
- From the real failure to the kernel calling panic how long
  does it take?
- What actions does the notifier take to tell the other kernel
  it is dead.
- Why do we think the kernel taking that action will be reliable?
- From the point where we call panic() how long does it take until
  the kdump kernel is active?


> Anyway this notifier is very effective and important in the actual world. 
> Another example is as follows:
> 
> http://lists.osdl.org/pipermail/fastboot/2006-June/003028.html

Hmm.  So if I read this correctly all you need to execute is a single
outb instruction?

This is part one of my biggest confusions what do you need to
do to notify the other node that you have died?

Eric

  reply	other threads:[~2006-06-16 16:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-15 11:16 Akiyama, Nobuyuki
2006-06-16  6:28 ` [Fastboot] " Eric W. Biederman
2006-06-16 12:15   ` Akiyama, Nobuyuki
2006-06-16 16:37     ` Eric W. Biederman [this message]
2006-06-19  7:30       ` Akiyama, Nobuyuki
2006-06-19 12:47         ` Eric W. Biederman
2006-06-19 13:28           ` Preben Traerup
2006-06-19 16:49             ` Eric W. Biederman
2006-06-19 17:07               ` Vivek Goyal
2006-06-19 17:50                 ` Eric W. Biederman
2006-06-19 18:19                   ` Vivek Goyal
2006-06-19 18:45                     ` Eric W. Biederman
2006-06-20  3:46                   ` Akiyama, Nobuyuki
2006-06-20  3:39             ` Akiyama, Nobuyuki
2006-07-04 12:33 Akiyama, Nobuyuki
2006-07-05 16:14 ` [Fastboot] " Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1odwtnjke.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akiyama.nobuyuk@jp.fujitsu.com \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®