With the advent of LZO and snappy compression support, it would be
helpful if it could be readily determined which type of compression
was used to create the dumpfile.
The zlib/LZO/snappy indicator is only found down in the bowels of each
page_desc structure:
/* page flags */
#define DUMP_DH_COMPRESSED_ZLIB 0x1 /* page is compressed with zlib */
#define DUMP_DH_COMPRESSED_LZO 0x2 /* paged is compressed with lzo */
#define DUMP_DH_COMPRESSED_SNAPPY 0x4
/* paged is compressed with snappy */
/* descriptor of each page for vmcore */
typedef struct page_desc {
off_t offset; /* the offset of the page data*/
unsigned int size; /* the size of this dump page */
unsigned int flags; /* flags */
unsigned long long page_flags; /* page flags */
} page_desc_t;
The compressed kdump's header does contain a "status" flag:
struct disk_dump_header {
char signature[SIG_LEN]; /* = "KDUMP " */
int header_version; /* Dump header version */
struct new_utsname utsname; /* copy of system_utsname */
struct timeval timestamp; /* Time stamp */
unsigned int status; /* Above flags */
...
which has these 3 flags:
#define DUMP_HEADER_COMPLETED 0
#define DUMP_HEADER_INCOMPLETED 1
#define DUMP_HEADER_COMPRESSED 8
But they are all remnants of the old "diskdump" facility, and none of them
are ever used by makedumpfile.
Any chance that the LZO/snappy/zlib method could also be put up in
the disk_dump_header?
Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compression_header.patch
Type: text/x-patch
Size: 796 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20130912/a41ea26a/attachment.bin>
