From: Dave Anderson <anderson@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: kexec@lists.infradead.org
Subject: Re: [PATCH / RFC] makedumpfile header to show LZO/snappy/zlib
Date: Fri, 20 Sep 2013 09:04:40 -0400 (EDT) [thread overview]
Message-ID: <408026044.15752698.1379682280786.JavaMail.root@redhat.com> (raw)
In-Reply-To: <523BCD38.4020702@mxc.nes.nec.co.jp>
----- Original Message -----
> Hello Dave,
>
> (2013/09/16 0:56), Dave Anderson wrote:
> >
> > 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
> >
> > --- makedumpfile-1.5.4/makedumpfile.c.orig
> > +++ makedumpfile-1.5.4/makedumpfile.c
> > @@ -5162,6 +5162,16 @@ write_kdump_header(void)
> > dh->bitmap_blocks = divideup(info->len_bitmap, dh->block_size);
> > memcpy(&dh->timestamp, &info->timestamp, sizeof(dh->timestamp));
> > memcpy(&dh->utsname, &info->system_utsname, sizeof(dh->utsname));
> > + if (info->flag_compress & DUMP_DH_COMPRESSED_ZLIB)
> > + dh->status |= DUMP_DH_COMPRESSED_ZLIB;
> > +#ifdef USELZO
> > + else if (info->flag_compress & DUMP_DH_COMPRESSED_LZO)
> > + dh->status |= DUMP_DH_COMPRESSED_LZO)
> > +#endif
> > +#ifdef USESNAPPY
> > + else if (info->flag_compress & DUMP_DH_COMPRESSED_SNAPPY)
> > + dh->status |= DUMP_DH_COMPRESSED_SNAPPY)
> > +#endif
>
> dh->status will not guarantee that *all pages* are compressed
> by the check below:
>
> > #ifdef USELZO
> > } else if (info->flag_lzo_support
> > && (info->flag_compress &
> > DUMP_DH_COMPRESSED_LZO)
> > && ((size_out = info->page_size),
> > lzo1x_1_compress(buf, info->page_size,
> > buf_out,
> > &size_out, wrkmem) ==
> > LZO_E_OK)
> > && (size_out < info->page_size)) {
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> When there is no effect of compression, the page will not be compressed.
>
> > pd.flags = DUMP_DH_COMPRESSED_LZO;
> > pd.size = size_out;
> > memcpy(buf, buf_out, pd.size);
> > #endif
>
> If we are on the same page, I'll accept your patch.
Right, I understand.
Thanks,
Dave
>
>
> Thanks
> Atsushi Kumagai
>
> >
> > size = sizeof(struct disk_dump_header);
> > if (!write_buffer(info->fd_dumpfile, 0, dh, size,
> > info->name_dumpfile))
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-09-20 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1632896047.12077061.1378995804236.JavaMail.root@redhat.com>
2013-09-12 14:35 ` [PATCH / RFC] makedumpfile header to show LZO/snappy/zlib Dave Anderson
2013-09-20 4:21 ` Atsushi Kumagai
2013-09-20 13:04 ` Dave Anderson [this message]
2013-09-26 13:31 ` Petr Tesarik
2013-09-26 17:05 ` Dave Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=408026044.15752698.1379682280786.JavaMail.root@redhat.com \
--to=anderson@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.