Masashige Kotani wrote:
>
> > "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)
>
> Do you mean as follows, Matt?
>
> "Dump methods" means how to use devices configured for dump device to
> save memory dump, and each of them should be pluggable?
> (single device as standard, concatenating devices as single dump device,
> mirroring devices for redundancy ...)
I guess what I mean is more like the following:
Assume there are multiple dump devices in /dev:
/dev/dump/dump0 (major 227, minor 0)
/dev/dump/dump1 (major 227, minor 1)
/dev/dump/dumpN (major 227, minor N)
All of these are configurable via open() and ioctl(), and each can have
their own individual dumping strategies based on configuration. For
example, let's say /dev/dump/dump0 is configured with dump method A,
RLE compression, and is non-disruptive. /dev/dump/dump1 is configured
with dump method B (let's say it's Mission Critical Linux's MCLX crash
utility), no compression, and is disruptive. Etc., etc., etc.
Each can be triggered via dprobes, or a system crash, SysRQ, or
any other mechanism.
As far as dump methods are concerned, we'd take dump_execute() and
turn it into a dump method launch. So, if it gets called, it walks
through the dump methods and determines which one to execute based
on what is configured. The final step is to make each dump method
a module rather than something statically built into the kernel.
This eliminates the need for massive dump overhead in the kernel
code -- each module can do its own thing with respect to method,
compression, etc. It can even determine whether it wants the kernel
to go silent or not (like what IBM's trying to do).
So, 'lsmod' might show:
[root@watereye /root]# lsmod
Module Size Used by
dump_rle 1104 0 (unused)
dump_gzip 8906 0 (unused)
dump_method_lkcd 89712 0 (unused)
dump_method_mclx 22319 0 (unused)
dump 17248 0 [dump_rle]
So a dump method module, when loaded, can then be used by a dump
device for crashing. The only complexity is writing a nice user
utility that configures how crashing is performed, and loads all
the right modules for you (or sets them up to load).
Does this make any sense at all? :) What do you think?
Anyone have any thoughts on this?
--Matt
> Each "dump devices" should be independently configurable about type of
> compression and dump method ?
>
> --Masashige
>
> > 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
|