> -----Original Message----- > > Hi, > > I created an enhancement request for makedumpfile here, > > https://github.com/makedumpfile/makedumpfile/issues/1 > > I found that compressing a flat core with gzip significantly reduces the size of > the core. Here were my findings, > > 32G flat elf core -E -F -d 0 > 33G kdump core -d 0 > 16G kdump compressed -c -d 0 > 1.9G flat elf core stream compressed with gzip -E -F -d 0 The kdump-compressed format does per-page compression with compression level 1, so depending on data in vmcore, gzip (with -6 by default) can compress one much smaller like this. Although I don't have a vmcore that shows such a drop in size with gzip as far as I tested. > > My feature request was to implement an option inside makedumpfile to gzip > compress the core output. This can already be accomplished by piping the core > thru the gzip tool, however, because makedumpfile already links against libz > having the option for makedumpfile to do it allows the gzip tools to be removed > from the crash kernels initramfs there by reducing the size. (personally I prefer piping it through gzip, but apparently there are cases where the initramfs size needs to be minimized..) > > Kazuhito Hagio had suggest adding the -C option instead of repurposing -c to do > this. > > So a resulting command line might looks like this, > > makedumpfile -C -F -E -d 31 /proc/vmcore core.gz Yes, the existing -c option is for per-page compression and creates a dumpfile that can be opened directly with crash utility, but stream compression is different. So I'd like to separate it from the -c. (as John commented, -z also might be good, but I wonder if someone might start to want the same function with lzo or snappy..) Anyway, I'll wait for patches for this enhancement. Thanks, Kazu _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
