Zfs: ZFS-ZSTD im Baum kollidiert mit ZSTD im Kernel

Wenn man dies auch gegen linux-5.8.0-gentoo-r1 und gentoo-sources-5.8.2 sieht, stammt das folgende Beispiel von linux-5.8.0-gentoo-r1:

saratoga /usr/src/linux # grep ZSTD .config
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD is not set
# CONFIG_SQUASHFS_ZSTD is not set
# CONFIG_PSTORE_ZSTD_COMPRESS is not set
# CONFIG_CRYPTO_ZSTD is not set
CONFIG_ZSTD_COMPRESS=y
CONFIG_ZSTD_DECOMPRESS=y

saratoga /usr/src/linux # make -j 81
scripts/kconfig/conf  --syncconfig Kconfig
  DESCEND  objtool
  CALL    scripts/atomic/check-atomics.sh
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  GZIP    kernel/config_data.gz
  CC      kernel/configs.o
Cyclomatic Complexity 1 kernel/configs.c:ikconfig_cleanup
Cyclomatic Complexity 2 kernel/configs.c:ikconfig_init
Cyclomatic Complexity 1 kernel/configs.c:ikconfig_read_current
  AR      kernel/built-in.a
  GEN     .version
  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  AR      init/built-in.a
  LD      vmlinux.o
ld: fs/btrfs/zstd.o: in function `zstd_decompress':
/usr/src/linux/fs/btrfs/zstd.c:627: multiple definition of `zstd_decompress'; fs/zfs/zstd/zfs_zstd.o:/usr/src/linux/fs/zfs/zstd/zfs_zstd.c:526: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_buildCTable_wksp':
/usr/src/linux/lib/zstd/fse_compress.c:93: multiple definition of `FSE_buildCTable_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7548: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_NCountWriteBound':
/usr/src/linux/lib/zstd/fse_compress.c:200: multiple definition of `FSE_NCountWriteBound'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7668: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_writeNCount':
/usr/src/linux/lib/zstd/fse_compress.c:303: multiple definition of `FSE_writeNCount'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7769: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_optimalTableLog_internal':
/usr/src/linux/lib/zstd/fse_compress.c:495: multiple definition of `FSE_optimalTableLog_internal'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7806: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_optimalTableLog_internal':
/usr/src/linux/lib/zstd/fse_compress.c:495: multiple definition of `FSE_optimalTableLog'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7819: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_normalizeCount':
/usr/src/linux/lib/zstd/fse_compress.c:609: multiple definition of `FSE_normalizeCount'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7917: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_buildCTable_raw':
/usr/src/linux/lib/zstd/fse_compress.c:667: multiple definition of `FSE_buildCTable_raw'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7978: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_buildCTable_rle':
/usr/src/linux/lib/zstd/fse_compress.c:710: multiple definition of `FSE_buildCTable_rle'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8018: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_compress_usingCTable':
/usr/src/linux/lib/zstd/fse_compress.c:787: multiple definition of `FSE_compress_usingCTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8096: first defined here
ld: lib/zstd/fse_compress.o: in function `FSE_compressBound':
/usr/src/linux/lib/zstd/fse_compress.c:795: multiple definition of `FSE_compressBound'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8105: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_optimalTableLog':
/usr/src/linux/lib/zstd/huf_compress.c:70: multiple definition of `HUF_optimalTableLog'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8413: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_buildCTable_wksp':
/usr/src/linux/lib/zstd/huf_compress.c:421: multiple definition of `HUF_buildCTable_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8703: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compressBound':
/usr/src/linux/lib/zstd/huf_compress.c:526: multiple definition of `HUF_compressBound'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8805: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compress1X_usingCTable':
/usr/src/linux/lib/zstd/huf_compress.c:548: multiple definition of `HUF_compress1X_usingCTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8894: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compress4X_usingCTable':
/usr/src/linux/lib/zstd/huf_compress.c:592: multiple definition of `HUF_compress4X_usingCTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8929: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compress4X_usingCTable':
/usr/src/linux/lib/zstd/huf_compress.c:592: multiple definition of `HUF_compress4X_usingCTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:8929: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compress1X_wksp':
/usr/src/linux/lib/zstd/huf_compress.c:750: multiple definition of `HUF_compress1X_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:9096: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compress1X_repeat':
/usr/src/linux/lib/zstd/huf_compress.c:757: multiple definition of `HUF_compress1X_repeat'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:9108: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compress4X_wksp':
/usr/src/linux/lib/zstd/huf_compress.c:763: multiple definition of `HUF_compress4X_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:9130: first defined here
ld: lib/zstd/huf_compress.o: in function `HUF_compress4X_repeat':
/usr/src/linux/lib/zstd/huf_compress.c:770: multiple definition of `HUF_compress4X_repeat'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:9145: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressContinue':
/usr/src/linux/lib/zstd/compress.c:2541: multiple definition of `ZSTD_compressContinue'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:15881: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBlock_greedy_extDict':
/usr/src/linux/lib/zstd/compress.c:2252: multiple definition of `ZSTD_compressBlock_greedy_extDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:19497: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_seqToCodes':
/usr/src/linux/lib/zstd/compress.c:567: multiple definition of `ZSTD_seqToCodes'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:15014: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_initCStream_usingCDict':
/usr/src/linux/lib/zstd/compress.c:3106: multiple definition of `ZSTD_initCStream_usingCDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16811: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_flushStream':
/usr/src/linux/lib/zstd/compress.c:3239: multiple definition of `ZSTD_flushStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:17175: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compress_usingCDict':
/usr/src/linux/lib/zstd/compress.c:2931: multiple definition of `ZSTD_compress_usingCDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16684: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBegin_usingCDict':
/usr/src/linux/lib/zstd/compress.c:2915: multiple definition of `ZSTD_compressBegin_usingCDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16660: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compress_usingDict':
/usr/src/linux/lib/zstd/compress.c:2827: multiple definition of `ZSTD_compress_usingDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16373: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_resetCStream':
/usr/src/linux/lib/zstd/compress.c:3050: multiple definition of `ZSTD_resetCStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:14050: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_adjustCParams':
/usr/src/linux/lib/zstd/compress.c:182: multiple definition of `ZSTD_adjustCParams'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:14152: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_copyCCtx':
/usr/src/linux/lib/zstd/compress.c:350: multiple definition of `ZSTD_copyCCtx'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:14919: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_freeCStream':
/usr/src/linux/lib/zstd/compress.c:3004: multiple definition of `ZSTD_freeCStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:13233: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressStream':
/usr/src/linux/lib/zstd/compress.c:3224: multiple definition of `ZSTD_compressStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:17054: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBegin':
/usr/src/linux/lib/zstd/compress.c:2760: multiple definition of `ZSTD_compressBegin'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16249: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_freeCDict':
/usr/src/linux/lib/zstd/compress.c:2901: multiple definition of `ZSTD_freeCDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16552: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBegin_advanced':
/usr/src/linux/lib/zstd/compress.c:2748: multiple definition of `ZSTD_compressBegin_advanced'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16229: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_getCParams':
/usr/src/linux/lib/zstd/compress.c:3414: multiple definition of `ZSTD_getCParams'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:17337: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBegin_usingDict':
/usr/src/linux/lib/zstd/compress.c:2755: multiple definition of `ZSTD_compressBegin_usingDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16239: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBound':
/usr/src/linux/lib/zstd/compress.c:38: multiple definition of `ZSTD_compressBound'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:13129: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_createCStream_advanced':
/usr/src/linux/lib/zstd/compress.c:2983: multiple definition of `ZSTD_createCStream_advanced'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16707: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_checkCParams':
/usr/src/linux/lib/zstd/compress.c:155: multiple definition of `ZSTD_checkCParams'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:10272: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_maxCLevel':
/usr/src/linux/lib/zstd/compress.c:3295: multiple definition of `ZSTD_maxCLevel'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:17200: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_getSeqStore':
/usr/src/linux/lib/zstd/compress.c:141: multiple definition of `ZSTD_getSeqStore'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:13274: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_endStream':
/usr/src/linux/lib/zstd/compress.c:3252: multiple definition of `ZSTD_endStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:17182: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBlock':
/usr/src/linux/lib/zstd/compress.c:2547: multiple definition of `ZSTD_compressBlock'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:15893: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_CStreamInSize':
/usr/src/linux/lib/zstd/compress.c:3023: multiple definition of `ZSTD_CStreamInSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16720: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_initCStream':
/usr/src/linux/lib/zstd/compress.c:3093: multiple definition of `ZSTD_initCStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16866: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_freeCCtx':
/usr/src/linux/lib/zstd/compress.c:134: multiple definition of `ZSTD_freeCCtx'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:13233: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_getParams':
/usr/src/linux/lib/zstd/compress.c:3438: multiple definition of `ZSTD_getParams'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:17359: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressBound':
/usr/src/linux/lib/zstd/compress.c:38: multiple definition of `ZSTD_CStreamOutSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16725: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressCCtx':
/usr/src/linux/lib/zstd/compress.c:2832: multiple definition of `ZSTD_compressCCtx'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16388: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_invalidateRepCodes':
/usr/src/linux/lib/zstd/compress.c:341: multiple definition of `ZSTD_invalidateRepCodes'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:14679: first defined here
ld: lib/zstd/compress.o: in function `ZSTD_compressEnd':
/usr/src/linux/lib/zstd/compress.c:2807: multiple definition of `ZSTD_compressEnd'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:16299: first defined here
ld: lib/zstd/entropy_common.o: in function `FSE_versionNumber':
/usr/src/linux/lib/zstd/entropy_common.c:49: multiple definition of `FSE_versionNumber'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:2504: first defined here
ld: lib/zstd/entropy_common.o: in function `ERR_isError':
/usr/src/linux/lib/zstd/error_private.h:44: multiple definition of `FSE_isError'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:810: first defined here
ld: lib/zstd/entropy_common.o: in function `HUF_isError':
/usr/src/linux/lib/zstd/entropy_common.c:52: multiple definition of `HUF_isError'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:2509: first defined here
ld: lib/zstd/entropy_common.o: in function `FSE_readNCount':
/usr/src/linux/lib/zstd/entropy_common.c:60: multiple definition of `FSE_readNCount'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:2520: first defined here
ld: lib/zstd/fse_decompress.o: in function `FSE_buildDTable_rle':
/usr/src/linux/lib/zstd/fse_decompress.c:180: multiple definition of `FSE_buildDTable_rle'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:2895: first defined here
ld: lib/zstd/fse_decompress.o: in function `FSE_buildDTable_raw':
/usr/src/linux/lib/zstd/fse_decompress.c:188: multiple definition of `FSE_buildDTable_raw'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:2904: first defined here
ld: lib/zstd/fse_decompress.o: in function `FSE_decompress_usingDTable':
/usr/src/linux/lib/zstd/fse_decompress.c:283: multiple definition of `FSE_decompress_usingDTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:2995: first defined here
ld: lib/zstd/fse_decompress.o: in function `FSE_decompress_wksp':
/usr/src/linux/lib/zstd/fse_decompress.c:295: multiple definition of `FSE_decompress_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:3007: first defined here
ld: lib/zstd/zstd_common.o: in function `ZSTD_malloc':
/usr/src/linux/lib/zstd/zstd_common.c:69: multiple definition of `ZSTD_malloc'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7374: first defined here
ld: lib/zstd/zstd_common.o: in function `ZSTD_free':
/usr/src/linux/lib/zstd/zstd_common.c:73: multiple definition of `ZSTD_free'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:7395: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_readDTableX2_wksp':
/usr/src/linux/lib/zstd/huf_decompress.c:91: multiple definition of `HUF_readDTableX2_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:21903: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress1X2_usingDTable':
/usr/src/linux/lib/zstd/huf_decompress.c:227: multiple definition of `HUF_decompress1X2_usingDTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22222: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress1X2_DCtx_wksp':
/usr/src/linux/lib/zstd/huf_decompress.c:233: multiple definition of `HUF_decompress1X2_DCtx_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22229: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress4X2_usingDTable':
/usr/src/linux/lib/zstd/huf_decompress.c:358: multiple definition of `HUF_decompress4X2_usingDTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22262: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress4X2_DCtx_wksp':
/usr/src/linux/lib/zstd/huf_decompress.c:364: multiple definition of `HUF_decompress4X2_DCtx_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22284: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress1X_usingDTable':
/usr/src/linux/lib/zstd/huf_decompress.c:848: multiple definition of `HUF_decompress1X_usingDTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22324: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress4X_usingDTable':
/usr/src/linux/lib/zstd/huf_decompress.c:855: multiple definition of `HUF_decompress4X_usingDTable'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22343: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_selectDecoder':
/usr/src/linux/lib/zstd/huf_decompress.c:890: multiple definition of `HUF_selectDecoder'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22392: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress4X_hufOnly_wksp':
/usr/src/linux/lib/zstd/huf_decompress.c:927: multiple definition of `HUF_decompress4X_hufOnly_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22470: first defined here
ld: lib/zstd/huf_decompress.o: in function `HUF_decompress1X_DCtx_wksp':
/usr/src/linux/lib/zstd/huf_decompress.c:942: multiple definition of `HUF_decompress1X_DCtx_wksp'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:22495: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decompressBlock':
/usr/src/linux/lib/zstd/decompress.c:1480: multiple definition of `ZSTD_decompressBlock'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:27819: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decompressBegin_usingDict':
/usr/src/linux/lib/zstd/decompress.c:1970: multiple definition of `ZSTD_decompressBegin_usingDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25688: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_nextInputType':
/usr/src/linux/lib/zstd/decompress.c:1725: multiple definition of `ZSTD_nextInputType'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25367: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_DStreamOutSize':
/usr/src/linux/lib/zstd/decompress.c:2278: multiple definition of `ZSTD_DStreamOutSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25795: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_resetDStream':
/usr/src/linux/lib/zstd/decompress.c:2282: multiple definition of `ZSTD_resetDStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24597: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_getDictID_fromDict':
/usr/src/linux/lib/zstd/decompress.c:2108: multiple definition of `ZSTD_getDictID_fromDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25725: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decompress_usingDDict':
/usr/src/linux/lib/zstd/decompress.c:2150: multiple definition of `ZSTD_decompress_usingDDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25761: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_findFrameCompressedSize':
/usr/src/linux/lib/zstd/decompress.c:1511: multiple definition of `ZSTD_findFrameCompressedSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25039: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_createDCtx_advanced':
/usr/src/linux/lib/zstd/decompress.c:130: multiple definition of `ZSTD_createDCtx_advanced'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24642: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_getcBlockSize':
/usr/src/linux/lib/zstd/decompress.c:396: multiple definition of `ZSTD_getcBlockSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:26452: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_freeDStream':
/usr/src/linux/lib/zstd/decompress.c:2258: multiple definition of `ZSTD_freeDStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25788: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_freeDCtx':
/usr/src/linux/lib/zstd/decompress.c:149: multiple definition of `ZSTD_freeDCtx'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24668: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_nextSrcSizeToDecompress':
/usr/src/linux/lib/zstd/decompress.c:1721: multiple definition of `ZSTD_nextSrcSizeToDecompress'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25346: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_findDecompressedSize':
/usr/src/linux/lib/zstd/decompress.c:320: multiple definition of `ZSTD_findDecompressedSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24884: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_isFrame':
/usr/src/linux/lib/zstd/decompress.c:175: multiple definition of `ZSTD_isFrame'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24703: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decodeSeqHeaders':
/usr/src/linux/lib/zstd/decompress.c:795: multiple definition of `ZSTD_decodeSeqHeaders'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:26883: first defined here
ld: lib/zstd/decompress.o: in function `memcpy':
/usr/src/linux/./include/linux/string.h:406: multiple definition of `ZSTD_copyDCtx'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/./include/linux/string.h:406: first defined here
ld: lib/zstd/decompress.o: in function `memcpy':
/usr/src/linux/./include/linux/string.h:406: multiple definition of `ZSTD_decompressBegin'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24597: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decompressStream':
/usr/src/linux/lib/zstd/decompress.c:2299: multiple definition of `ZSTD_decompressStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:26095: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decompressContinue':
/usr/src/linux/lib/zstd/decompress.c:1744: multiple definition of `ZSTD_decompressContinue'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25395: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_initDStream':
/usr/src/linux/lib/zstd/decompress.c:2215: multiple definition of `ZSTD_initDStream'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25850: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decompress_usingDict':
/usr/src/linux/lib/zstd/decompress.c:1709: multiple definition of `ZSTD_decompressDCtx'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25320: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_getDictID_fromFrame':
/usr/src/linux/lib/zstd/decompress.c:2136: multiple definition of `ZSTD_getDictID_fromFrame'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24756: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decompress_usingDict':
/usr/src/linux/lib/zstd/decompress.c:1709: multiple definition of `ZSTD_decompress_usingDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25298: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_getDictID_fromDDict':
/usr/src/linux/lib/zstd/decompress.c:2121: multiple definition of `ZSTD_getDictID_fromDDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24442: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_insertBlock':
/usr/src/linux/lib/zstd/decompress.c:1491: multiple definition of `ZSTD_insertBlock'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25076: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_getFrameParams':
/usr/src/linux/lib/zstd/decompress.c:211: multiple definition of `ZSTD_getFrameContentSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24844: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_decodeLiteralsBlock':
/usr/src/linux/lib/zstd/decompress.c:434: multiple definition of `ZSTD_decodeLiteralsBlock'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:26474: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_freeDDict':
/usr/src/linux/lib/zstd/decompress.c:2091: multiple definition of `ZSTD_freeDDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:24414: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_initDStream_usingDDict':
/usr/src/linux/lib/zstd/decompress.c:2248: multiple definition of `ZSTD_initDStream_usingDDict'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25859: first defined here
ld: lib/zstd/decompress.o: in function `ZSTD_DStreamInSize':
/usr/src/linux/lib/zstd/decompress.c:2277: multiple definition of `ZSTD_DStreamInSize'; fs/zfs/zstd/lib/zstd.o:/usr/src/linux/fs/zfs/zstd/lib/zstd.c:25795: first defined here
make: *** [Makefile:1139: vmlinux] Error 1

Ich baue gegen ZFS HEAD (commit 64025fa3a1f0f710f7f8678f2ac459b07ed9f88f) und vermute, dass dies mit der gestrigen Zusammenführung von https://github.com/openzfs/zfs/pull/10278#issuecomment -677809493 zusammenhängt

Danke für die Warnung!
Keines unserer Testsysteme hatte diese Probleme...

@c0d3z3r0 und @brainslayer
Ihr wollt vielleicht Abhilfe schaffen...

Bearbeiten
Ich habe mich geirrt, wir haben 5.8 getestet, danke @brainslayer

meins läuft 5.8 mit aktuellem Master-Git, natürlich einschließlich zstd. alle arbeiten

server2:~ # uname -a Linux server2 5.8.2-666.ddwrt #1 SMP Fri Aug 21 13:02:10 +03 2020 x86_64 x86_64 x86_64 GNU/Linux server2:~ # zfs get all |grep compres zfs compressratio 2.04x - zfs compression zstd local zfs refcompressratio 2.04x - server2:~ #

aber er macht Inline-Kernel-Kompilierung. Ich kompiliere aus Baum

ah, die Ursache ist einfach. Das Problem ist, dass er mit zstd im Kernel kompiliert. dies kollidiert mit Symbolen aus der zfs-zstd-Implementierung. Dies ist unlösbar, es sei denn, wir benennen alle zstd-Funktionen in unserer Implementierung um. Sperrpunkt

@BrainSlayer Ich bin damit nicht so vertraut, aber können wir das im Kernel enthaltene ZSTD nicht beim Build ausschließen oder ist es automatisch für alles enthalten, ohne uns die Option zu geben, dies nicht zu tun?

Nein Wir können nicht. die ZSTD-Implementierung im Kernel ist funktionsreduziert und veraltet

Warum brauchten wir eine eigene Implementierung? Ich glaube, ZSTD ist jetzt schon eine Weile im Kernel. Können wir es nicht einfach benutzen?

Von: Sebastian Gottschall [email protected]
Gesendet: Freitag, 21. August 2020 11:23:16 Uhr
An: openzfs/ zfs [email protected]
Cc: Arvind Sankar [email protected] ; Autor [email protected]
Betreff: Re: [openzfs/zfs] ZSTD-Konflikt mit Linux 5.8.x (#10763)

ah, die Ursache ist einfach. Das Problem ist, dass er mit zstd in der Kernel-Unterstützung kompiliert. dies kollidiert mit Symbolen aus der zfs-zstd-Implementierung. Dies ist unlösbar, es sei denn, wir benennen alle zstd-Funktionen in unserer Implementierung um. Sperrpunkt

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/openzfs/zfs/issues/10763#issuecomment-678348711 an oder melden Sie sich ab https://github.com/notifications/unsubscribe-auth/AJBU6WIW2CQXKWFNHZ4KYMDSB2GOJANCNFSM4QG654KA .

@nivedita76
Wir können uns nicht auf die Version im Kernel verlassen, da sie möglicherweise nicht mit der Version übereinstimmt, die Ihre Daten ursprünglich komprimiert hat. Einfach ausgedrückt: Wenn Sie nicht möchten, dass Ihre Daten beschädigt werden, sollten Sie sich nicht auf das Kernel-ZSTD verlassen.

TLDR: Nein.

Warum brauchten wir eine eigene Implementierung? Ich glaube, ZSTD ist jetzt schon eine Weile im Kernel. Können wir es nicht einfach benutzen?
…
________________________________ Von: Sebastian Gottschall [email protected] Gesendet: Freitag, 21. August 2020 11:23:16 Uhr An: openzfs/ zfs [email protected] Cc: Arvind Sankar [email protected] ; Autor [email protected] Betreff: Re: [openzfs/zfs] ZSTD-Konflikt mit Linux 5.8.x (#10763) Ah, die Ursache ist einfach. Das Problem ist, dass er mit zstd in der Kernel-Unterstützung kompiliert. dies kollidiert mit Symbolen aus der zfs-zstd-Implementierung. Dies ist unlösbar, es sei denn, wir benennen alle zstd-Funktionen in unserer Implementierung um. Sperrpunkt – Sie erhalten dies, weil Sie den Thread verfasst haben. Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an< #10763 (Kommentar) > oder melden Sie sich ab unter https://github.com/notifications/unsubscribe-auth/AJBU6WIW2CQXKWFNHZ4KYMDSB2GOJANCNFSM4QG654KA .

wie ich im letzten Kommentar geschrieben habe. die im Kernel enthaltene zstd lib ist veraltet und hat eingeschränkte Funktionen. es wird nicht funktionieren. aber Sie können zfs als Problemumgehung aus dem Baum kompilieren, bis wir uns darauf einigen, wie wir dieses Problem beheben. Wir haben nur eine Symbolkollision, da Sie sie statisch kompiliert haben

@BrainSlayer Irgendeine Idee, wie viele Distributionen sofort von diesem Problem betroffen wären?

100%. Die im Kernel enthaltene zstd lib ist seit langem enthalten. Wenn Sie also zfs static in den Kernel kompilieren und im Kernel zstd aktiviert ist, sind alle unterstützten Kernel betroffen. Das Kompilieren aus dem Baum ist kein Problem

Lösung, die einen Wrapper-Header mit einigen #define-Makros schreibt, die alle zstd-Funktionen für zfs umbenennen

@BrainSlayer Ich meinte so: Wie viele Kernel kompilieren zfs statisch in den Kernel UND haben beide das im Kernel enthaltene zstd aktiviert?

Lösung, die einen Wrapper-Header mit einigen #define-Makros schreibt, die alle zstd-Funktionen für zfs umbenennen

Wir könnten in der Tat allem ZFS_ voranstellen, die Priorität für so etwas hängt ein wenig davon ab, wie viele Distributionen sofort betroffen wären, wenn zfs static in den Kernel kompiliert UND das im Kernel enthaltene zstd vorhanden wäre beide aktiviert...

@BrainSlayer was würde derzeit passieren, wenn jemand das zfs-Modul lädt und dann ein anderes Kernel-Modul lädt, das ZSTD im Kernel verwendet?

Zum Umbenennen ist es möglich, dies mit objcopy --prefix-symbols=zfs_ (zB) zu tun, um nicht alle Symbole auflisten zu müssen. Ein Beispiel im Kernel ist drivers/firmware/efi/libstub/Makefile, das alle Symbole für den EFI-Stub auf ARM64 umbenennt.

@nivedita76
Könnten Sie den Titel bitte umbenennen in:
In-tree ZFS-ZSTD clash with in-kernel ZSTD

Zum Umbenennen ist es möglich, dies mit objcopy --prefix-symbols=zfs_ (zB) zu tun, um nicht alle Symbole auflisten zu müssen

Ich persönlich bin mit einer solchen Lösung einverstanden.
@allanjude und @c0d3z3r0 ?

In Bezug auf Distributionen unterstützt der Upstream-Kernel jetzt initramfs, das mit ZSTD komprimiert wurde. Ich bin mir nicht sicher, wie viele Distributionen das zurückportiert haben, aber ZSTD, das in den Kernel kompiliert wurde, könnte ziemlich verbreitet sein.

@nivedita76 Das hat mir @BrainSlayer vorher gesagt, aber das ist nicht das Problem.
Das Problem besteht darin, ZSTD "einzubacken" UND ZFS im Baum zu erstellen.
(die Kombination aus beidem)

Aber ja, wenn ZFS im Baum erstellt wird, sind alle Kernel-Versionen einschließlich ZSTD im Kernel betroffen.

@nivedita76 Das hat mir @BrainSlayer vorher gesagt, aber das ist nicht das Problem.
Das Problem besteht darin, ZSTD "einzubacken" UND ZFS im Baum zu erstellen.
(die Kombination aus beidem)

Sind wir sicher, dass dies keine Laufzeitprobleme verursacht? Die ZFS ZSTD-Implementierung wird als Modul geladen, richtig? Wie kann das ZSTD-Symbole überschreiben, die bereits in den Kernel eingebaut sind?

Was ich meine ist, sind wir sicher, dass zfs.ko die Symbole von zzstd.ko verwendet und nicht die im Kernel eingebauten?

@nivedita76
Ich glaube, wir haben es auch in Kernel-Versionen ohne ZSTD getestet ...

Aber ich denke, nur unsere Version voranzustellen, ist eine schöne und saubere Lösung.

@Ornias1993 Ich stimme zu. Ich werde etwas vorbereiten, sobald ich etwas Zeit finde. Es gibt viele Funktionen zu berücksichtigen

@nivedita76 zzstd.ko verwendet alle Funktionen inline. Es gibt keinen Verweis auf zstd von zfs.ko usw., daher befinden sich alle Verweise auf zstd selbst in zzstd.ko selbst. Es gibt also keine Kollision, wenn Sie es nur aus dem Baum kompilieren und nicht statisch in den Kernel

@Ornias1993 Ich stimme zu. Ich werde etwas vorbereiten, sobald ich etwas Zeit finde. Es gibt viele Funktionen zu berücksichtigen

Würde die Lösung von @nivedita76 für diesen Zweck funktionieren?
objcopy --prefix-symbols=zfs_

@nivedita76
Ich glaube, wir haben es auch in Kernel-Versionen ohne ZSTD getestet ...

Aber das geht nicht auf meine Bedenken ein, die sich auf Kernel-Versionen _mit_ ZSTD beziehen. Oder wirklich versuchen, Pools zu importieren, die mit einem Kernel ohne ZSTD erstellt wurden, der definitiv In-Tree-ZSTD verwendet, auf einen Kernel mit ZSTD, der möglicherweise das In-Kernel-ZSTD verwendet.

@nivedita76 zzstd.ko verwendet alle Funktionen inline. Es gibt keinen Verweis auf zstd von zfs.ko usw., daher befinden sich alle Verweise auf zstd selbst in zzstd.ko selbst. Es gibt also keine Kollision, wenn Sie es nur aus dem Baum kompilieren und nicht statisch in den Kernel

Oh, nicht einmal zstd_compress/zstd_decompress kollidieren?

@nivedita76 Wenn ja, hätten wir das gleiche Problem wie hier, nicht wahr? ;)
Denn wenn das der Fall wäre, würde es auch zu einem Fehler führen, weil es zwei Optionen für zstd_compress/zstd_decompress hätte …

Ok, ich war mir nicht sicher, ob es bei Symbolkonflikten in Modulen vs. Kernel zu einem Fehler kam.

@nivedita76 Ich bin mir nicht 100% sicher, aber wenn wir diesen Fehler beheben, wäre das sowieso behoben, wenn das der Fall ist. Es sollte zumindest auf OpenZFS2.0 RELEASE behoben werden :)

Bitte lass mich diese Nacht einfach schlafen. Morgen haben wir eine Lösung. Es ist leicht zu beheben und nein, es besteht kein Risiko, falsche Symbole zu verwenden, wenn es als Modul aus dem Baum kompiliert wird

lol @BrainSlayer süße Träume :)

@Ornias1993 ein interessanter Punkt. Ist das statische Verlinken von Nicht-GPL-Code wie zfs mit dem Kernel nicht eine Verletzung der GPL-Lizenz?

@nivedita76 bitte versuchen Sie diesen Commit/Patch zusätzlich zum Master und geben Sie uns Feedback, wenn dies Ihr Problem löst https://github.com/BrainSlayer/zfs/commit/2fee2750a68ed7826d17554181971c0ee6cb703b

@BrainSlayer
Solange Sie nicht verteilen oder veröffentlichen, ist dies kein Verstoß gegen die GPL gemäß Artikel 2 Abschnitt b der GPLv2.

Komischerweise sind die GPL_ONLY-Tags selbst eine GPL-Verletzung gemäß Artikel 6 der GPLv2 und deren allgemeiner Erläuterung in der Präambel, die im Gegensatz zu dem, was viele Leute sagen, eine rechtlich anerkannte Quelle zur Erläuterung von Artikeln von a ist Lizenz oder Vereinbarung in (mindestens) Europa.

TLDR:

1. Indem Sie es selbst statisch verlinken, verletzen Sie es nicht
2. Der Linux-Kernel selbst ist der größte GPL-Verletzer weltweit.

@BrainSlayer Hat der von @nivedita76 vorgeschlagene Patch nicht funktioniert?

@Ornias1993 habe keinen Patch von ihm gesehen. Ich habe meine eigene erstellt (siehe meinen Commit-Link zu meinem privaten Baum). Es reicht nicht aus, den Symbolen nur ein Präfix voranzustellen, da Sie auch die Verweise darauf voranstellen müssen, was mit objcopy nicht einfach möglich ist, außer mit einer Symbolliste. Also ist meine Lösung sauberer (normalerweise)

In Bezug auf den Linux-Kernel verstehe ich nicht, warum Sie sagen, dass der Kernel selbst der größte Verletzer ist. erklären

@BrainSlayer Ohh okey, ich bezog mich auf seinen Patch-Vorschlag. Guter Punkt in der Tat.

Warum Linux bereits der größte Verletzer ist, habe ich im zweiten Teil meines letzten Posts erklärt.

@BrainSlayer Könntest du einen PR-Entwurf für deinen Patch einreichen, nur damit wir diese Tests in Gang bringen können?

@Ornias1993 Ich möchte zuerst ein Feedback von @nivedita76 erhalten , um sicherzugehen. Ich habe es bereits lokal ohne Probleme kompiliert

und wir müssen @behlendorf bitten, das Testsystem so zu ändern, dass es dieses Szenario enthält.

@brainslayer Ich weiß, das ist nicht der Grund, warum ich frage ... Ich habe gefragt, um sicherzustellen, dass die bestehenden Tests nicht scheißen.

@Ornias1993 ich und git eine unendliche Geschichte. gib mir ein paar minuten

@BrainSlayer Keine Sorge, ich denke, wir sind mittlerweile alle daran gewöhnt :)
Entwurf ist übrigens der kleine Dropdown-Button rechts neben dem großen grünen Submit-Button ;)

es geht um Verzweigung. Mein Git-Tree hat auch einen anderen Fix für mein eigenes System (Abwärtskompatibilität mit Dev-Versionen). Ich habe es jetzt schon verzweigt
https://github.com/openzfs/zfs/pull/10775

Nein Wir können nicht. die ZSTD-Implementierung im Kernel ist funktionsreduziert und veraltet

FYI Ich bin dabei, es zu aktualisieren, um den neuesten Upstream direkt zu verwenden. Die einzige Funktion, die nicht unterstützt wird, sind Aufrufe von malloc() und free() (ohne ZSTD_customMem , zB ZSTD_createCCtx() ), da es keinen großartigen Standardwert gibt, und zwar muss vor dem Booten funktionieren. Aber die Bereitstellung von ZSTD_customMem wird gut funktionieren.

Lassen Sie mich wissen, ob Sie daran interessiert sind, den zstd im Kernel zu verwenden, sobald er aktualisiert wurde. Du kannst dich per E-Mail an ${github-username}@fb.com wenden, oder ich werde diesen Thread noch einmal überprüfen.

Wir können uns nicht auf die Version im Kernel verlassen, da sie möglicherweise nicht mit der Version übereinstimmt, die Ihre Daten ursprünglich komprimiert hat. Einfach ausgedrückt: Wenn Sie nicht möchten, dass Ihre Daten beschädigt werden, sollten Sie sich nicht auf das Kernel-ZSTD verlassen.

Das zstd-Format ist stabil und die zstd-Versionen sind sowohl aufwärts- als auch abwärtskompatibel. Die Version im Kernel kann Daten verstehen, die von der neuesten Version erzeugt wurden, und umgekehrt. Die Verwendung einer anderen Version ist kein Problem.

@terrelln ZSTD wurde bereits implementiert, es gibt keine Pläne für die Verwendung von In-Kernel-Zstd, Gespräche darüber sind seit Monaten abgeschlossen ...

Wie auch immer: Im Grunde geht es hier nicht wirklich um die ZSTD-Version, sondern um ZFS.
ZFS führt Prüfsummenbildung durch, selbst kompatible Versionen von ZSTD können zu leicht unterschiedlichen Prüfsummen führen, und wir müssen dies berücksichtigen. ZFS muss auch viele verschiedene Plattformen unterstützen, sowohl auf Linux- als auch auf FreeBSD-Basis. Sich auf unterschiedliche Versionen von ZSTD im Kernel verlassen zu müssen, verkompliziert die Dinge bis zum n-ten Grad.

Die aktuelle Implementierung von zstd auf zfs ist ziemlich solide, gut überprüft und dieser Fehler wurde bereits ohne große Probleme behoben.

Obwohl es großartig ist, dass Sie uns Ihre Meinung dazu mitteilen, wie wir dies erreichen könnten, hat ZSTD-on-ZFS die Designphase mittlerweile verlassen, und mit dem aktuellen Design gibt es keinen Vorteil bei der Verwendung von In-Kernel-ZSTD ....

Am Freitag, den 28. August 2020 um 11:22:21 -0700 schrieb Kjeld Schouten-Lebbing:

@terrelln ZSTD wurde bereits implementiert, es gibt keine Pläne für die Verwendung von In-Kernel-Zstd, Gespräche darüber sind seit Monaten abgeschlossen ...

Wie auch immer: Im Grunde geht es hier nicht wirklich um die ZSTD-Version, sondern um ZFS.
ZSTD führt Prüfsummenbildung durch, selbst kompatible Versionen von ZSTD können zu leicht unterschiedlichen Prüfsummen führen, und wir müssen dies berücksichtigen. ZSTD muss auch viele verschiedene Plattformen unterstützen, sowohl auf Linux- als auch auf FreeBSD-Basis. Sich auf unterschiedliche Versionen von ZSTD im Kernel verlassen zu müssen, verkompliziert die Dinge bis zum n-ten Grad.

Die aktuelle Implementierung von zstd auf zfs ist ziemlich solide, gut überprüft und dieser Fehler wurde bereits ohne große Probleme behoben.

Obwohl es großartig ist, dass Sie uns Ihre Meinung dazu mitteilen, wie wir dies erreichen könnten, hat ZSTD-on-ZFS die Designphase mittlerweile verlassen, und mit dem aktuellen Design gibt es keinen Vorteil bei der Verwendung von In-Kernel-ZSTD ....

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an:
https://github.com/openzfs/zfs/issues/10763#issuecomment -683037238

Es gibt mindestens einen Vorteil: die Beseitigung von Doppelarbeit. zstd fügt hinzu
etwa 0,5 MB zum ZFS-Kernel-Build.

Danke.

@nivedita76 Die aktuelle ZFS-Version bindet jede ZFS-Version an eine bestimmte ZSTD-Version. Was rückgängig zu machen wäre eine Hölle.

Sie unterschätzen auch: Es würde keine 0,5 MB aus dem Kernel herausschneiden, wir müssten immer noch eine ZSTD-Bibliothek für Plattformen (oder Kernel-Versionen) liefern, die kein ZSTD integriert haben. Um es noch komplizierter zu machen, gab es früher (ungefähr vor 3 Jahren) Probleme mit zstd-Versionen, die bei Verwendung mit ZFS nicht richtig funktionierten. Ohh und zfs unterstützen auch Kernel ohne ZSTD-Buildin afaik.

Alles in allem also: Wir können die ZSTD-Bibliothek nicht vollständig entfernen. Wir könnten es mit harter Umschreibungsarbeit zu einer Option machen, eine Kernel-zstd-Version zu verwenden, aber niemand wird die dafür erforderliche Höllenarbeit leisten und sie tatsächlich weiterhin unterstützen. Und wofür? Weil das bedeuten würde, dass ein paar Leute (es ist eine kleine Minderheit, die das tut, was Sie tun, und eine gpl-Verletzung, einen solchen Kernel zu verteilen) es kompilieren könnten, um 0,5 MB zu sparen?

All diese Designdiskussionen werden seit 3-4 Jahren immer wieder geführt. Für jede Diskussion gibt es eine Zeit und einen Ort. Imho, das ist es nicht mehr. Ich sage nicht, dass deine Meinung irrelevant ist, aber es wird nichts ändern.

Stabilität war schon immer der Schlüssel für ZSTD-on-ZFS und die Bereitstellung einer vertrauenswürdigen ZSTD-Quelle (die in Vergessenheit geraten ist) ist Teil dieser Stabilitätsgarantie.

Obwohl es großartig ist, dass Sie uns Ihre Meinung dazu mitteilen, wie wir dies erreichen könnten, hat ZSTD-on-ZFS die Designphase mittlerweile verlassen, und mit dem aktuellen Design gibt es keinen Vorteil bei der Verwendung von In-Kernel-ZSTD ....

Keine Sorge, ich wollte Sie nur wissen lassen, dass die Option jetzt verfügbar ist :)

Am Freitag, den 28. August 2020 um 11:22:21 -0700 schrieb Kjeld Schouten-Lebbing: @terrelln ZSTD wurde bereits implementiert, es gibt keine Pläne für die Verwendung von in-kernel zstd, Gespräche darüber sind seit Monaten abgeschlossen jetzt ... Wie auch immer: Im Wesentlichen geht es hier nicht wirklich um die ZSTD-Version, sondern um ZFS. ZSTD führt Prüfsummenbildung durch, selbst kompatible Versionen von ZSTD können zu leicht unterschiedlichen Prüfsummen führen, und wir müssen dies berücksichtigen. ZSTD muss auch viele verschiedene Plattformen unterstützen, sowohl auf Linux- als auch auf FreeBSD-Basis. Sich auf unterschiedliche Versionen von ZSTD im Kernel verlassen zu müssen, verkompliziert die Dinge bis zum n-ten Grad. Die aktuelle Implementierung von zstd auf zfs ist ziemlich solide, gut überprüft und dieser Fehler wurde bereits ohne große Probleme behoben. Obwohl es großartig ist, dass Sie uns Ihre Meinung dazu mitteilen, wie wir dies erreichen könnten, hat ZSTD-on-ZFS die Designphase inzwischen verlassen, und mit dem aktuellen Design gibt es keinen Vorteil bei der Verwendung von zstd im Kernel .... -- Sie erhalten dies, weil Sie erwähnt wurden. Antworten Sie direkt auf diese E-Mail oder sehen Sie sie auf GitHub an: #10763 (Kommentar)
Es gibt mindestens einen Vorteil: die Beseitigung von Doppelarbeit. zstd fügt dem ZFS-Kernel-Build etwa 0,5 MB hinzu. Danke.

Weißt du, was ein großer Nachteil ist? Die zstd-Variante im Kernel ist langsamer und da ihr die benutzerdefinierte Zuweisungsfunktion fehlt, ist sie unbrauchbar und funktioniert nicht. Wir haben einen speziellen benutzerdefinierten Allokator geschrieben, der die Gesamtleistung um ein Vielfaches erhöht. Ohne sie wird es die zfs-Tests nicht bestehen, da sie alle aus Leistungsgründen ablaufen. Daher gab es nie eine Option, die In-Kernel-Variante zu verwenden.

@BrainSlayer , danke, dass du auf das Hauptargument hingewiesen hast, das ich zu dumm war, um es vollständig zu verstehen/zu erklären! 👍

@Ornias1993 gib dir keine Vorwürfe. Ich frage mich eher, warum Leute solche Dinge anfordern, ohne ein bisschen tiefer zu recherchieren, worüber sie sprechen. Wenn der Kernel in Zukunft alle Features bereitstellt, könnte er eine Option für zukünftige Versionen sein, aber selbst dann wird nur ein Benchmark zeigen, ob es sich lohnt, dies weiterzuverfolgen

@Ornias1993 gib dir keine Vorwürfe. Ich frage mich eher, warum Leute solche Dinge anfordern, ohne ein bisschen tiefer zu recherchieren, worüber sie sprechen. Wenn der Kernel in Zukunft alle Features bereitstellt, könnte er eine Option für zukünftige Versionen sein, aber selbst dann wird nur ein Benchmark zeigen, ob es sich lohnt, dies weiterzuverfolgen

Guter Punkt, aber selbst in diesem Fall muss die ganze Menge anderer Probleme noch umgestaltet werden ... Ich sage nicht, dass es nie passieren wird, aber nicht in absehbarer Zeit (tm) ;)

Entschuldigung, ich hatte nicht die Absicht, hierher zu kommen und zu sagen, dass OpenZFS für Linux die Version von zstd im Kernel hätte verwenden sollen. Angesichts des Zustands von zstd im Kernel ist das Bündeln von Upstream-zstd definitiv die bessere Wahl. Ganz zu schweigen von der Komplexität der Verwendung von zwei inkompatiblen Versionen von zstd, einer für Linux und einer für BSDs.

Ich habe die Version in den Kernel geschrieben, bevor der Upstream-zstd bereit war, so wie er ist, verwendet zu werden, und ich war zu neu im Projekt, um alle Änderungen zu kennen, die erforderlich sind, um sie dorthin zu bringen. Jetzt, wie Sie mit OpenZFS bewiesen haben, kann zstd unverändert mit entweder ZSTD_customMem oder ZSTD_initStatic*() verwendet werden.

Weißt du, was ein großer Nachteil ist? Die zstd-Variante im Kernel ist langsamer und da ihr die benutzerdefinierte Zuweisungsfunktion fehlt, ist sie unbrauchbar und funktioniert nicht. Wir haben einen speziellen benutzerdefinierten Allokator geschrieben, der die Gesamtleistung um ein Vielfaches erhöht. Ohne sie wird es die zfs-Tests nicht bestehen, da sie alle aus Leistungsgründen ablaufen. Daher gab es nie eine Option, die In-Kernel-Variante zu verwenden.

Nur aus Interesse, womit vergleichst du? Vergleichen Sie mit der Zuweisung eines Kontexts für jeden (De-) Komprimierungsaufruf? Ich würde sicherlich glauben, dass das um ein Vielfaches langsamer ist. Der Ansatz der benutzerdefinierten Zuweisung scheint dem Ansatz ähnlich zu sein, den btrfs zum Beispiel beim Zwischenspeichern von Arbeitsbereichen verfolgt hat, und ich würde eine ähnliche Leistung erwarten.

Wenn Sie sich den Code in zfs_zstd.c , können Sie möglicherweise eine kleine Menge an Komprimierungsleistung erzielen, indem Sie die ZSTD_CCtx -Objekte zwischenspeichern. Wenn Sie ein ZSTD_CCtx wiederverwenden, müssen seine Tabellen nicht auf Null gesetzt werden, wodurch ein ~100-KB-Memset auf Ebene 3 gespeichert wird. Dies führt zu der Komplexität des Zwischenspeicherns der ZSTD_CCtx -Objekte, also haben Sie es vielleicht schon getan berücksichtigt und aufgrund der architektonischen Komplexität ausgeschlossen.

Wenn ich zstd im Kernel aktualisiere, aktualisiere ich btrfs, um Kontexte wiederzuverwenden, anstatt nur den Arbeitsspeicher. An diesem Punkt werde ich den Geschwindigkeitsunterschied sorgfältig messen, aber ich würde einen Gewinn von nicht mehr als 10% bei niedrigen Pegeln schätzen, wahrscheinlich eher 3-5%.

Wenn der Kernel in Zukunft alle Features bereitstellt, könnte er eine Option für zukünftige Versionen sein, aber selbst dann wird nur ein Benchmark zeigen, ob es sich lohnt, dies weiterzuverfolgen

Ich arbeite daran, zstd-1.4.6 (nächste Version) so zu portieren, wie es im Kernel ist, und es trivial zu machen, auf dem neuesten Stand zu bleiben. Es wird mit allen Funktionen ausgestattet sein und Upstream wie OpenZFS direkt verwenden. Es sollte also identische Leistung haben. Es gäbe keinen guten Grund für einen Wechsel, da das Bündeln von zstd bereits funktioniert und wahrscheinlich etwas zusätzliche Komplexität aufweist, aber die Option wird bei Bedarf vorhanden sein.

Wenn es irgendetwas gibt, das das OpenZFS-Projekt von zstd braucht/wünscht, lassen Sie es mich bitte wissen/eröffnen Sie ein Problem.

Entschuldigung, ich hatte nicht die Absicht, hierher zu kommen und zu sagen, dass OpenZFS für Linux die Version von zstd im Kernel hätte verwenden sollen. Angesichts des Zustands von zstd im Kernel ist das Bündeln von Upstream-zstd definitiv die bessere Wahl. Ganz zu schweigen von der Komplexität der Verwendung von zwei inkompatiblen Versionen von zstd, einer für Linux und einer für BSDs.

Ich habe die Version in den Kernel geschrieben, bevor der Upstream-zstd bereit war, so wie er ist, verwendet zu werden, und ich war zu neu im Projekt, um alle Änderungen zu kennen, die erforderlich sind, um sie dorthin zu bringen. Jetzt, wie Sie mit OpenZFS bewiesen haben, kann zstd unverändert mit entweder ZSTD_customMem oder ZSTD_initStatic*() verwendet werden.

Weißt du, was ein großer Nachteil ist? Die zstd-Variante im Kernel ist langsamer und da ihr die benutzerdefinierte Zuweisungsfunktion fehlt, ist sie unbrauchbar und funktioniert nicht. Wir haben einen speziellen benutzerdefinierten Allokator geschrieben, der die Gesamtleistung um ein Vielfaches erhöht. Ohne sie wird es die zfs-Tests nicht bestehen, da sie alle aus Leistungsgründen ablaufen. Daher gab es nie eine Option, die In-Kernel-Variante zu verwenden.

Nur aus Interesse, womit vergleichst du? Vergleichen Sie mit der Zuweisung eines Kontexts für jeden (De-) Komprimierungsaufruf? Ich würde sicherlich glauben, dass das um ein Vielfaches langsamer ist. Der Ansatz der benutzerdefinierten Zuweisung scheint dem Ansatz ähnlich zu sein, den btrfs zum Beispiel beim Zwischenspeichern von Arbeitsbereichen verfolgt hat, und ich würde eine ähnliche Leistung erwarten.

Wenn Sie sich den Code in zfs_zstd.c , können Sie möglicherweise eine kleine Menge an Komprimierungsleistung erzielen, indem Sie die ZSTD_CCtx -Objekte zwischenspeichern. Wenn Sie ein ZSTD_CCtx wiederverwenden, müssen seine Tabellen nicht auf Null gesetzt werden, wodurch ein ~100-KB-Memset auf Ebene 3 gespeichert wird. Dies führt zu der Komplexität des Zwischenspeicherns der ZSTD_CCtx -Objekte, also haben Sie es vielleicht schon getan berücksichtigt und aufgrund der architektonischen Komplexität ausgeschlossen.

Wenn ich zstd im Kernel aktualisiere, aktualisiere ich btrfs, um Kontexte wiederzuverwenden, anstatt nur den Arbeitsspeicher. An diesem Punkt werde ich den Geschwindigkeitsunterschied sorgfältig messen, aber ich würde einen Gewinn von nicht mehr als 10% bei niedrigen Pegeln schätzen, wahrscheinlich eher 3-5%.

Wenn der Kernel in Zukunft alle Features bereitstellt, könnte er eine Option für zukünftige Versionen sein, aber selbst dann wird nur ein Benchmark zeigen, ob es sich lohnt, dies weiterzuverfolgen

Ich arbeite daran, zstd-1.4.6 (nächste Version) so zu portieren, wie es im Kernel ist, und es trivial zu machen, auf dem neuesten Stand zu bleiben. Es wird mit allen Funktionen ausgestattet sein und Upstream wie OpenZFS direkt verwenden. Es sollte also identische Leistung haben. Es gäbe keinen guten Grund für einen Wechsel, da das Bündeln von zstd bereits funktioniert und wahrscheinlich etwas zusätzliche Komplexität aufweist, aber die Option wird bei Bedarf vorhanden sein.

Wenn es irgendetwas gibt, das das OpenZFS-Projekt von zstd braucht/wünscht, lassen Sie es mich bitte wissen/eröffnen Sie ein Problem.

Nein, wir ordnen Dekomprimierung und Komprimierung keinen neuen Kontext zu. Der Zuordner erstellt einen multithreadsicheren Speicherzuweisungspool, der Objekte selbst freigibt, wenn sie nicht verwendet werden, und Zuweisungen auf eigene Weise zwischenspeichert. Dekomprimierung ist kein großes Problem, da der Kontext für die Dekomprimierung klein ist, aber wir cachen es auch aus Leistungsgründen. Der Komprimierungskontext ist das Problem, da er sehr groß sein kann. mit hoher Komprimierungsrate (19) sind es etwa 80 MB pro Thread und zfs arbeitet multithreaded. Auf einem Standard-8-Core-System laufen 32 Threads gleichzeitig. Dies ist ein Problem für die Zuweisung (die Zuweisung großer Blöcke ist selbst mit Standardkomprimierungseinstellungen nur langsam). Der Slab-Cache hilft auch nicht. 1. Der maximal zuordenbare Speicher ist in der zfs-Implementierung begrenzt. und wenn wir dieses Limit aufheben, ist es immer noch langsamer als unser eigener Speicherpool-Ansatz. dieser Speicherpool ist ebenfalls eine sehr spezialisierte Implementierung, die nur für zstd erstellt wurde, und zeigt die beste Leistung aller Lösungen. Der Ansatz besteht grundsätzlich darin, den Kontext wann immer möglich wiederzuverwenden und Zuweisungen zur Standardlaufzeit zu vermeiden. also ja. Standard-Allokationspool-Ansatz, nur schneller als jede von uns getestete Standardlösung. aber wie auch immer. Sobald Sie Ihre Upstream-Arbeit im Kernel abgeschlossen haben, werde ich sie überprüfen und auch einen Leistungsvergleich durchführen. Bedenken Sie, dass unsere zstd-Implementierung statisch kompiliert wird, da der gesamte Quellcode mit explizitem -O3 kombiniert wird, wie es die ursprüngliche Bibliothek tut. Dadurch kann der Compiler den Code viel besser optimieren als jede modulare Quellvariante. Das Kompilieren eines voll funktionsfähigen zstd in den Kernel ist ebenfalls nicht möglich, da einige Funktionen von zstd eine Stack-Nutzung von > 20 KB haben. Dies ist nicht Kernel-Code-kompatibel. Wir verwenden diese Funktionen nicht in unserem Code, aber dies muss von Ihnen berücksichtigt werden

@BrainSlayer gute Anmerkung zur Stapelgröße, es war einer der wenigen Aspekte von zstd, die wir nicht wirklich mochten (obwohl wir diese Codepfade nicht verwenden)

@terrelln willst du dafür ein Problem im zstd-Projekt?

@Ornias1993 Das Stapelproblem kann behoben werden, verringert jedoch normalerweise die Leistung. aber vielleicht gibt es auch eine bessere Lösung für diese Hufman-Tabellen-Makro-Hölle auf dem lokalen Stack

aber vielleicht gibt es auch eine bessere Lösung für diese Hufman-Tabellen-Makro-Hölle auf dem lokalen Stack

Deshalb frage ich, ob er eine Ausgabe dafür haben möchte ;)

Nein, wir weisen Dekomprimierung und Komprimierung keinen neuen Kontext zu.

Ich weiß, dass Sie den Kontextspeicher in Ihrem Zuordner wiederverwenden. Ich meine die Erstellung des zstd-Kontextes selbst in dieser Zeile https://github.com/openzfs/zfs/blob/abe4fbfd01c2440813c9f31ca6727473e22d0039/module/zstd/zfs_zstd.c#L365
Wenn Sie das ZSTD_CCtx -Objekt selbst zwischenspeichern und wiederverwenden, vermeiden Sie ein ~100-KB-memset() auf Ebene 3 innerhalb von zstd bei nachfolgenden Verwendungen von ZSTD_CCtx mit denselben Parametern. Dies ist ein viel kleinerer Deal als die Zuteilung, denn wie Sie sagten, ist die Zuteilung kostspielig. Aber ich vermute, es würde sich in der Komprimierungsleistung zeigen und wahrscheinlich etwa 3-5% der Komprimierungs-CPU kosten. Mir wurde klar, dass ich bei dieser Leistungsbewertung 128-KB-Blöcke annehme, aber ich bin mir nicht sicher, ob das für ZFS richtig ist. Je größer die Blockgröße, desto weniger spielt dies eine Rolle.

Bedenken Sie, dass unsere zstd-Implementierung statisch kompiliert wird, da der gesamte Quellcode mit explizitem -O3 kombiniert wird, wie es die ursprüngliche Bibliothek tut. Dadurch kann der Compiler den Code viel besser optimieren als jede modulare Quellvariante

Der Linux-Kernel kompiliert zstd auch mit -O3 . Ich glaube, ich weiß nicht ganz, was Sie hier sagen. Zstd hat keine Cross-Translation-Unit-Funktionsaufrufe in seinen Hot Loops. Tatsächlich hat zstd keine heißen Funktionsaufrufe in seinen heißen Schleifen, alles sollte inline sein (oder es ist kalt). Es sollte also keinen Vorteil bringen, mehrere .c -Dateien zu einer zu kombinieren, oder von LTO.

Das Kompilieren eines voll funktionsfähigen zstd in den Kernel ist ebenfalls nicht möglich, da einige Funktionen von zstd eine Stack-Nutzung von > 20 KB haben. Dies ist nicht Kernel-Code-kompatibel.

Diese Funktionen werden von zstd nicht benötigt. Es gibt eine Reihe von Funktionen in huf_compress.c , huf_decompress.c , fse_compress.c und fse_decompress.c , die von zstd überhaupt nicht verwendet werden. Sie sind vorhanden, weil diese Dateien aus dem FiniteStateEntropy-Projekt stammen. Dies ist jedoch ein Problem für den Kernel, da dies Build-Warnungen auslöst, obwohl die Funktionen nicht verwendet werden. Also füge ich in https://github.com/facebook/zstd/pull/2289 ZSTD_NO_UNUSED_FUNCTIONS hinzu, was diese Funktionen verbirgt. Sie können das also in der nächsten zstd-Version definieren, um diese Funktionen auszublenden. Nachdem dieses Makro definiert ist, hat zstd keine Funktionen, die mehr als 2 KB Stapelspeicherplatz verwenden.

In diesem PR habe ich auch einen Test hinzugefügt, der die tatsächliche Stack-High-Watermark für zstd (in den bestehenden Kernel-Anwendungsfällen) misst. Nachdem ich die Nutzung des Komprimierungsstacks in diesem PR um 1 KB reduziert hatte, habe ich gemessen, dass die Komprimierung ~ 2 KB Stack-Speicherplatz und die Dekomprimierung ~ 1 KB Stack-Speicherplatz benötigt. Dies könnte durch einige weitere Arbeiten weiter reduziert werden.

@Ornias1993 Wenn Sie ein Problem eröffnen möchten, wäre das großartig. Es wäre ein guter Ort, um sicherzustellen, dass diese Antworten nicht verloren gehen, und eine Erinnerung daran, die neuen Build-Makros zu verwenden, wenn wir die nächste zstd-Version veröffentlichen. Ich möchte auch die tatsächliche Stack-Nutzung von zstd weiter reduzieren.

@Ornias1993 Das Stapelproblem kann behoben werden, verringert jedoch normalerweise die Leistung. aber vielleicht gibt es auch eine bessere Lösung für diese Hufman-Tabellen-Makro-Hölle auf dem lokalen Stack

Um es klarzustellen, dies sind die Funktionen, die von zstd vollständig nicht verwendet werden. Wir verwenden "Workspace"-Varianten dieser Funktionen, um die Nutzung großer Stacks zu vermeiden. Wir ordnen etwas Platz in ZSTD_CCtx und ZSTD_DCtx einmal zu und verwenden ihn als Scratch-Speicherplatz anstelle des Stapels.

Ich werde prüfen, ob die Wiederverwendung des gesamten Kontextobjekts funktioniert. Normalerweise verfolgt der Kontext den aktuellen Komprimierungsfluss / -status, daher ist es für mich merkwürdig, dass er funktioniert, ohne ihn bei der Wiederverwendung zu löschen

@BrainSlayer Wenn es klappt, ruf mich an und ich mache die Leistungstests auch noch einmal :)
3-5% könnten ziemlich interessant sein :)

@terrelln Tolle Änderung ZSTD_NO_UNUSED_FUNCTIONS ist sicherlich etwas, das wir auch für ZFS verwenden wollen 👍

@ Ornias1993 Wenn ich es tue, werde ich nur die Init-Funktionen neu implementieren, um den Mempool allgemeiner zu halten. aber ich glaube nicht, dass es funktioniert, ohne den Kontext zu löschen

Ich werde prüfen, ob die Wiederverwendung des gesamten Kontextobjekts funktioniert. Normalerweise verfolgt der Kontext den aktuellen Komprimierungsfluss / -status, daher ist es für mich merkwürdig, dass er funktioniert, ohne ihn bei der Wiederverwendung zu löschen

Wenn ich mich richtig erinnere, gibt es eine ZSTD-API zum "Zurücksetzen" eines CCtx, um es wiederverwenden zu können. Es müssen nur ein paar Felder zurückgesetzt werden, um es sicher zu machen, anstatt das gesamte CCtx einzurichten.

Es war eine der Optimierungen, die ich mir ansehen wollte, sobald ich den Rest der Bootloader-Bits erledigt habe usw.

Ich werde prüfen, ob die Wiederverwendung des gesamten Kontextobjekts funktioniert. Normalerweise verfolgt der Kontext den aktuellen Komprimierungsfluss / -status, daher ist es für mich merkwürdig, dass er funktioniert, ohne ihn bei der Wiederverwendung zu löschen

Für die Komprimierung verwenden wir Indextabellen in den komprimierten Daten, um Übereinstimmungen zu finden. Diese Tabellen beginnen mit dem Wert von 0 . Nachdem wir Daten von beispielsweise 5000 Bytes komprimiert haben, ist der maximale Wert 4999 . Der nächste Komprimierungsaufruf kann also Einträge unter 5000 "ungültig machen", anstatt die Tabellen neu auf Null zu setzen. Die Kontextwiederverwendung erzeugt Byte-identische Ausgaben für Single-Use-Kontexte, es handelt sich lediglich um eine Optimierung.

Sobald ich den Rest der Bootloader-Bits erledigt habe usw.

Es ist ein bisschen Offtopic im Offtopic, aber wie läuft die Bootloader-Arbeit eigentlich? :)

@Ornias1993 Bootloader? Ich weiß, dass Freebsd einen eigenen Bootloader verwendet. Der Grub-Patch, den ich gemacht habe, funktioniert

@BrainSlayer Warum fragst du mich? Frag Allan, es ist seine Arbeit, nicht meine. Schätze, er ist mehr als qualifiziert, es viel besser zu erklären, als ich es verstehe;)

@Ornias1993 , weil Sie auf ein Projekt verwiesen haben, das für mich neu ist

@BrainSlayer : @Ornias1993 antwortete @allanjude und brachte es zur Sprache:

Es war eine der Optimierungen, die ich mir ansehen wollte, sobald ich den Rest der Bootloader-Bits erledigt habe usw.

Ich ging also davon aus, dass Allan daran arbeitet, und selbst wenn ich keine Ahnung hätte, wer er war, würde ein kurzer Blick auf sein Profilbild mich vermuten lassen, dass diese Arbeit mit BSD zu tun hat. :zwinkern:

@mschilli87 Alan sprach von einem Bootloader. Ich sehe nicht, dass dies mit einer Optimierung zusammenhängt

@BrainSlayer :

alan[sic!] sprach von einem Bootloader. Ich sehe nicht, dass dies mit einer Optimierung zusammenhängt

Allan gab Input zur „Reuse-Context-Optimierung“ und verwies Sie auf den API-Teil zum Zurücksetzen eines CCtx , da er dies auf seiner Liste potenzieller zukünftiger Verbesserungen hatte. Er erwähnte nur die Bootloader-Arbeit als Grund dafür, dass er nicht früher dazu kam, und @Ornias1993 ging nicht auf eine Tangente, weil er daran interessiert ist (unabhängig von ZST in ZFS-Optimierungen). Er hat seinen Kommentar auch eindeutig als Off-Topic gekennzeichnet.
Mit einer schnellen Suche könnten Sie feststellen, dass dies schon einmal auf einer PR auftauchte , mit der Sie wahrscheinlich sehr vertraut sind. :zwinkern:

Also nein: Der Bootloader hat nichts mit der Optimierung zu tun, außer dass @allanjude über beide nachdenkt und das eine erwähnt, wenn es um das andere geht, aber @Ornias1993 war trotzdem interessiert und ging weiter. Dann schienen Sie an dieser Tangente interessiert / verwirrt zu sein und baten @Ornias1993 , Ihnen genau die Details zu geben, die er gerade von @allenjude erfragt hatte , und ich habe einfach versucht, Sie auf den Kontext hinzuweisen, von dem ich dachte, dass Sie ihn beim Lesen dieses Threads übersehen haben müssen.

Es tut mir leid, wenn ich weiter zu Ihrer Verwirrung beigetragen habe, aber soweit ich verstehe, können Sie das Bootloader-Thema getrost ignorieren, es sei denn, Sie interessieren sich unabhängig von Ihrem Interesse an der Optimierung von ZST auf ZFS (wie es anscheinend @allanjude und @Ornias1993 tun). :leicht_lächelndes_gesicht:

@mschilli87 Wie immer: Du hast den Tag kommentiert und mein Tag hat gerade erst begonnen :)

@BrainSlayer SLight Nekro:
Haben Sie schon versucht, den Kontext wiederzuverwenden?

@Ornias1993 das macht der Mempool am Ende. Ich habe keinen Code gefunden, der auf die aktuelle Art und Weise, wie wir es tun, zu Leistungseinbußen führt. Wir verwenden bereits zugewiesene Objekte wieder. Wir löschen den Speicher bei der Wiederverwendung nicht. Es ist kein Memset fertig

@BrainSlayer Danke für die Klarheit, ich habe in meinem Kopf eine Auswahlliste für ZSTD-Todos erstellt, gut zu wissen, dass dies definitiv als gelöst angesehen wird.