lkcd
[Top] [All Lists]

Re: Non-disruptive dumps - expanding on the steps

To: "Matt D. Robinson" <yakker@xxxxxxxxxxxxxx>
Subject: Re: Non-disruptive dumps - expanding on the steps
From: bsuparna@xxxxxxxxxx
Date: Thu, 19 Jul 2001 19:47:37 +0530
Cc: lkcd@xxxxxxxxxxx
Sender: owner-lkcd@xxxxxxxxxxx
>If you're talking about non-disruptive dumps here, I agree.Otherwise,
>I'm not so certain.  I don't believe you should wait for anything.Stable
>system state when panic() or die_if_kernel() is activated is completely
>ambiguous.  Therefore, you should start acting right away,regardless of
>system state.

Yes, we were talking about non-disruptive dumps in the note. I understand
your concern about panic type situations. That needs more thought.

>If you're using your own I/O driver for dumping, then it eliminates the
>uncertainty associated with disruptive dumps.

Assuming that you are talking only about panic type/disruptive dumps here
(not the non-disruptive case, right ?).
One problem with the specialized i/o driver approach is that it may be hard
to get this support for all kinds of disk i/o / dump h/w (all adapter
types). So, we would need to address the cases where such a raw interface
does not exist for the dump device and have  a fall-back aproach for these
cases (mcore style ?)

Regards
Suparna


  Suparna Bhattacharya
  IBM Software Lab, India
  E-mail : bsuparna@xxxxxxxxxx
  Phone : 91-80-5267117, Extn : 2525



<Prev in Thread] Current Thread [Next in Thread>