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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox