7ce9da0bea
In non regular use cases allocated memory might stay persistent in memory pool. This small patch checks every minute if there are old objects which can be released from memory pool. Right now with regular use, the pool is checked for old objects on each allocation attempt from this pool. so basically polling by its use. Now consider what happens if someone writes a lot of files and stops use of the volume or even unmounts it. So the code will no longer check if objects can be released from the pool. Already allocated objects will still stay in pool cache. this is no big issue for common use. But someone discovered this issue while doing tests. personally i know this behavior and I'm aware of it. Its no big issue. just a enhancement Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl> Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com> Closes #10938 Closes #10969 |
||
---|---|---|
.. | ||
include | ||
lib | ||
Makefile.in | ||
README.md | ||
zfs_zstd.c | ||
zstd-in.c |
README.md
ZSTD-On-ZFS Library Manual
Introduction
This subtree contains the ZSTD library used in ZFS. It is heavily cut-down by dropping any unneeded files, and combined into a single file, but otherwise is intentionally unmodified. Please do not alter the file containing the zstd library, besides upgrading to a newer ZSTD release.
Tree structure:
zfs_zstd.c
is the actualzzstd
kernel module.lib/
contains the the unmodified, "amalgamated" version of theZstandard
library, generated from our template filezstd-in.c
is our template file for generating the libraryinclude/
: This directory contains supplemental includes for platform compatibility, which are not expected to be used by ZFS elsewhere in the future. Thus we keep them private to ZSTD.
Updating ZSTD
To update ZSTD the following steps need to be taken:
- Grab the latest release of ZSTD.
- Update
module/zstd/zstd-in.c
if required. (seezstd/contrib/single_file_libs/zstd-in.c
in the zstd repository) - Generate the "single-file-library" and put it to
module/zstd/lib/
. - Copy the following files to
module/zstd/lib/
:zstd/lib/zstd.h
zstd/lib/common/zstd_errors.h
This can be done using a few shell commands from inside the zfs repo:
cd PATH/TO/ZFS
url="https://github.com/facebook/zstd"
release="$(curl -s "${url}"/releases/latest | grep -oP '(?<=v)[\d\.]+')"
zstd="/tmp/zstd-${release}/"
wget -O /tmp/zstd.tar.gz \
"${url}/releases/download/v${release}/zstd-${release}.tar.gz"
tar -C /tmp -xzf /tmp/zstd.tar.gz
cp ${zstd}/lib/zstd.h module/zstd/lib/
cp ${zstd}/lib/zstd_errors.h module/zstd/lib/
${zstd}/contrib/single_file_libs/combine.sh \
-r ${zstd}/lib -o module/zstd/lib/zstd.c module/zstd/zstd-in.c
Note: if the zstd library for zfs is updated to a newer version, the macro list in include/zstd_compat_wrapper.h usually needs to be updated. this can be done with some hand crafting of the output of the following script: nm zstd.o | awk '{print "#define "$3 " zfs_" $3}' > macrotable
Altering ZSTD and breaking changes
If ZSTD made changes that break compatibility or you need to make breaking changes to the way we handle ZSTD, it is required to maintain backwards compatibility.
We already save the ZSTD version number within the block header to be used to add future compatibility checks and/or fixes. However, currently it is not actually used in such a way.