"Howell, David P" wrote:
>
> We are working on a proposal for redundant dump device support that I plan
> to
> share in the next few weeks; I've got a prototype mostly working that can be
>
> contributed. Let me know how you are approaching this, I'll send details of
> what we are doing here later this week. Sounds like a good opportunity for
> collaboration on this.
>
> Regards,
> Dave Howell
I'm really curious as to the proposal. Sounds like a good idea, the
real question becomes, do you want to chain multiple dump devices with
multiple dump mechanisms?
Here's where I'm going with this. I just finished the code to allow
people to install their own dump compression mechanisms (right now, it'll
be RLE, I have to check in the GZIP compression module, and people can
put in whatever one they want). Do you want to take the next step and
let people have chains of dump mechanisms based on the dump condition?
I realize multiple dump devices is good, but what if you could plug in
your own dump method with it? Then that dump method could query the
available dump devices configured.
So you'd have:
dump methods (one standard, but plug-and-play)
dump devices (requires at least one, multiples allowed, maybe
access lists for methods?)
dump compressions (configurable, usable by some methods)
Would this be the eventual goal? That way, everything is tunable to
their own liking. I figured I'd ask, since if you're going to add in
multiple dump devices, and we've gone to multiple compression types,
you might as well go all the way and add dump methods as well. I
don't know what the rest of the group thinks, but this could be
very useful.
I'd definitely like to get some feedback ... this is all doable,
as long as the dump compression code is in 'lcrash', and the pages
are dumped in a way that we can find the location in memory, this
can work pretty sweet for everyone here.
--Matt
> -----Original Message-----
> From: Masashige Kotani [mailto:m-kotani@xxxxxxxxxxxxxxx]
> Sent: Tuesday, September 04, 2001 4:07 AM
> To: lkcd@xxxxxxxxxxx
> Subject: multiple dump devices
>
> Hello.
>
> Nowadays, I think that the reliability of memory dumping: extracting memory
> as much as possible will be improved.
>
> LKCD uses "only one dump device" in process of memory dump. When it does not
> have enough capacity for memory dump it is not able to be used by some
> reasons, memory dumping is failure.
>
> - When additional memory devices are attached, The capacity of the dump
> device must be increased.
> - To avoid failing memory dump by disk failure, want to add alternative dump
> devices.
> In these cases, I consider that LKCD have to be handle multiple dump devices
> to be useful in different environments.
>
> It can improve the following problems:
> - When it runs short of capacity in one dump device
> Dump data can be divided and written in two or more dump devices.
> - When the dump device is broken
> The LKCD can dump, If it can use at least one among dump devices.
>
> I think that such expansion is indispensable for enterprises use, what do
> you think?
>
> LKCD dumps to multiple dump devices with parallel I/O if possible and time
> of dumping can be decreased. but it is still under examination.
>
> --Masashige
|