Bug 172826

Summary:	Feature: selectable dump filtering
Product:	Red Hat Enterprise Linux 4	Reporter:	Tim Burke <tburke>
Component:	diskdumputils	Assignee:	Akira Imamura <aimamura>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	aimamura, anderson, dzickus, ktokunag, lwang, ntachino
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHEA-2007-0233	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-05-01 22:59:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	176344, 215617

Description Tim Burke 2005-11-10 02:47:34 UTC

In a recent customer meeting the following feature request came up.  I'll do my
best to represent it here.....

The customer is highly interested in diskdump in general.  However, they had
reservations about providing us full dumps for post-mortem diagnosis.  Possible
reasons include:
- bandwidth, upload time, and disk space on our end
- preserve company confidential info in memory?

Consequently, they would like the ability to provide a limited partial crash
dump initially.  Presumably that would provide enough info to diagnose most
issues. However, they recognize that in some cases, a more complete dump may be
needed.  

One approach to doing this would be to initially configure their systems for
partial crash dumps. Then in the event that a more complete dump is required,
they'd have to attempt to reproduce the issue again.  This is what would have to
be done using the capabilities as of U2.

What they would prefer to be able to do is to configure their systems for full
dumps.  Then they would like a utility that could be run after the system has
been rebooted, to take input from the full dump, and output a separate dump file
which is a partial dump.  Basically, filtering of a dump file.  That way, they
can initially send in to support the minimal dump file size, then if its
warranted, they can later provide the full dump.. without having to try to
reproduce the same problem again.

Comment 1 Akira Imamura 2006-02-24 16:14:41 UTC

I need to know further more requirement of the customer so as to compose
this feature. The information I can currently see is not quite enough to
compose it. Please provide me anything you know such as specification. Note
that even if the specification is shown in private comments, I cannot see
anything.

Regards,

Comment 4 Akira Imamura 2006-04-04 13:22:15 UTC

This BZ is just a new feature, so I change severity to "enhancement".

Comment 5 Bob Johnson 2006-04-11 16:19:37 UTC

This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.

Comment 6 Akira Imamura 2006-05-11 20:02:23 UTC

I've been working on this feature since this BZ was opened. But
there was not enough time to work on it because I had a lot of
other patches to do. I need to keep working on it. This feature
should be included in U5.

Regards,
Akira

Comment 7 Dave Anderson 2006-05-11 20:55:36 UTC

Interesting...

This kind of feature is essentially what NEC is doing for
the RHEL5 kdump filtering (partial dump) feature.  The difference
from what's being requested here would be:

(1) the NEC utility will start with a full /proc/vmcore while
    running in the kdump kernel environment, and from that file it
    creates a filtered/partial vmcore.
 
(2) if the original vmcore on the customer system was a compressed
    diskdump already, i.e., instead of an ELF vmcore, then NEC's utility
    would not work -- because NEC is translating from an ELF vmcore to a 
    filtered dumpfile only.

(3) the original kdump ELF vmcore is history as soon as the kdump kernel
    reboots, so both files would have to be saved somewhere.  

So (3) might be considered as a kdump option, i.e., allowing for saving
both the full and partial dump files while running in the kdump environment.
I've added Don's name to the cc: list as a reminder that this might be
a useful kdump option.

Comment 8 Akira Imamura 2006-05-12 18:24:45 UTC

I closed this BZ by mistake. So, I reopen it.

Comment 13 Akira Imamura 2006-12-14 23:32:52 UTC

I worked on this feature, and uploaded the latest diskdumputils SRPM which
includes it onto http://people.redhat.com/aimamura/. The SRPM is a beta. So
please use it for test only.
dumpfilter command works correctly on the system that the following kernel
is installed.
http://people.redhat.com/~jbaron/rhel4/SRPMS.kernel/

Thanks,
Akira

Comment 14 Akira Imamura 2006-12-15 22:48:48 UTC

I've changed the component to diskcheck by mistake. So I correct it.

Regards,
Akira

Comment 15 Dave Anderson 2007-01-08 20:10:02 UTC

Upstream diskdumputils version 1.3.25 containing the feature
has been checked into RHEL-4 CVS, version 1.3.25-1:

  /mnt/redhat/brewroot/packages/diskdumputils/1.3.25/1

Comment 19 Red Hat Bugzilla 2007-05-01 22:59:11 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2007-0233.html