Change Details

Compression can be requested by passing -c to dumpon(8) or by setting dumpcompress=YES in rc.conf. savecore(8) will automatically save compressed vmcores with a .gz extension. The kernel dump header struct is modified and its version is bumped. Two new fields were added: - dumpextent, which gives the distance between the leading and trailing headers. With uncompressed dumps, this is equal to dumplength. Kernel dumps are written sequentially, but when compression is enabled we don't know how long the dump will be. To handle this, we first check to see if the uncompressed dump would fit in the dump device. If so, we start writing at offset [end of device - uncompressed length]. If the uncompressed kernel dump would not fit, we start writing the compressed dump at the beginning of the device and hope that it ends up fitting; if not, we'll get an error when dump_raw_write() attempts to write past the device boundary. - compression, the compression algorithm used. In particular, I made an affordance for alternate compression algorithms, though we currently only support DEFLATE. I took bytes out of the panicstr buffer, since most panic strings are much shorter than 192 bytes. We currently don't support simultaneous encryption and compression. The reason is that the current implementation of encrypted dumps does not add any padding bytes, as uncompressed dumps are always a multiple of the device sector size in length. To support compressed dumps, though, we need padding bytes, which complicates the implementation somewhat. This will be handled in a separate revision, though I'm not sure if the extra complexity is worth it.

Compression can be requested by passing -c to dumpon(8) or by setting dumpcompress=YES in rc.conf. savecore(8) will automatically save compressed vmcores with a .gz extension. The kernel dump header struct is modified and its version is bumped. Two new fields were added: - dumpextent, which gives the distance between the leading and trailing headers. With uncompressed dumps, this is equal to dumplength. Kernel dumps are written sequentially, but when compression is enabled we don't know how long the dump will be. To handle this, we first check to see if the uncompressed dump would fit in the dump device. If so, we start writing at offset [end of device - uncompressed length]. If the uncompressed kernel dump would not fit, we start writing the compressed dump at the beginning of the device and hope that it ends up fitting; if not, we'll get an error when dump_raw_write() attempts to write past the device boundary. - compression, the compression algorithm used. In particular, I made an affordance for alternate compression algorithms, though we currently only support DEFLATE. I took bytes out of the panicstr buffer, since most panic strings are much shorter than 192 bytes. We currently don't support simultaneous encryption and compression. The reason is that the current implementation of encrypted dumps does not add any padding bytes, as uncompressed dumps are always a multiple of the device sector size in length. To support compressed dumps, though, we need padding bytes, which complicates the implementation somewhat. Therefore, that support is deferred to a different revision.

Compression can be requested by passing -c to dumpon(8) or by setting dumpcompress=YES in rc.conf. savecore(8) will automatically save compressed vmcores with a .gz extension. The kernel dump header struct is modified and its version is bumped. Two new fields were added: - dumpextent, which gives the distance between the leading and trailing headers. With uncompressed dumps, this is equal to dumplength. Kernel dumps are written sequentially, but when compression is enabled we don't know how long the dump will be. To handle this, we first check to see if the uncompressed dump would fit in the dump device. If so, we start writing at offset [end of device - uncompressed length]. If the uncompressed kernel dump would not fit, we start writing the compressed dump at the beginning of the device and hope that it ends up fitting; if not, we'll get an error when dump_raw_write() attempts to write past the device boundary. - compression, the compression algorithm used. In particular, I made an affordance for alternate compression algorithms, though we currently only support DEFLATE. I took bytes out of the panicstr buffer, since most panic strings are much shorter than 192 bytes. We currently don't support simultaneous encryption and compression. The reason is that the current implementation of encrypted dumps does not add any padding bytes, as uncompressed dumps are always a multiple of the device sector size in length. To support compressed dumps, though, we need padding bytes, which complicates the implementation somewhat. This will be handled in a separate revisionTherefore, though I'm not sure if the extra complexity is worth itthat support is deferred to a different revision.