2008-11-20 23:01:55 +03:00
|
|
|
/*
|
|
|
|
* CDDL HEADER START
|
|
|
|
*
|
|
|
|
* The contents of this file are subject to the terms of the
|
|
|
|
* Common Development and Distribution License (the "License").
|
|
|
|
* You may not use this file except in compliance with the License.
|
|
|
|
*
|
|
|
|
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
|
2022-07-12 00:16:13 +03:00
|
|
|
* or https://opensource.org/licenses/CDDL-1.0.
|
2008-11-20 23:01:55 +03:00
|
|
|
* See the License for the specific language governing permissions
|
|
|
|
* and limitations under the License.
|
|
|
|
*
|
|
|
|
* When distributing Covered Code, include this CDDL HEADER in each
|
|
|
|
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
|
|
|
|
* If applicable, add the following below this CDDL HEADER, with the
|
|
|
|
* fields enclosed by brackets "[]" replaced with your own identifying
|
|
|
|
* information: Portions Copyright [yyyy] [name of copyright owner]
|
|
|
|
*
|
|
|
|
* CDDL HEADER END
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2010-05-29 00:45:14 +04:00
|
|
|
* Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.
|
2011-11-08 04:26:52 +04:00
|
|
|
* Copyright 2011 Nexenta Systems, Inc. All rights reserved.
|
2024-04-22 19:42:38 +03:00
|
|
|
* Copyright (c) 2012, 2024 by Delphix. All rights reserved.
|
2013-01-23 13:54:30 +04:00
|
|
|
* Copyright (c) 2013 by Saso Kiselkov. All rights reserved.
|
2017-04-13 19:40:00 +03:00
|
|
|
* Copyright (c) 2013, Joyent, Inc. All rights reserved.
|
|
|
|
* Copyright 2016 Toomas Soome <tsoome@me.com>
|
Add zstd support to zfs
This PR adds two new compression types, based on ZStandard:
- zstd: A basic ZStandard compression algorithm Available compression.
Levels for zstd are zstd-1 through zstd-19, where the compression
increases with every level, but speed decreases.
- zstd-fast: A faster version of the ZStandard compression algorithm
zstd-fast is basically a "negative" level of zstd. The compression
decreases with every level, but speed increases.
Available compression levels for zstd-fast:
- zstd-fast-1 through zstd-fast-10
- zstd-fast-20 through zstd-fast-100 (in increments of 10)
- zstd-fast-500 and zstd-fast-1000
For more information check the man page.
Implementation details:
Rather than treat each level of zstd as a different algorithm (as was
done historically with gzip), the block pointer `enum zio_compress`
value is simply zstd for all levels, including zstd-fast, since they all
use the same decompression function.
The compress= property (a 64bit unsigned integer) uses the lower 7 bits
to store the compression algorithm (matching the number of bits used in
a block pointer, as the 8th bit was borrowed for embedded block
pointers). The upper bits are used to store the compression level.
It is necessary to be able to determine what compression level was used
when later reading a block back, so the concept used in LZ4, where the
first 32bits of the on-disk value are the size of the compressed data
(since the allocation is rounded up to the nearest ashift), was
extended, and we store the version of ZSTD and the level as well as the
compressed size. This value is returned when decompressing a block, so
that if the block needs to be recompressed (L2ARC, nop-write, etc), that
the same parameters will be used to result in the matching checksum.
All of the internal ZFS code ( `arc_buf_hdr_t`, `objset_t`,
`zio_prop_t`, etc.) uses the separated _compress and _complevel
variables. Only the properties ZAP contains the combined/bit-shifted
value. The combined value is split when the compression_changed_cb()
callback is called, and sets both objset members (os_compress and
os_complevel).
The userspace tools all use the combined/bit-shifted value.
Additional notes:
zdb can now also decode the ZSTD compression header (flag -Z) and
inspect the size, version and compression level saved in that header.
For each record, if it is ZSTD compressed, the parameters of the decoded
compression header get printed.
ZSTD is included with all current tests and new tests are added
as-needed.
Per-dataset feature flags now get activated when the property is set.
If a compression algorithm requires a feature flag, zfs activates the
feature when the property is set, rather than waiting for the first
block to be born. This is currently only used by zstd but can be
extended as needed.
Portions-Sponsored-By: The FreeBSD Foundation
Co-authored-by: Allan Jude <allanjude@freebsd.org>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Co-authored-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Allan Jude <allanjude@freebsd.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Closes #6247
Closes #9024
Closes #10277
Closes #10278
2020-08-18 20:10:17 +03:00
|
|
|
* Copyright (c) 2019, Allan Jude
|
2024-04-04 14:34:42 +03:00
|
|
|
* Copyright (c) 2019, 2023, 2024, Klara Inc.
|
Add zstd support to zfs
This PR adds two new compression types, based on ZStandard:
- zstd: A basic ZStandard compression algorithm Available compression.
Levels for zstd are zstd-1 through zstd-19, where the compression
increases with every level, but speed decreases.
- zstd-fast: A faster version of the ZStandard compression algorithm
zstd-fast is basically a "negative" level of zstd. The compression
decreases with every level, but speed increases.
Available compression levels for zstd-fast:
- zstd-fast-1 through zstd-fast-10
- zstd-fast-20 through zstd-fast-100 (in increments of 10)
- zstd-fast-500 and zstd-fast-1000
For more information check the man page.
Implementation details:
Rather than treat each level of zstd as a different algorithm (as was
done historically with gzip), the block pointer `enum zio_compress`
value is simply zstd for all levels, including zstd-fast, since they all
use the same decompression function.
The compress= property (a 64bit unsigned integer) uses the lower 7 bits
to store the compression algorithm (matching the number of bits used in
a block pointer, as the 8th bit was borrowed for embedded block
pointers). The upper bits are used to store the compression level.
It is necessary to be able to determine what compression level was used
when later reading a block back, so the concept used in LZ4, where the
first 32bits of the on-disk value are the size of the compressed data
(since the allocation is rounded up to the nearest ashift), was
extended, and we store the version of ZSTD and the level as well as the
compressed size. This value is returned when decompressing a block, so
that if the block needs to be recompressed (L2ARC, nop-write, etc), that
the same parameters will be used to result in the matching checksum.
All of the internal ZFS code ( `arc_buf_hdr_t`, `objset_t`,
`zio_prop_t`, etc.) uses the separated _compress and _complevel
variables. Only the properties ZAP contains the combined/bit-shifted
value. The combined value is split when the compression_changed_cb()
callback is called, and sets both objset members (os_compress and
os_complevel).
The userspace tools all use the combined/bit-shifted value.
Additional notes:
zdb can now also decode the ZSTD compression header (flag -Z) and
inspect the size, version and compression level saved in that header.
For each record, if it is ZSTD compressed, the parameters of the decoded
compression header get printed.
ZSTD is included with all current tests and new tests are added
as-needed.
Per-dataset feature flags now get activated when the property is set.
If a compression algorithm requires a feature flag, zfs activates the
feature when the property is set, rather than waiting for the first
block to be born. This is currently only used by zstd but can be
extended as needed.
Portions-Sponsored-By: The FreeBSD Foundation
Co-authored-by: Allan Jude <allanjude@freebsd.org>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Co-authored-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Allan Jude <allanjude@freebsd.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Closes #6247
Closes #9024
Closes #10277
Closes #10278
2020-08-18 20:10:17 +03:00
|
|
|
* Copyright (c) 2019-2020, Michael Niewöhner
|
2019-09-10 23:34:53 +03:00
|
|
|
* Copyright (c) 2024 by George Melikov. All rights reserved.
|
2011-11-08 04:26:52 +04:00
|
|
|
*/
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
#ifndef _ZIO_H
|
|
|
|
#define _ZIO_H
|
|
|
|
|
2015-12-22 04:31:57 +03:00
|
|
|
#include <sys/zio_priority.h>
|
2008-11-20 23:01:55 +03:00
|
|
|
#include <sys/zfs_context.h>
|
|
|
|
#include <sys/spa.h>
|
|
|
|
#include <sys/txg.h>
|
|
|
|
#include <sys/avl.h>
|
|
|
|
#include <sys/fs/zfs.h>
|
|
|
|
#include <sys/zio_impl.h>
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
/*
|
|
|
|
* Embedded checksum
|
|
|
|
*/
|
|
|
|
#define ZEC_MAGIC 0x210da7ab10c7a11ULL
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
typedef struct zio_eck {
|
|
|
|
uint64_t zec_magic; /* for validation, endianness */
|
|
|
|
zio_cksum_t zec_cksum; /* 256-bit checksum */
|
|
|
|
} zio_eck_t;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Gang block headers are self-checksumming and contain an array
|
|
|
|
* of block pointers.
|
|
|
|
*/
|
|
|
|
#define SPA_GANGBLOCKSIZE SPA_MINBLOCKSIZE
|
|
|
|
#define SPA_GBH_NBLKPTRS ((SPA_GANGBLOCKSIZE - \
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (zio_eck_t)) / sizeof (blkptr_t))
|
2008-11-20 23:01:55 +03:00
|
|
|
#define SPA_GBH_FILLER ((SPA_GANGBLOCKSIZE - \
|
2010-05-29 00:45:14 +04:00
|
|
|
sizeof (zio_eck_t) - \
|
2008-11-20 23:01:55 +03:00
|
|
|
(SPA_GBH_NBLKPTRS * sizeof (blkptr_t))) /\
|
|
|
|
sizeof (uint64_t))
|
|
|
|
|
|
|
|
typedef struct zio_gbh {
|
|
|
|
blkptr_t zg_blkptr[SPA_GBH_NBLKPTRS];
|
|
|
|
uint64_t zg_filler[SPA_GBH_FILLER];
|
2010-05-29 00:45:14 +04:00
|
|
|
zio_eck_t zg_tail;
|
2008-11-20 23:01:55 +03:00
|
|
|
} zio_gbh_phys_t;
|
|
|
|
|
|
|
|
enum zio_checksum {
|
|
|
|
ZIO_CHECKSUM_INHERIT = 0,
|
|
|
|
ZIO_CHECKSUM_ON,
|
|
|
|
ZIO_CHECKSUM_OFF,
|
|
|
|
ZIO_CHECKSUM_LABEL,
|
|
|
|
ZIO_CHECKSUM_GANG_HEADER,
|
|
|
|
ZIO_CHECKSUM_ZILOG,
|
|
|
|
ZIO_CHECKSUM_FLETCHER_2,
|
|
|
|
ZIO_CHECKSUM_FLETCHER_4,
|
|
|
|
ZIO_CHECKSUM_SHA256,
|
2010-05-29 00:45:14 +04:00
|
|
|
ZIO_CHECKSUM_ZILOG2,
|
2016-06-16 01:47:05 +03:00
|
|
|
ZIO_CHECKSUM_NOPARITY,
|
|
|
|
ZIO_CHECKSUM_SHA512,
|
|
|
|
ZIO_CHECKSUM_SKEIN,
|
|
|
|
ZIO_CHECKSUM_EDONR,
|
Introduce BLAKE3 checksums as an OpenZFS feature
This commit adds BLAKE3 checksums to OpenZFS, it has similar
performance to Edon-R, but without the caveats around the latter.
Homepage of BLAKE3: https://github.com/BLAKE3-team/BLAKE3
Wikipedia: https://en.wikipedia.org/wiki/BLAKE_(hash_function)#BLAKE3
Short description of Wikipedia:
BLAKE3 is a cryptographic hash function based on Bao and BLAKE2,
created by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and
Zooko Wilcox-O'Hearn. It was announced on January 9, 2020, at Real
World Crypto. BLAKE3 is a single algorithm with many desirable
features (parallelism, XOF, KDF, PRF and MAC), in contrast to BLAKE
and BLAKE2, which are algorithm families with multiple variants.
BLAKE3 has a binary tree structure, so it supports a practically
unlimited degree of parallelism (both SIMD and multithreading) given
enough input. The official Rust and C implementations are
dual-licensed as public domain (CC0) and the Apache License.
Along with adding the BLAKE3 hash into the OpenZFS infrastructure a
new benchmarking file called chksum_bench was introduced. When read
it reports the speed of the available checksum functions.
On Linux: cat /proc/spl/kstat/zfs/chksum_bench
On FreeBSD: sysctl kstat.zfs.misc.chksum_bench
This is an example output of an i3-1005G1 test system with Debian 11:
implementation 1k 4k 16k 64k 256k 1m 4m
edonr-generic 1196 1602 1761 1749 1762 1759 1751
skein-generic 546 591 608 615 619 612 616
sha256-generic 240 300 316 314 304 285 276
sha512-generic 353 441 467 476 472 467 426
blake3-generic 308 313 313 313 312 313 312
blake3-sse2 402 1289 1423 1446 1432 1458 1413
blake3-sse41 427 1470 1625 1704 1679 1607 1629
blake3-avx2 428 1920 3095 3343 3356 3318 3204
blake3-avx512 473 2687 4905 5836 5844 5643 5374
Output on Debian 5.10.0-10-amd64 system: (Ryzen 7 5800X)
implementation 1k 4k 16k 64k 256k 1m 4m
edonr-generic 1840 2458 2665 2719 2711 2723 2693
skein-generic 870 966 996 992 1003 1005 1009
sha256-generic 415 442 453 455 457 457 457
sha512-generic 608 690 711 718 719 720 721
blake3-generic 301 313 311 309 309 310 310
blake3-sse2 343 1865 2124 2188 2180 2181 2186
blake3-sse41 364 2091 2396 2509 2463 2482 2488
blake3-avx2 365 2590 4399 4971 4915 4802 4764
Output on Debian 5.10.0-9-powerpc64le system: (POWER 9)
implementation 1k 4k 16k 64k 256k 1m 4m
edonr-generic 1213 1703 1889 1918 1957 1902 1907
skein-generic 434 492 520 522 511 525 525
sha256-generic 167 183 187 188 188 187 188
sha512-generic 186 216 222 221 225 224 224
blake3-generic 153 152 154 153 151 153 153
blake3-sse2 391 1170 1366 1406 1428 1426 1414
blake3-sse41 352 1049 1212 1174 1262 1258 1259
Output on Debian 5.10.0-11-arm64 system: (Pi400)
implementation 1k 4k 16k 64k 256k 1m 4m
edonr-generic 487 603 629 639 643 641 641
skein-generic 271 299 303 308 309 309 307
sha256-generic 117 127 128 130 130 129 130
sha512-generic 145 165 170 172 173 174 175
blake3-generic 81 29 71 89 89 89 89
blake3-sse2 112 323 368 379 380 371 374
blake3-sse41 101 315 357 368 369 364 360
Structurally, the new code is mainly split into these parts:
- 1x cross platform generic c variant: blake3_generic.c
- 4x assembly for X86-64 (SSE2, SSE4.1, AVX2, AVX512)
- 2x assembly for ARMv8 (NEON converted from SSE2)
- 2x assembly for PPC64-LE (POWER8 converted from SSE2)
- one file for switching between the implementations
Note the PPC64 assembly requires the VSX instruction set and the
kfpu_begin() / kfpu_end() calls on PowerPC were updated accordingly.
Reviewed-by: Felix Dörre <felix@dogcraft.de>
Reviewed-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Tino Reichardt <milky-zfs@mcmilk.de>
Co-authored-by: Rich Ercolani <rincebrain@gmail.com>
Closes #10058
Closes #12918
2022-06-09 01:55:57 +03:00
|
|
|
ZIO_CHECKSUM_BLAKE3,
|
2008-11-20 23:01:55 +03:00
|
|
|
ZIO_CHECKSUM_FUNCTIONS
|
|
|
|
};
|
|
|
|
|
2014-06-06 01:19:08 +04:00
|
|
|
/*
|
|
|
|
* The number of "legacy" compression functions which can be set on individual
|
|
|
|
* objects.
|
|
|
|
*/
|
|
|
|
#define ZIO_CHECKSUM_LEGACY_FUNCTIONS ZIO_CHECKSUM_ZILOG2
|
|
|
|
|
2009-07-03 02:44:48 +04:00
|
|
|
#define ZIO_CHECKSUM_ON_VALUE ZIO_CHECKSUM_FLETCHER_4
|
2008-11-20 23:01:55 +03:00
|
|
|
#define ZIO_CHECKSUM_DEFAULT ZIO_CHECKSUM_ON
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
#define ZIO_CHECKSUM_MASK 0xffULL
|
2021-10-11 20:58:06 +03:00
|
|
|
#define ZIO_CHECKSUM_VERIFY (1U << 8)
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
#define ZIO_DEDUPCHECKSUM ZIO_CHECKSUM_SHA256
|
|
|
|
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
/* macros defining encryption lengths */
|
|
|
|
#define ZIO_OBJSET_MAC_LEN 32
|
|
|
|
#define ZIO_DATA_IV_LEN 12
|
|
|
|
#define ZIO_DATA_SALT_LEN 8
|
|
|
|
#define ZIO_DATA_MAC_LEN 16
|
|
|
|
|
2014-06-06 01:19:08 +04:00
|
|
|
/*
|
|
|
|
* The number of "legacy" compression functions which can be set on individual
|
|
|
|
* objects.
|
|
|
|
*/
|
|
|
|
#define ZIO_COMPRESS_LEGACY_FUNCTIONS ZIO_COMPRESS_LZ4
|
|
|
|
|
2015-07-06 04:55:32 +03:00
|
|
|
/*
|
|
|
|
* The meaning of "compress = on" selected by the compression features enabled
|
|
|
|
* on a given pool.
|
|
|
|
*/
|
|
|
|
#define ZIO_COMPRESS_LEGACY_ON_VALUE ZIO_COMPRESS_LZJB
|
|
|
|
#define ZIO_COMPRESS_LZ4_ON_VALUE ZIO_COMPRESS_LZ4
|
|
|
|
|
2022-03-03 21:43:38 +03:00
|
|
|
#define ZIO_COMPRESS_DEFAULT ZIO_COMPRESS_ON
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
#define BOOTFS_COMPRESS_VALID(compress) \
|
|
|
|
((compress) == ZIO_COMPRESS_LZJB || \
|
2013-01-23 13:54:30 +04:00
|
|
|
(compress) == ZIO_COMPRESS_LZ4 || \
|
2016-12-03 10:13:44 +03:00
|
|
|
(compress) == ZIO_COMPRESS_GZIP_1 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_2 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_3 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_4 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_5 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_6 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_7 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_8 || \
|
|
|
|
(compress) == ZIO_COMPRESS_GZIP_9 || \
|
|
|
|
(compress) == ZIO_COMPRESS_ZLE || \
|
Add zstd support to zfs
This PR adds two new compression types, based on ZStandard:
- zstd: A basic ZStandard compression algorithm Available compression.
Levels for zstd are zstd-1 through zstd-19, where the compression
increases with every level, but speed decreases.
- zstd-fast: A faster version of the ZStandard compression algorithm
zstd-fast is basically a "negative" level of zstd. The compression
decreases with every level, but speed increases.
Available compression levels for zstd-fast:
- zstd-fast-1 through zstd-fast-10
- zstd-fast-20 through zstd-fast-100 (in increments of 10)
- zstd-fast-500 and zstd-fast-1000
For more information check the man page.
Implementation details:
Rather than treat each level of zstd as a different algorithm (as was
done historically with gzip), the block pointer `enum zio_compress`
value is simply zstd for all levels, including zstd-fast, since they all
use the same decompression function.
The compress= property (a 64bit unsigned integer) uses the lower 7 bits
to store the compression algorithm (matching the number of bits used in
a block pointer, as the 8th bit was borrowed for embedded block
pointers). The upper bits are used to store the compression level.
It is necessary to be able to determine what compression level was used
when later reading a block back, so the concept used in LZ4, where the
first 32bits of the on-disk value are the size of the compressed data
(since the allocation is rounded up to the nearest ashift), was
extended, and we store the version of ZSTD and the level as well as the
compressed size. This value is returned when decompressing a block, so
that if the block needs to be recompressed (L2ARC, nop-write, etc), that
the same parameters will be used to result in the matching checksum.
All of the internal ZFS code ( `arc_buf_hdr_t`, `objset_t`,
`zio_prop_t`, etc.) uses the separated _compress and _complevel
variables. Only the properties ZAP contains the combined/bit-shifted
value. The combined value is split when the compression_changed_cb()
callback is called, and sets both objset members (os_compress and
os_complevel).
The userspace tools all use the combined/bit-shifted value.
Additional notes:
zdb can now also decode the ZSTD compression header (flag -Z) and
inspect the size, version and compression level saved in that header.
For each record, if it is ZSTD compressed, the parameters of the decoded
compression header get printed.
ZSTD is included with all current tests and new tests are added
as-needed.
Per-dataset feature flags now get activated when the property is set.
If a compression algorithm requires a feature flag, zfs activates the
feature when the property is set, rather than waiting for the first
block to be born. This is currently only used by zstd but can be
extended as needed.
Portions-Sponsored-By: The FreeBSD Foundation
Co-authored-by: Allan Jude <allanjude@freebsd.org>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Co-authored-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Allan Jude <allanjude@freebsd.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Closes #6247
Closes #9024
Closes #10277
Closes #10278
2020-08-18 20:10:17 +03:00
|
|
|
(compress) == ZIO_COMPRESS_ZSTD || \
|
2015-07-06 04:55:32 +03:00
|
|
|
(compress) == ZIO_COMPRESS_ON || \
|
2010-05-29 00:45:14 +04:00
|
|
|
(compress) == ZIO_COMPRESS_OFF)
|
|
|
|
|
Add zstd support to zfs
This PR adds two new compression types, based on ZStandard:
- zstd: A basic ZStandard compression algorithm Available compression.
Levels for zstd are zstd-1 through zstd-19, where the compression
increases with every level, but speed decreases.
- zstd-fast: A faster version of the ZStandard compression algorithm
zstd-fast is basically a "negative" level of zstd. The compression
decreases with every level, but speed increases.
Available compression levels for zstd-fast:
- zstd-fast-1 through zstd-fast-10
- zstd-fast-20 through zstd-fast-100 (in increments of 10)
- zstd-fast-500 and zstd-fast-1000
For more information check the man page.
Implementation details:
Rather than treat each level of zstd as a different algorithm (as was
done historically with gzip), the block pointer `enum zio_compress`
value is simply zstd for all levels, including zstd-fast, since they all
use the same decompression function.
The compress= property (a 64bit unsigned integer) uses the lower 7 bits
to store the compression algorithm (matching the number of bits used in
a block pointer, as the 8th bit was borrowed for embedded block
pointers). The upper bits are used to store the compression level.
It is necessary to be able to determine what compression level was used
when later reading a block back, so the concept used in LZ4, where the
first 32bits of the on-disk value are the size of the compressed data
(since the allocation is rounded up to the nearest ashift), was
extended, and we store the version of ZSTD and the level as well as the
compressed size. This value is returned when decompressing a block, so
that if the block needs to be recompressed (L2ARC, nop-write, etc), that
the same parameters will be used to result in the matching checksum.
All of the internal ZFS code ( `arc_buf_hdr_t`, `objset_t`,
`zio_prop_t`, etc.) uses the separated _compress and _complevel
variables. Only the properties ZAP contains the combined/bit-shifted
value. The combined value is split when the compression_changed_cb()
callback is called, and sets both objset members (os_compress and
os_complevel).
The userspace tools all use the combined/bit-shifted value.
Additional notes:
zdb can now also decode the ZSTD compression header (flag -Z) and
inspect the size, version and compression level saved in that header.
For each record, if it is ZSTD compressed, the parameters of the decoded
compression header get printed.
ZSTD is included with all current tests and new tests are added
as-needed.
Per-dataset feature flags now get activated when the property is set.
If a compression algorithm requires a feature flag, zfs activates the
feature when the property is set, rather than waiting for the first
block to be born. This is currently only used by zstd but can be
extended as needed.
Portions-Sponsored-By: The FreeBSD Foundation
Co-authored-by: Allan Jude <allanjude@freebsd.org>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Co-authored-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Allan Jude <allanjude@freebsd.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Closes #6247
Closes #9024
Closes #10277
Closes #10278
2020-08-18 20:10:17 +03:00
|
|
|
|
|
|
|
#define ZIO_COMPRESS_ALGO(x) (x & SPA_COMPRESSMASK)
|
|
|
|
#define ZIO_COMPRESS_LEVEL(x) ((x & ~SPA_COMPRESSMASK) >> SPA_COMPRESSBITS)
|
|
|
|
#define ZIO_COMPRESS_RAW(type, level) (type | ((level) << SPA_COMPRESSBITS))
|
|
|
|
|
|
|
|
#define ZIO_COMPLEVEL_ZSTD(level) \
|
|
|
|
ZIO_COMPRESS_RAW(ZIO_COMPRESS_ZSTD, level)
|
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
#define ZIO_FAILURE_MODE_WAIT 0
|
|
|
|
#define ZIO_FAILURE_MODE_CONTINUE 1
|
|
|
|
#define ZIO_FAILURE_MODE_PANIC 2
|
|
|
|
|
2018-03-15 20:56:55 +03:00
|
|
|
typedef enum zio_suspend_reason {
|
|
|
|
ZIO_SUSPEND_NONE = 0,
|
|
|
|
ZIO_SUSPEND_IOERR,
|
|
|
|
ZIO_SUSPEND_MMP,
|
|
|
|
} zio_suspend_reason_t;
|
|
|
|
|
2022-10-27 19:54:54 +03:00
|
|
|
/*
|
|
|
|
* This was originally an enum type. However, those are 32-bit and there is no
|
|
|
|
* way to make a 64-bit enum type. Since we ran out of bits for flags, we were
|
|
|
|
* forced to upgrade it to a uint64_t.
|
2024-02-29 03:25:24 +03:00
|
|
|
*
|
|
|
|
* NOTE: PLEASE UPDATE THE BITFIELD STRINGS IN zfs_valstr.c IF YOU ADD ANOTHER
|
|
|
|
* FLAG.
|
2022-10-27 19:54:54 +03:00
|
|
|
*/
|
|
|
|
typedef uint64_t zio_flag_t;
|
2010-05-29 00:45:14 +04:00
|
|
|
/*
|
|
|
|
* Flags inherited by gang, ddt, and vdev children,
|
|
|
|
* and that must be equal for two zios to aggregate
|
|
|
|
*/
|
2022-10-27 19:54:54 +03:00
|
|
|
#define ZIO_FLAG_DONT_AGGREGATE (1ULL << 0)
|
|
|
|
#define ZIO_FLAG_IO_REPAIR (1ULL << 1)
|
|
|
|
#define ZIO_FLAG_SELF_HEAL (1ULL << 2)
|
|
|
|
#define ZIO_FLAG_RESILVER (1ULL << 3)
|
|
|
|
#define ZIO_FLAG_SCRUB (1ULL << 4)
|
|
|
|
#define ZIO_FLAG_SCAN_THREAD (1ULL << 5)
|
|
|
|
#define ZIO_FLAG_PHYSICAL (1ULL << 6)
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
#define ZIO_FLAG_AGG_INHERIT (ZIO_FLAG_CANFAIL - 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flags inherited by ddt, gang, and vdev children.
|
|
|
|
*/
|
2022-10-27 19:54:54 +03:00
|
|
|
#define ZIO_FLAG_CANFAIL (1ULL << 7) /* must be first for INHERIT */
|
|
|
|
#define ZIO_FLAG_SPECULATIVE (1ULL << 8)
|
|
|
|
#define ZIO_FLAG_CONFIG_WRITER (1ULL << 9)
|
|
|
|
#define ZIO_FLAG_DONT_RETRY (1ULL << 10)
|
|
|
|
#define ZIO_FLAG_NODATA (1ULL << 12)
|
|
|
|
#define ZIO_FLAG_INDUCE_DAMAGE (1ULL << 13)
|
|
|
|
#define ZIO_FLAG_IO_ALLOCATING (1ULL << 14)
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
#define ZIO_FLAG_DDT_INHERIT (ZIO_FLAG_IO_RETRY - 1)
|
|
|
|
#define ZIO_FLAG_GANG_INHERIT (ZIO_FLAG_IO_RETRY - 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flags inherited by vdev children.
|
|
|
|
*/
|
2022-10-27 19:54:54 +03:00
|
|
|
#define ZIO_FLAG_IO_RETRY (1ULL << 15) /* must be first for INHERIT */
|
|
|
|
#define ZIO_FLAG_PROBE (1ULL << 16)
|
|
|
|
#define ZIO_FLAG_TRYHARD (1ULL << 17)
|
|
|
|
#define ZIO_FLAG_OPTIONAL (1ULL << 18)
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
#define ZIO_FLAG_VDEV_INHERIT (ZIO_FLAG_DONT_QUEUE - 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flags not inherited by any children.
|
|
|
|
*/
|
2022-10-27 19:54:54 +03:00
|
|
|
#define ZIO_FLAG_DONT_QUEUE (1ULL << 19) /* must be first for INHERIT */
|
|
|
|
#define ZIO_FLAG_DONT_PROPAGATE (1ULL << 20)
|
|
|
|
#define ZIO_FLAG_IO_BYPASS (1ULL << 21)
|
|
|
|
#define ZIO_FLAG_IO_REWRITE (1ULL << 22)
|
|
|
|
#define ZIO_FLAG_RAW_COMPRESS (1ULL << 23)
|
|
|
|
#define ZIO_FLAG_RAW_ENCRYPT (1ULL << 24)
|
|
|
|
#define ZIO_FLAG_GANG_CHILD (1ULL << 25)
|
|
|
|
#define ZIO_FLAG_DDT_CHILD (1ULL << 26)
|
|
|
|
#define ZIO_FLAG_GODFATHER (1ULL << 27)
|
|
|
|
#define ZIO_FLAG_NOPWRITE (1ULL << 28)
|
|
|
|
#define ZIO_FLAG_REEXECUTED (1ULL << 29)
|
|
|
|
#define ZIO_FLAG_DELEGATED (1ULL << 30)
|
Adding Direct IO Support
Adding O_DIRECT support to ZFS to bypass the ARC for writes/reads.
O_DIRECT support in ZFS will always ensure there is coherency between
buffered and O_DIRECT IO requests. This ensures that all IO requests,
whether buffered or direct, will see the same file contents at all
times. Just as in other FS's , O_DIRECT does not imply O_SYNC. While
data is written directly to VDEV disks, metadata will not be synced
until the associated TXG is synced.
For both O_DIRECT read and write request the offset and request sizes,
at a minimum, must be PAGE_SIZE aligned. In the event they are not,
then EINVAL is returned unless the direct property is set to always (see
below).
For O_DIRECT writes:
The request also must be block aligned (recordsize) or the write
request will take the normal (buffered) write path. In the event that
request is block aligned and a cached copy of the buffer in the ARC,
then it will be discarded from the ARC forcing all further reads to
retrieve the data from disk.
For O_DIRECT reads:
The only alignment restrictions are PAGE_SIZE alignment. In the event
that the requested data is in buffered (in the ARC) it will just be
copied from the ARC into the user buffer.
For both O_DIRECT writes and reads the O_DIRECT flag will be ignored in
the event that file contents are mmap'ed. In this case, all requests
that are at least PAGE_SIZE aligned will just fall back to the buffered
paths. If the request however is not PAGE_SIZE aligned, EINVAL will
be returned as always regardless if the file's contents are mmap'ed.
Since O_DIRECT writes go through the normal ZIO pipeline, the
following operations are supported just as with normal buffered writes:
Checksum
Compression
Encryption
Erasure Coding
There is one caveat for the data integrity of O_DIRECT writes that is
distinct for each of the OS's supported by ZFS.
FreeBSD - FreeBSD is able to place user pages under write protection so
any data in the user buffers and written directly down to the
VDEV disks is guaranteed to not change. There is no concern
with data integrity and O_DIRECT writes.
Linux - Linux is not able to place anonymous user pages under write
protection. Because of this, if the user decides to manipulate
the page contents while the write operation is occurring, data
integrity can not be guaranteed. However, there is a module
parameter `zfs_vdev_direct_write_verify` that controls the
if a O_DIRECT writes that can occur to a top-level VDEV before
a checksum verify is run before the contents of the I/O buffer
are committed to disk. In the event of a checksum verification
failure the write will return EIO. The number of O_DIRECT write
checksum verification errors can be observed by doing
`zpool status -d`, which will list all verification errors that
have occurred on a top-level VDEV. Along with `zpool status`, a
ZED event will be issues as `dio_verify` when a checksum
verification error occurs.
ZVOLs and dedup is not currently supported with Direct I/O.
A new dataset property `direct` has been added with the following 3
allowable values:
disabled - Accepts O_DIRECT flag, but silently ignores it and treats
the request as a buffered IO request.
standard - Follows the alignment restrictions outlined above for
write/read IO requests when the O_DIRECT flag is used.
always - Treats every write/read IO request as though it passed
O_DIRECT and will do O_DIRECT if the alignment restrictions
are met otherwise will redirect through the ARC. This
property will not allow a request to fail.
There is also a module parameter zfs_dio_enabled that can be used to
force all reads and writes through the ARC. By setting this module
parameter to 0, it mimics as if the direct dataset property is set to
disabled.
Reviewed-by: Brian Behlendorf <behlendorf@llnl.gov>
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Signed-off-by: Brian Atkinson <batkinson@lanl.gov>
Co-authored-by: Mark Maybee <mark.maybee@delphix.com>
Co-authored-by: Matt Macy <mmacy@FreeBSD.org>
Co-authored-by: Brian Behlendorf <behlendorf@llnl.gov>
Closes #10018
2024-09-14 23:47:59 +03:00
|
|
|
#define ZIO_FLAG_DIO_CHKSUM_ERR (1ULL << 31)
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-11-06 21:38:42 +03:00
|
|
|
#define ZIO_ALLOCATOR_NONE (-1)
|
|
|
|
#define ZIO_HAS_ALLOCATOR(zio) ((zio)->io_allocator != ZIO_ALLOCATOR_NONE)
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
#define ZIO_FLAG_MUSTSUCCEED 0
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
#define ZIO_FLAG_RAW (ZIO_FLAG_RAW_COMPRESS | ZIO_FLAG_RAW_ENCRYPT)
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
#define ZIO_DDT_CHILD_FLAGS(zio) \
|
|
|
|
(((zio)->io_flags & ZIO_FLAG_DDT_INHERIT) | \
|
|
|
|
ZIO_FLAG_DDT_CHILD | ZIO_FLAG_CANFAIL)
|
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
#define ZIO_GANG_CHILD_FLAGS(zio) \
|
|
|
|
(((zio)->io_flags & ZIO_FLAG_GANG_INHERIT) | \
|
|
|
|
ZIO_FLAG_GANG_CHILD | ZIO_FLAG_CANFAIL)
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
#define ZIO_VDEV_CHILD_FLAGS(zio) \
|
|
|
|
(((zio)->io_flags & ZIO_FLAG_VDEV_INHERIT) | \
|
OpenZFS 7614, 9064 - zfs device evacuation/removal
OpenZFS 7614 - zfs device evacuation/removal
OpenZFS 9064 - remove_mirror should wait for device removal to complete
This project allows top-level vdevs to be removed from the storage pool
with "zpool remove", reducing the total amount of storage in the pool.
This operation copies all allocated regions of the device to be removed
onto other devices, recording the mapping from old to new location.
After the removal is complete, read and free operations to the removed
(now "indirect") vdev must be remapped and performed at the new location
on disk. The indirect mapping table is kept in memory whenever the pool
is loaded, so there is minimal performance overhead when doing operations
on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries
become "obsolete" because they are no longer used by any block pointers
in the pool. An entry becomes obsolete when all the blocks that use
it are freed. An entry can also become obsolete when all the snapshots
that reference it are deleted, and the block pointers that reference it
have been "remapped" in all filesystems/zvols (and clones). Whenever an
indirect block is written, all the block pointers in it will be "remapped"
to their new (concrete) locations if possible. This process can be
accelerated by using the "zfs remap" command to proactively rewrite all
indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of
the data that is copied. This makes the process much faster, but if it
were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror.
At the moment, only mirrors and simple top-level vdevs can be removed
and no removal is allowed if any of the top-level vdevs are raidz.
Porting Notes:
* Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
* Remove comment regarding "mpt" driver where zfs_remove_max_segment
is initialized to SPA_MAXBLOCKSIZE.
Change zfs_condense_indirect_commit_entry_delay_ticks to
zfs_condense_indirect_commit_entry_delay_ms for consistency with
most other tunables in which delays are specified in ms.
* ZTS changes:
Use set_tunable rather than mdb
Use zpool sync as appropriate
Use sync_pool instead of sync
Kill jobs during test_removal_with_operation to allow unmount/export
Don't add non-disk names such as "mirror" or "raidz" to $DISKS
Use $TEST_BASE_DIR instead of /tmp
Increase HZ from 100 to 1000 which is more common on Linux
removal_multiple_indirection.ksh
Reduce iterations in order to not time out on the code
coverage builders.
removal_resume_export:
Functionally, the test case is correct but there exists a race
where the kernel thread hasn't been fully started yet and is
not visible. Wait for up to 1 second for the removal thread
to be started before giving up on it. Also, increase the
amount of data copied in order that the removal not finish
before the export has a chance to fail.
* MMP compatibility, the concept of concrete versus non-concrete devices
has slightly changed the semantics of vdev_writeable(). Update
mmp_random_leaf_impl() accordingly.
* Updated dbuf_remap() to handle the org.zfsonlinux:large_dnode pool
feature which is not supported by OpenZFS.
* Added support for new vdev removal tracepoints.
* Test cases removal_with_zdb and removal_condense_export have been
intentionally disabled. When run manually they pass as intended,
but when running in the automated test environment they produce
unreliable results on the latest Fedora release.
They may work better once the upstream pool import refectoring is
merged into ZoL at which point they will be re-enabled.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Alex Reece <alex@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Laager <rlaager@wiktel.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Garrett D'Amore <garrett@damore.org>
Ported-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://www.illumos.org/issues/7614
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/f539f1eb
Closes #6900
2016-09-22 19:30:13 +03:00
|
|
|
ZIO_FLAG_DONT_PROPAGATE | ZIO_FLAG_CANFAIL)
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2021-10-11 20:58:06 +03:00
|
|
|
#define ZIO_CHILD_BIT(x) (1U << (x))
|
|
|
|
#define ZIO_CHILD_BIT_IS_SET(val, x) ((val) & (1U << (x)))
|
OpenZFS 8857 - zio_remove_child() panic due to already destroyed parent zio
PROBLEM
=======
It's possible for a parent zio to complete even though it has children
which have not completed. This can result in the following panic:
> $C
ffffff01809128c0 vpanic()
ffffff01809128e0 mutex_panic+0x58(fffffffffb94c904, ffffff597dde7f80)
ffffff0180912950 mutex_vector_enter+0x347(ffffff597dde7f80)
ffffff01809129b0 zio_remove_child+0x50(ffffff597dde7c58, ffffff32bd901ac0,
ffffff3373370908)
ffffff0180912a40 zio_done+0x390(ffffff32bd901ac0)
ffffff0180912a70 zio_execute+0x78(ffffff32bd901ac0)
ffffff0180912b30 taskq_thread+0x2d0(ffffff33bae44140)
ffffff0180912b40 thread_start+8()
> ::status
debugging crash dump vmcore.2 (64-bit) from batfs0390
operating system: 5.11 joyent_20170911T171900Z (i86pc)
image uuid: (not set)
panic message: mutex_enter: bad mutex, lp=ffffff597dde7f80
owner=ffffff3c59b39480 thread=ffffff0180912c40
dump content: kernel pages only
The problem is that dbuf_prefetch along with l2arc can create a zio tree
which confuses the parent zio and allows it to complete with while children
still exist. Here's the scenario:
zio tree:
pio
|--- lio
The parent zio, pio, has entered the zio_done stage and begins to check its
children to see there are still some that have not completed. In zio_done(),
the children are checked in the following order:
zio_wait_for_children(zio, ZIO_CHILD_VDEV, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_GANG, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_DDT, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_LOGICAL, ZIO_WAIT_DONE)
If pio, finds any child which has not completed then it stops executing and
goes to sleep. Each call to zio_wait_for_children() will grab the io_lock
while checking the particular child.
In this scenario, the pio has completed the first call to
zio_wait_for_children() to check for any ZIO_CHILD_VDEV children. Since
the only zio in the zio tree right now is the logical zio, lio, then it
completes that call and prepares to check the next child type.
In the meantime, the lio completes and in its callback creates a child vdev
zio, cio. The zio tree looks like this:
zio tree:
pio
|--- lio
|--- cio
The lio then grabs the parent's io_lock and removes itself.
zio tree:
pio
|--- cio
The pio continues to run but has already completed its check for ZIO_CHILD_VDEV
and will erroneously complete. When the child zio, cio, completes it will panic
the system trying to reference the parent zio which has been destroyed.
SOLUTION
========
The fix is to rework the zio_wait_for_children() logic to accept a bitfield
for all the children types that it's interested in checking. The
io_lock will is held the entire time we check all the children types. Since
the function now accepts a bitfield, a simple ZIO_CHILD_BIT() macro is provided
to allow for the conversion between a ZIO_CHILD type and the bitfield used by
the zio_wiat_for_children logic.
Authored by: George Wilson <george.wilson@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Andriy Gapon <avg@FreeBSD.org>
Reviewed by: Youzhong Yang <youzhong@gmail.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Dan McDonald <danmcd@omniti.com>
Ported-by: Giuseppe Di Natale <dinatale2@llnl.gov>
OpenZFS-issue: https://www.illumos.org/issues/8857
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/862ff6d99c
Issue #5918
Closes #7168
2018-02-08 23:04:14 +03:00
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
enum zio_child {
|
|
|
|
ZIO_CHILD_VDEV = 0,
|
|
|
|
ZIO_CHILD_GANG,
|
2010-05-29 00:45:14 +04:00
|
|
|
ZIO_CHILD_DDT,
|
2008-12-03 23:09:06 +03:00
|
|
|
ZIO_CHILD_LOGICAL,
|
|
|
|
ZIO_CHILD_TYPES
|
|
|
|
};
|
|
|
|
|
OpenZFS 8857 - zio_remove_child() panic due to already destroyed parent zio
PROBLEM
=======
It's possible for a parent zio to complete even though it has children
which have not completed. This can result in the following panic:
> $C
ffffff01809128c0 vpanic()
ffffff01809128e0 mutex_panic+0x58(fffffffffb94c904, ffffff597dde7f80)
ffffff0180912950 mutex_vector_enter+0x347(ffffff597dde7f80)
ffffff01809129b0 zio_remove_child+0x50(ffffff597dde7c58, ffffff32bd901ac0,
ffffff3373370908)
ffffff0180912a40 zio_done+0x390(ffffff32bd901ac0)
ffffff0180912a70 zio_execute+0x78(ffffff32bd901ac0)
ffffff0180912b30 taskq_thread+0x2d0(ffffff33bae44140)
ffffff0180912b40 thread_start+8()
> ::status
debugging crash dump vmcore.2 (64-bit) from batfs0390
operating system: 5.11 joyent_20170911T171900Z (i86pc)
image uuid: (not set)
panic message: mutex_enter: bad mutex, lp=ffffff597dde7f80
owner=ffffff3c59b39480 thread=ffffff0180912c40
dump content: kernel pages only
The problem is that dbuf_prefetch along with l2arc can create a zio tree
which confuses the parent zio and allows it to complete with while children
still exist. Here's the scenario:
zio tree:
pio
|--- lio
The parent zio, pio, has entered the zio_done stage and begins to check its
children to see there are still some that have not completed. In zio_done(),
the children are checked in the following order:
zio_wait_for_children(zio, ZIO_CHILD_VDEV, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_GANG, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_DDT, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_LOGICAL, ZIO_WAIT_DONE)
If pio, finds any child which has not completed then it stops executing and
goes to sleep. Each call to zio_wait_for_children() will grab the io_lock
while checking the particular child.
In this scenario, the pio has completed the first call to
zio_wait_for_children() to check for any ZIO_CHILD_VDEV children. Since
the only zio in the zio tree right now is the logical zio, lio, then it
completes that call and prepares to check the next child type.
In the meantime, the lio completes and in its callback creates a child vdev
zio, cio. The zio tree looks like this:
zio tree:
pio
|--- lio
|--- cio
The lio then grabs the parent's io_lock and removes itself.
zio tree:
pio
|--- cio
The pio continues to run but has already completed its check for ZIO_CHILD_VDEV
and will erroneously complete. When the child zio, cio, completes it will panic
the system trying to reference the parent zio which has been destroyed.
SOLUTION
========
The fix is to rework the zio_wait_for_children() logic to accept a bitfield
for all the children types that it's interested in checking. The
io_lock will is held the entire time we check all the children types. Since
the function now accepts a bitfield, a simple ZIO_CHILD_BIT() macro is provided
to allow for the conversion between a ZIO_CHILD type and the bitfield used by
the zio_wiat_for_children logic.
Authored by: George Wilson <george.wilson@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Andriy Gapon <avg@FreeBSD.org>
Reviewed by: Youzhong Yang <youzhong@gmail.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Dan McDonald <danmcd@omniti.com>
Ported-by: Giuseppe Di Natale <dinatale2@llnl.gov>
OpenZFS-issue: https://www.illumos.org/issues/8857
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/862ff6d99c
Issue #5918
Closes #7168
2018-02-08 23:04:14 +03:00
|
|
|
#define ZIO_CHILD_VDEV_BIT ZIO_CHILD_BIT(ZIO_CHILD_VDEV)
|
|
|
|
#define ZIO_CHILD_GANG_BIT ZIO_CHILD_BIT(ZIO_CHILD_GANG)
|
|
|
|
#define ZIO_CHILD_DDT_BIT ZIO_CHILD_BIT(ZIO_CHILD_DDT)
|
|
|
|
#define ZIO_CHILD_LOGICAL_BIT ZIO_CHILD_BIT(ZIO_CHILD_LOGICAL)
|
|
|
|
#define ZIO_CHILD_ALL_BITS \
|
Reduce taskq and context-switch cost of zio pipe
When doing a read from disk, ZFS creates 3 ZIO's: a zio_null(), the
logical zio_read(), and then a physical zio. Currently, each of these
results in a separate taskq_dispatch(zio_execute).
On high-read-iops workloads, this causes a significant performance
impact. By processing all 3 ZIO's in a single taskq entry, we reduce the
overhead on taskq locking and context switching. We accomplish this by
allowing zio_done() to return a "next zio to execute" to zio_execute().
This results in a ~12% performance increase for random reads, from
96,000 iops to 108,000 iops (with recordsize=8k, on SSD's).
Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed by: George Wilson <george.wilson@delphix.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
External-issue: DLPX-59292
Closes #7736
2018-08-03 01:51:45 +03:00
|
|
|
(ZIO_CHILD_VDEV_BIT | ZIO_CHILD_GANG_BIT | \
|
OpenZFS 8857 - zio_remove_child() panic due to already destroyed parent zio
PROBLEM
=======
It's possible for a parent zio to complete even though it has children
which have not completed. This can result in the following panic:
> $C
ffffff01809128c0 vpanic()
ffffff01809128e0 mutex_panic+0x58(fffffffffb94c904, ffffff597dde7f80)
ffffff0180912950 mutex_vector_enter+0x347(ffffff597dde7f80)
ffffff01809129b0 zio_remove_child+0x50(ffffff597dde7c58, ffffff32bd901ac0,
ffffff3373370908)
ffffff0180912a40 zio_done+0x390(ffffff32bd901ac0)
ffffff0180912a70 zio_execute+0x78(ffffff32bd901ac0)
ffffff0180912b30 taskq_thread+0x2d0(ffffff33bae44140)
ffffff0180912b40 thread_start+8()
> ::status
debugging crash dump vmcore.2 (64-bit) from batfs0390
operating system: 5.11 joyent_20170911T171900Z (i86pc)
image uuid: (not set)
panic message: mutex_enter: bad mutex, lp=ffffff597dde7f80
owner=ffffff3c59b39480 thread=ffffff0180912c40
dump content: kernel pages only
The problem is that dbuf_prefetch along with l2arc can create a zio tree
which confuses the parent zio and allows it to complete with while children
still exist. Here's the scenario:
zio tree:
pio
|--- lio
The parent zio, pio, has entered the zio_done stage and begins to check its
children to see there are still some that have not completed. In zio_done(),
the children are checked in the following order:
zio_wait_for_children(zio, ZIO_CHILD_VDEV, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_GANG, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_DDT, ZIO_WAIT_DONE)
zio_wait_for_children(zio, ZIO_CHILD_LOGICAL, ZIO_WAIT_DONE)
If pio, finds any child which has not completed then it stops executing and
goes to sleep. Each call to zio_wait_for_children() will grab the io_lock
while checking the particular child.
In this scenario, the pio has completed the first call to
zio_wait_for_children() to check for any ZIO_CHILD_VDEV children. Since
the only zio in the zio tree right now is the logical zio, lio, then it
completes that call and prepares to check the next child type.
In the meantime, the lio completes and in its callback creates a child vdev
zio, cio. The zio tree looks like this:
zio tree:
pio
|--- lio
|--- cio
The lio then grabs the parent's io_lock and removes itself.
zio tree:
pio
|--- cio
The pio continues to run but has already completed its check for ZIO_CHILD_VDEV
and will erroneously complete. When the child zio, cio, completes it will panic
the system trying to reference the parent zio which has been destroyed.
SOLUTION
========
The fix is to rework the zio_wait_for_children() logic to accept a bitfield
for all the children types that it's interested in checking. The
io_lock will is held the entire time we check all the children types. Since
the function now accepts a bitfield, a simple ZIO_CHILD_BIT() macro is provided
to allow for the conversion between a ZIO_CHILD type and the bitfield used by
the zio_wiat_for_children logic.
Authored by: George Wilson <george.wilson@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Andriy Gapon <avg@FreeBSD.org>
Reviewed by: Youzhong Yang <youzhong@gmail.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Dan McDonald <danmcd@omniti.com>
Ported-by: Giuseppe Di Natale <dinatale2@llnl.gov>
OpenZFS-issue: https://www.illumos.org/issues/8857
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/862ff6d99c
Issue #5918
Closes #7168
2018-02-08 23:04:14 +03:00
|
|
|
ZIO_CHILD_DDT_BIT | ZIO_CHILD_LOGICAL_BIT)
|
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
enum zio_wait_type {
|
|
|
|
ZIO_WAIT_READY = 0,
|
|
|
|
ZIO_WAIT_DONE,
|
|
|
|
ZIO_WAIT_TYPES
|
|
|
|
};
|
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
typedef void zio_done_func_t(zio_t *zio);
|
|
|
|
|
2019-12-09 23:29:56 +03:00
|
|
|
extern int zio_exclude_metadata;
|
2016-10-14 03:59:18 +03:00
|
|
|
extern int zio_dva_throttle_enabled;
|
2022-01-15 02:37:55 +03:00
|
|
|
extern const char *const zio_type_name[ZIO_TYPES];
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A bookmark is a four-tuple <objset, object, level, blkid> that uniquely
|
|
|
|
* identifies any block in the pool. By convention, the meta-objset (MOS)
|
2010-05-29 00:45:14 +04:00
|
|
|
* is objset 0, and the meta-dnode is object 0. This covers all blocks
|
|
|
|
* except root blocks and ZIL blocks, which are defined as follows:
|
2008-11-20 23:01:55 +03:00
|
|
|
*
|
2010-05-29 00:45:14 +04:00
|
|
|
* Root blocks (objset_phys_t) are object 0, level -1: <objset, 0, -1, 0>.
|
|
|
|
* ZIL blocks are bookmarked <objset, 0, -2, blkid == ZIL sequence number>.
|
|
|
|
* dmu_sync()ed ZIL data blocks are bookmarked <objset, object, -2, blkid>.
|
2015-12-22 04:31:57 +03:00
|
|
|
* dnode visit bookmarks are <objset, object id of dnode, -3, 0>.
|
2008-11-20 23:01:55 +03:00
|
|
|
*
|
2010-05-29 00:45:14 +04:00
|
|
|
* Note: this structure is called a bookmark because its original purpose
|
|
|
|
* was to remember where to resume a pool-wide traverse.
|
2008-11-20 23:01:55 +03:00
|
|
|
*
|
2014-06-25 22:37:59 +04:00
|
|
|
* Note: this structure is passed between userland and the kernel, and is
|
|
|
|
* stored on disk (by virtue of being incorporated into other on-disk
|
|
|
|
* structures, e.g. dsl_scan_phys_t).
|
Improve zpool status output, list all affected datasets
Currently, determining which datasets are affected by corruption is
a manual process.
The primary difficulty in reporting the list of affected snapshots is
that since the error was initially found, the snapshot where the error
originally occurred in, may have been deleted. To solve this issue, we
add the ID of the head dataset of the original snapshot which the error
was detected in, to the stored error report. Then any time a filesystem
is deleted, the errors associated with it are deleted as well. Any time
a clone promote occurs, we modify reports associated with the original
head to refer to the new head. The stored error reports are identified
by this head ID, the birth time of the block which the error occurred
in, as well as some information about the error itself are also stored.
Once this information is stored, we can find the set of datasets
affected by an error by walking back the list of snapshots in the given
head until we find one with the appropriate birth txg, and then traverse
through the snapshots of the clone family, terminating a branch if the
block was replaced in a given snapshot. Then we report this information
back to libzfs, and to the zpool status command, where it is displayed
as follows:
pool: test
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 00:00:00 with 800 errors on Fri Dec 3
08:27:57 2021
config:
NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
sdb ONLINE 0 0 1.58K
errors: Permanent errors have been detected in the following files:
test@1:/test.0.0
/test/test.0.0
/test/1clone/test.0.0
A new feature flag is introduced to mark the presence of this change, as
well as promotion and backwards compatibility logic. This is an updated
version of #9175. Rebase required fixing the tests, updating the ABI of
libzfs, updating the man pages, fixing bugs, fixing the error returns,
and updating the old on-disk error logs to the new format when
activating the feature.
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Co-authored-by: TulsiJain <tulsi.jain@delphix.com>
Signed-off-by: George Amanakis <gamanakis@gmail.com>
Closes #9175
Closes #12812
2022-04-26 03:25:42 +03:00
|
|
|
*
|
|
|
|
* If the head_errlog feature is enabled a different on-disk format for error
|
|
|
|
* logs is used. This introduces the use of an error bookmark, a four-tuple
|
|
|
|
* <object, level, blkid, birth> that uniquely identifies any error block
|
|
|
|
* in the pool. The birth transaction group is used to track whether the block
|
|
|
|
* has been overwritten by newer data or added to a snapshot since its marking
|
|
|
|
* as an error.
|
2008-11-20 23:01:55 +03:00
|
|
|
*/
|
2014-06-25 22:37:59 +04:00
|
|
|
struct zbookmark_phys {
|
2008-11-20 23:01:55 +03:00
|
|
|
uint64_t zb_objset;
|
|
|
|
uint64_t zb_object;
|
|
|
|
int64_t zb_level;
|
|
|
|
uint64_t zb_blkid;
|
Add visibility in to arc_read
This change is an attempt to add visibility into the arc_read calls
occurring on a system, in real time. To do this, a list was added to the
in memory SPA data structure for a pool, with each element on the list
corresponding to a call to arc_read. These entries are then exported
through the kstat interface, which can then be interpreted in userspace.
For each arc_read call, the following information is exported:
* A unique identifier (uint64_t)
* The time the entry was added to the list (hrtime_t)
(*not* wall clock time; relative to the other entries on the list)
* The objset ID (uint64_t)
* The object number (uint64_t)
* The indirection level (uint64_t)
* The block ID (uint64_t)
* The name of the function originating the arc_read call (char[24])
* The arc_flags from the arc_read call (uint32_t)
* The PID of the reading thread (pid_t)
* The command or name of thread originating read (char[16])
From this exported information one can see, in real time, exactly what
is being read, what function is generating the read, and whether or not
the read was found to be already cached.
There is still some work to be done, but this should serve as a good
starting point.
Specifically, dbuf_read's are not accounted for in the currently
exported information. Thus, a follow up patch should probably be added
to export these calls that never call into arc_read (they only hit the
dbuf hash table). In addition, it might be nice to create a utility
similar to "arcstat.py" to digest the exported information and display
it in a more readable format. Or perhaps, log the information and allow
for it to be "replayed" at a later time.
Signed-off-by: Prakash Surya <surya1@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-09-07 03:09:05 +04:00
|
|
|
};
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2023-03-29 02:51:58 +03:00
|
|
|
struct zbookmark_err_phys {
|
Improve zpool status output, list all affected datasets
Currently, determining which datasets are affected by corruption is
a manual process.
The primary difficulty in reporting the list of affected snapshots is
that since the error was initially found, the snapshot where the error
originally occurred in, may have been deleted. To solve this issue, we
add the ID of the head dataset of the original snapshot which the error
was detected in, to the stored error report. Then any time a filesystem
is deleted, the errors associated with it are deleted as well. Any time
a clone promote occurs, we modify reports associated with the original
head to refer to the new head. The stored error reports are identified
by this head ID, the birth time of the block which the error occurred
in, as well as some information about the error itself are also stored.
Once this information is stored, we can find the set of datasets
affected by an error by walking back the list of snapshots in the given
head until we find one with the appropriate birth txg, and then traverse
through the snapshots of the clone family, terminating a branch if the
block was replaced in a given snapshot. Then we report this information
back to libzfs, and to the zpool status command, where it is displayed
as follows:
pool: test
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 00:00:00 with 800 errors on Fri Dec 3
08:27:57 2021
config:
NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
sdb ONLINE 0 0 1.58K
errors: Permanent errors have been detected in the following files:
test@1:/test.0.0
/test/test.0.0
/test/1clone/test.0.0
A new feature flag is introduced to mark the presence of this change, as
well as promotion and backwards compatibility logic. This is an updated
version of #9175. Rebase required fixing the tests, updating the ABI of
libzfs, updating the man pages, fixing bugs, fixing the error returns,
and updating the old on-disk error logs to the new format when
activating the feature.
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Co-authored-by: TulsiJain <tulsi.jain@delphix.com>
Signed-off-by: George Amanakis <gamanakis@gmail.com>
Closes #9175
Closes #12812
2022-04-26 03:25:42 +03:00
|
|
|
uint64_t zb_object;
|
|
|
|
int64_t zb_level;
|
|
|
|
uint64_t zb_blkid;
|
|
|
|
uint64_t zb_birth;
|
2023-03-29 02:51:58 +03:00
|
|
|
};
|
Improve zpool status output, list all affected datasets
Currently, determining which datasets are affected by corruption is
a manual process.
The primary difficulty in reporting the list of affected snapshots is
that since the error was initially found, the snapshot where the error
originally occurred in, may have been deleted. To solve this issue, we
add the ID of the head dataset of the original snapshot which the error
was detected in, to the stored error report. Then any time a filesystem
is deleted, the errors associated with it are deleted as well. Any time
a clone promote occurs, we modify reports associated with the original
head to refer to the new head. The stored error reports are identified
by this head ID, the birth time of the block which the error occurred
in, as well as some information about the error itself are also stored.
Once this information is stored, we can find the set of datasets
affected by an error by walking back the list of snapshots in the given
head until we find one with the appropriate birth txg, and then traverse
through the snapshots of the clone family, terminating a branch if the
block was replaced in a given snapshot. Then we report this information
back to libzfs, and to the zpool status command, where it is displayed
as follows:
pool: test
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 00:00:00 with 800 errors on Fri Dec 3
08:27:57 2021
config:
NAME STATE READ WRITE CKSUM
test ONLINE 0 0 0
sdb ONLINE 0 0 1.58K
errors: Permanent errors have been detected in the following files:
test@1:/test.0.0
/test/test.0.0
/test/1clone/test.0.0
A new feature flag is introduced to mark the presence of this change, as
well as promotion and backwards compatibility logic. This is an updated
version of #9175. Rebase required fixing the tests, updating the ABI of
libzfs, updating the man pages, fixing bugs, fixing the error returns,
and updating the old on-disk error logs to the new format when
activating the feature.
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Co-authored-by: TulsiJain <tulsi.jain@delphix.com>
Signed-off-by: George Amanakis <gamanakis@gmail.com>
Closes #9175
Closes #12812
2022-04-26 03:25:42 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
#define SET_BOOKMARK(zb, objset, object, level, blkid) \
|
|
|
|
{ \
|
|
|
|
(zb)->zb_objset = objset; \
|
|
|
|
(zb)->zb_object = object; \
|
|
|
|
(zb)->zb_level = level; \
|
|
|
|
(zb)->zb_blkid = blkid; \
|
|
|
|
}
|
|
|
|
|
|
|
|
#define ZB_DESTROYED_OBJSET (-1ULL)
|
|
|
|
|
|
|
|
#define ZB_ROOT_OBJECT (0ULL)
|
|
|
|
#define ZB_ROOT_LEVEL (-1LL)
|
|
|
|
#define ZB_ROOT_BLKID (0ULL)
|
|
|
|
|
|
|
|
#define ZB_ZIL_OBJECT (0ULL)
|
|
|
|
#define ZB_ZIL_LEVEL (-2LL)
|
|
|
|
|
2015-12-22 04:31:57 +03:00
|
|
|
#define ZB_DNODE_LEVEL (-3LL)
|
|
|
|
#define ZB_DNODE_BLKID (0ULL)
|
|
|
|
|
2012-12-14 03:24:15 +04:00
|
|
|
#define ZB_IS_ZERO(zb) \
|
|
|
|
((zb)->zb_objset == 0 && (zb)->zb_object == 0 && \
|
|
|
|
(zb)->zb_level == 0 && (zb)->zb_blkid == 0)
|
|
|
|
#define ZB_IS_ROOT(zb) \
|
|
|
|
((zb)->zb_object == ZB_ROOT_OBJECT && \
|
|
|
|
(zb)->zb_level == ZB_ROOT_LEVEL && \
|
|
|
|
(zb)->zb_blkid == ZB_ROOT_BLKID)
|
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
typedef struct zio_prop {
|
|
|
|
enum zio_checksum zp_checksum;
|
|
|
|
enum zio_compress zp_compress;
|
Add zstd support to zfs
This PR adds two new compression types, based on ZStandard:
- zstd: A basic ZStandard compression algorithm Available compression.
Levels for zstd are zstd-1 through zstd-19, where the compression
increases with every level, but speed decreases.
- zstd-fast: A faster version of the ZStandard compression algorithm
zstd-fast is basically a "negative" level of zstd. The compression
decreases with every level, but speed increases.
Available compression levels for zstd-fast:
- zstd-fast-1 through zstd-fast-10
- zstd-fast-20 through zstd-fast-100 (in increments of 10)
- zstd-fast-500 and zstd-fast-1000
For more information check the man page.
Implementation details:
Rather than treat each level of zstd as a different algorithm (as was
done historically with gzip), the block pointer `enum zio_compress`
value is simply zstd for all levels, including zstd-fast, since they all
use the same decompression function.
The compress= property (a 64bit unsigned integer) uses the lower 7 bits
to store the compression algorithm (matching the number of bits used in
a block pointer, as the 8th bit was borrowed for embedded block
pointers). The upper bits are used to store the compression level.
It is necessary to be able to determine what compression level was used
when later reading a block back, so the concept used in LZ4, where the
first 32bits of the on-disk value are the size of the compressed data
(since the allocation is rounded up to the nearest ashift), was
extended, and we store the version of ZSTD and the level as well as the
compressed size. This value is returned when decompressing a block, so
that if the block needs to be recompressed (L2ARC, nop-write, etc), that
the same parameters will be used to result in the matching checksum.
All of the internal ZFS code ( `arc_buf_hdr_t`, `objset_t`,
`zio_prop_t`, etc.) uses the separated _compress and _complevel
variables. Only the properties ZAP contains the combined/bit-shifted
value. The combined value is split when the compression_changed_cb()
callback is called, and sets both objset members (os_compress and
os_complevel).
The userspace tools all use the combined/bit-shifted value.
Additional notes:
zdb can now also decode the ZSTD compression header (flag -Z) and
inspect the size, version and compression level saved in that header.
For each record, if it is ZSTD compressed, the parameters of the decoded
compression header get printed.
ZSTD is included with all current tests and new tests are added
as-needed.
Per-dataset feature flags now get activated when the property is set.
If a compression algorithm requires a feature flag, zfs activates the
feature when the property is set, rather than waiting for the first
block to be born. This is currently only used by zstd but can be
extended as needed.
Portions-Sponsored-By: The FreeBSD Foundation
Co-authored-by: Allan Jude <allanjude@freebsd.org>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Co-authored-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Allan Jude <allanjude@freebsd.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Closes #6247
Closes #9024
Closes #10277
Closes #10278
2020-08-18 20:10:17 +03:00
|
|
|
uint8_t zp_complevel;
|
2008-12-03 23:09:06 +03:00
|
|
|
uint8_t zp_level;
|
2010-05-29 00:45:14 +04:00
|
|
|
uint8_t zp_copies;
|
2023-06-30 18:54:00 +03:00
|
|
|
dmu_object_type_t zp_type;
|
2013-05-10 23:47:54 +04:00
|
|
|
boolean_t zp_dedup;
|
|
|
|
boolean_t zp_dedup_verify;
|
|
|
|
boolean_t zp_nopwrite;
|
2023-03-10 22:59:53 +03:00
|
|
|
boolean_t zp_brtwrite;
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
boolean_t zp_encrypt;
|
|
|
|
boolean_t zp_byteorder;
|
Adding Direct IO Support
Adding O_DIRECT support to ZFS to bypass the ARC for writes/reads.
O_DIRECT support in ZFS will always ensure there is coherency between
buffered and O_DIRECT IO requests. This ensures that all IO requests,
whether buffered or direct, will see the same file contents at all
times. Just as in other FS's , O_DIRECT does not imply O_SYNC. While
data is written directly to VDEV disks, metadata will not be synced
until the associated TXG is synced.
For both O_DIRECT read and write request the offset and request sizes,
at a minimum, must be PAGE_SIZE aligned. In the event they are not,
then EINVAL is returned unless the direct property is set to always (see
below).
For O_DIRECT writes:
The request also must be block aligned (recordsize) or the write
request will take the normal (buffered) write path. In the event that
request is block aligned and a cached copy of the buffer in the ARC,
then it will be discarded from the ARC forcing all further reads to
retrieve the data from disk.
For O_DIRECT reads:
The only alignment restrictions are PAGE_SIZE alignment. In the event
that the requested data is in buffered (in the ARC) it will just be
copied from the ARC into the user buffer.
For both O_DIRECT writes and reads the O_DIRECT flag will be ignored in
the event that file contents are mmap'ed. In this case, all requests
that are at least PAGE_SIZE aligned will just fall back to the buffered
paths. If the request however is not PAGE_SIZE aligned, EINVAL will
be returned as always regardless if the file's contents are mmap'ed.
Since O_DIRECT writes go through the normal ZIO pipeline, the
following operations are supported just as with normal buffered writes:
Checksum
Compression
Encryption
Erasure Coding
There is one caveat for the data integrity of O_DIRECT writes that is
distinct for each of the OS's supported by ZFS.
FreeBSD - FreeBSD is able to place user pages under write protection so
any data in the user buffers and written directly down to the
VDEV disks is guaranteed to not change. There is no concern
with data integrity and O_DIRECT writes.
Linux - Linux is not able to place anonymous user pages under write
protection. Because of this, if the user decides to manipulate
the page contents while the write operation is occurring, data
integrity can not be guaranteed. However, there is a module
parameter `zfs_vdev_direct_write_verify` that controls the
if a O_DIRECT writes that can occur to a top-level VDEV before
a checksum verify is run before the contents of the I/O buffer
are committed to disk. In the event of a checksum verification
failure the write will return EIO. The number of O_DIRECT write
checksum verification errors can be observed by doing
`zpool status -d`, which will list all verification errors that
have occurred on a top-level VDEV. Along with `zpool status`, a
ZED event will be issues as `dio_verify` when a checksum
verification error occurs.
ZVOLs and dedup is not currently supported with Direct I/O.
A new dataset property `direct` has been added with the following 3
allowable values:
disabled - Accepts O_DIRECT flag, but silently ignores it and treats
the request as a buffered IO request.
standard - Follows the alignment restrictions outlined above for
write/read IO requests when the O_DIRECT flag is used.
always - Treats every write/read IO request as though it passed
O_DIRECT and will do O_DIRECT if the alignment restrictions
are met otherwise will redirect through the ARC. This
property will not allow a request to fail.
There is also a module parameter zfs_dio_enabled that can be used to
force all reads and writes through the ARC. By setting this module
parameter to 0, it mimics as if the direct dataset property is set to
disabled.
Reviewed-by: Brian Behlendorf <behlendorf@llnl.gov>
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Signed-off-by: Brian Atkinson <batkinson@lanl.gov>
Co-authored-by: Mark Maybee <mark.maybee@delphix.com>
Co-authored-by: Matt Macy <mmacy@FreeBSD.org>
Co-authored-by: Brian Behlendorf <behlendorf@llnl.gov>
Closes #10018
2024-09-14 23:47:59 +03:00
|
|
|
boolean_t zp_direct_write;
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
uint8_t zp_salt[ZIO_DATA_SALT_LEN];
|
|
|
|
uint8_t zp_iv[ZIO_DATA_IV_LEN];
|
|
|
|
uint8_t zp_mac[ZIO_DATA_MAC_LEN];
|
2018-09-06 04:33:36 +03:00
|
|
|
uint32_t zp_zpl_smallblk;
|
2023-06-27 05:50:18 +03:00
|
|
|
dmu_object_type_t zp_storage_type;
|
2008-12-03 23:09:06 +03:00
|
|
|
} zio_prop_t;
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
typedef struct zio_cksum_report zio_cksum_report_t;
|
|
|
|
|
|
|
|
typedef void zio_cksum_finish_f(zio_cksum_report_t *rep,
|
2017-01-05 22:10:07 +03:00
|
|
|
const abd_t *good_data);
|
2010-05-29 00:45:14 +04:00
|
|
|
typedef void zio_cksum_free_f(void *cbdata, size_t size);
|
|
|
|
|
|
|
|
struct zio_bad_cksum; /* defined in zio_checksum.h */
|
2012-12-14 03:24:15 +04:00
|
|
|
struct dnode_phys;
|
2016-07-22 18:52:49 +03:00
|
|
|
struct abd;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
struct zio_cksum_report {
|
|
|
|
struct zio_cksum_report *zcr_next;
|
|
|
|
nvlist_t *zcr_ereport;
|
|
|
|
nvlist_t *zcr_detector;
|
|
|
|
void *zcr_cbdata;
|
|
|
|
size_t zcr_cbinfo; /* passed to zcr_free() */
|
Distributed Spare (dRAID) Feature
This patch adds a new top-level vdev type called dRAID, which stands
for Distributed parity RAID. This pool configuration allows all dRAID
vdevs to participate when rebuilding to a distributed hot spare device.
This can substantially reduce the total time required to restore full
parity to pool with a failed device.
A dRAID pool can be created using the new top-level `draid` type.
Like `raidz`, the desired redundancy is specified after the type:
`draid[1,2,3]`. No additional information is required to create the
pool and reasonable default values will be chosen based on the number
of child vdevs in the dRAID vdev.
zpool create <pool> draid[1,2,3] <vdevs...>
Unlike raidz, additional optional dRAID configuration values can be
provided as part of the draid type as colon separated values. This
allows administrators to fully specify a layout for either performance
or capacity reasons. The supported options include:
zpool create <pool> \
draid[<parity>][:<data>d][:<children>c][:<spares>s] \
<vdevs...>
- draid[parity] - Parity level (default 1)
- draid[:<data>d] - Data devices per group (default 8)
- draid[:<children>c] - Expected number of child vdevs
- draid[:<spares>s] - Distributed hot spares (default 0)
Abbreviated example `zpool status` output for a 68 disk dRAID pool
with two distributed spares using special allocation classes.
```
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
slag7 ONLINE 0 0 0
draid2:8d:68c:2s-0 ONLINE 0 0 0
L0 ONLINE 0 0 0
L1 ONLINE 0 0 0
...
U25 ONLINE 0 0 0
U26 ONLINE 0 0 0
spare-53 ONLINE 0 0 0
U27 ONLINE 0 0 0
draid2-0-0 ONLINE 0 0 0
U28 ONLINE 0 0 0
U29 ONLINE 0 0 0
...
U42 ONLINE 0 0 0
U43 ONLINE 0 0 0
special
mirror-1 ONLINE 0 0 0
L5 ONLINE 0 0 0
U5 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
L6 ONLINE 0 0 0
U6 ONLINE 0 0 0
spares
draid2-0-0 INUSE currently in use
draid2-0-1 AVAIL
```
When adding test coverage for the new dRAID vdev type the following
options were added to the ztest command. These options are leverages
by zloop.sh to test a wide range of dRAID configurations.
-K draid|raidz|random - kind of RAID to test
-D <value> - dRAID data drives per group
-S <value> - dRAID distributed hot spares
-R <value> - RAID parity (raidz or dRAID)
The zpool_create, zpool_import, redundancy, replacement and fault
test groups have all been updated provide test coverage for the
dRAID feature.
Co-authored-by: Isaac Huang <he.huang@intel.com>
Co-authored-by: Mark Maybee <mmaybee@cray.com>
Co-authored-by: Don Brady <don.brady@delphix.com>
Co-authored-by: Matthew Ahrens <mahrens@delphix.com>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mmaybee@cray.com>
Reviewed-by: Matt Ahrens <matt@delphix.com>
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #10102
2020-11-14 00:51:51 +03:00
|
|
|
uint64_t zcr_sector;
|
2010-05-29 00:45:14 +04:00
|
|
|
uint64_t zcr_align;
|
|
|
|
uint64_t zcr_length;
|
|
|
|
zio_cksum_finish_f *zcr_finish;
|
|
|
|
zio_cksum_free_f *zcr_free;
|
|
|
|
|
|
|
|
/* internal use only */
|
|
|
|
struct zio_bad_cksum *zcr_ckinfo; /* information from failure */
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef struct zio_vsd_ops {
|
|
|
|
zio_done_func_t *vsd_free;
|
|
|
|
} zio_vsd_ops_t;
|
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
typedef struct zio_gang_node {
|
|
|
|
zio_gbh_phys_t *gn_gbh;
|
|
|
|
struct zio_gang_node *gn_child[SPA_GBH_NBLKPTRS];
|
|
|
|
} zio_gang_node_t;
|
|
|
|
|
|
|
|
typedef zio_t *zio_gang_issue_func_t(zio_t *zio, blkptr_t *bp,
|
2016-07-22 18:52:49 +03:00
|
|
|
zio_gang_node_t *gn, struct abd *data, uint64_t offset);
|
2008-12-03 23:09:06 +03:00
|
|
|
|
2016-07-22 18:52:49 +03:00
|
|
|
typedef void zio_transform_func_t(zio_t *zio, struct abd *data, uint64_t size);
|
2008-12-03 23:09:06 +03:00
|
|
|
|
|
|
|
typedef struct zio_transform {
|
2016-07-22 18:52:49 +03:00
|
|
|
struct abd *zt_orig_abd;
|
2008-12-03 23:09:06 +03:00
|
|
|
uint64_t zt_orig_size;
|
|
|
|
uint64_t zt_bufsize;
|
|
|
|
zio_transform_func_t *zt_transform;
|
|
|
|
struct zio_transform *zt_next;
|
|
|
|
} zio_transform_t;
|
|
|
|
|
Reduce taskq and context-switch cost of zio pipe
When doing a read from disk, ZFS creates 3 ZIO's: a zio_null(), the
logical zio_read(), and then a physical zio. Currently, each of these
results in a separate taskq_dispatch(zio_execute).
On high-read-iops workloads, this causes a significant performance
impact. By processing all 3 ZIO's in a single taskq entry, we reduce the
overhead on taskq locking and context switching. We accomplish this by
allowing zio_done() to return a "next zio to execute" to zio_execute().
This results in a ~12% performance increase for random reads, from
96,000 iops to 108,000 iops (with recordsize=8k, on SSD's).
Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed by: George Wilson <george.wilson@delphix.com>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
External-issue: DLPX-59292
Closes #7736
2018-08-03 01:51:45 +03:00
|
|
|
typedef zio_t *zio_pipe_stage_t(zio_t *zio);
|
2008-12-03 23:09:06 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The io_reexecute flags are distinct from io_flags because the child must
|
|
|
|
* be able to propagate them to the parent. The normal io_flags are local
|
|
|
|
* to the zio, not protected by any lock, and not modifiable by children;
|
|
|
|
* the reexecute flags are protected by io_lock, modifiable by children,
|
|
|
|
* and always propagated -- even when ZIO_FLAG_DONT_PROPAGATE is set.
|
|
|
|
*/
|
|
|
|
#define ZIO_REEXECUTE_NOW 0x01
|
|
|
|
#define ZIO_REEXECUTE_SUSPEND 0x02
|
|
|
|
|
2019-03-29 19:13:20 +03:00
|
|
|
/*
|
|
|
|
* The io_trim flags are used to specify the type of TRIM to perform. They
|
|
|
|
* only apply to ZIO_TYPE_TRIM zios are distinct from io_flags.
|
|
|
|
*/
|
|
|
|
enum trim_flag {
|
2021-10-11 20:58:06 +03:00
|
|
|
ZIO_TRIM_SECURE = 1U << 0,
|
2019-03-29 19:13:20 +03:00
|
|
|
};
|
|
|
|
|
2017-01-12 22:52:56 +03:00
|
|
|
typedef struct zio_alloc_list {
|
|
|
|
list_t zal_list;
|
|
|
|
uint64_t zal_size;
|
|
|
|
} zio_alloc_list_t;
|
|
|
|
|
2009-02-18 23:51:31 +03:00
|
|
|
typedef struct zio_link {
|
|
|
|
zio_t *zl_parent;
|
|
|
|
zio_t *zl_child;
|
|
|
|
list_node_t zl_parent_node;
|
|
|
|
list_node_t zl_child_node;
|
|
|
|
} zio_link_t;
|
|
|
|
|
2023-06-27 19:09:48 +03:00
|
|
|
enum zio_qstate {
|
|
|
|
ZIO_QS_NONE = 0,
|
|
|
|
ZIO_QS_QUEUED,
|
|
|
|
ZIO_QS_ACTIVE,
|
|
|
|
};
|
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
struct zio {
|
|
|
|
/* Core information about this I/O */
|
2014-06-25 22:37:59 +04:00
|
|
|
zbookmark_phys_t io_bookmark;
|
2008-12-03 23:09:06 +03:00
|
|
|
zio_prop_t io_prop;
|
|
|
|
zio_type_t io_type;
|
|
|
|
enum zio_child io_child_type;
|
2019-03-29 19:13:20 +03:00
|
|
|
enum trim_flag io_trim_flags;
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 07:01:20 +04:00
|
|
|
zio_priority_t io_priority;
|
2008-12-03 23:09:06 +03:00
|
|
|
uint8_t io_reexecute;
|
2009-02-18 23:51:31 +03:00
|
|
|
uint8_t io_state[ZIO_WAIT_TYPES];
|
2008-11-20 23:01:55 +03:00
|
|
|
uint64_t io_txg;
|
2008-12-03 23:09:06 +03:00
|
|
|
spa_t *io_spa;
|
2008-11-20 23:01:55 +03:00
|
|
|
blkptr_t *io_bp;
|
2010-05-29 00:45:14 +04:00
|
|
|
blkptr_t *io_bp_override;
|
2008-11-20 23:01:55 +03:00
|
|
|
blkptr_t io_bp_copy;
|
2009-02-18 23:51:31 +03:00
|
|
|
list_t io_parent_list;
|
|
|
|
list_t io_child_list;
|
2008-11-20 23:01:55 +03:00
|
|
|
zio_t *io_logical;
|
2008-12-03 23:09:06 +03:00
|
|
|
zio_transform_t *io_transform_stack;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
/* Callback info */
|
2016-05-15 18:02:28 +03:00
|
|
|
zio_done_func_t *io_ready;
|
|
|
|
zio_done_func_t *io_children_ready;
|
2008-11-20 23:01:55 +03:00
|
|
|
zio_done_func_t *io_done;
|
|
|
|
void *io_private;
|
2010-05-29 00:45:14 +04:00
|
|
|
int64_t io_prev_space_delta; /* DMU private */
|
2008-11-20 23:01:55 +03:00
|
|
|
blkptr_t io_bp_orig;
|
2016-07-11 20:45:52 +03:00
|
|
|
/* io_lsize != io_orig_size iff this is a raw write */
|
|
|
|
uint64_t io_lsize;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
/* Data represented by this I/O */
|
2016-07-22 18:52:49 +03:00
|
|
|
struct abd *io_abd;
|
|
|
|
struct abd *io_orig_abd;
|
2008-11-20 23:01:55 +03:00
|
|
|
uint64_t io_size;
|
2010-05-29 00:45:14 +04:00
|
|
|
uint64_t io_orig_size;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
/* Stuff for the vdev stack */
|
|
|
|
vdev_t *io_vd;
|
|
|
|
void *io_vsd;
|
2010-05-29 00:45:14 +04:00
|
|
|
const zio_vsd_ops_t *io_vsd_ops;
|
2018-09-06 04:33:36 +03:00
|
|
|
metaslab_class_t *io_metaslab_class; /* dva throttle class */
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2023-06-27 19:09:48 +03:00
|
|
|
enum zio_qstate io_queue_state; /* vdev queue state */
|
|
|
|
union {
|
|
|
|
list_node_t l;
|
|
|
|
avl_node_t a;
|
|
|
|
} io_queue_node ____cacheline_aligned; /* allocator and vdev queues */
|
|
|
|
avl_node_t io_offset_node; /* vdev offset queues */
|
2008-11-20 23:01:55 +03:00
|
|
|
uint64_t io_offset;
|
2013-03-22 02:47:36 +04:00
|
|
|
hrtime_t io_timestamp; /* submitted at */
|
2016-10-14 03:59:18 +03:00
|
|
|
hrtime_t io_queued_timestamp;
|
2016-05-23 20:41:29 +03:00
|
|
|
hrtime_t io_target_timestamp;
|
2013-03-22 02:47:36 +04:00
|
|
|
hrtime_t io_delta; /* vdev queue service delta */
|
2016-02-29 21:05:23 +03:00
|
|
|
hrtime_t io_delay; /* Device access time (disk or */
|
|
|
|
/* file). */
|
2017-01-12 22:52:56 +03:00
|
|
|
zio_alloc_list_t io_alloc_list;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
/* Internal pipeline state */
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_flag_t io_flags;
|
2010-05-29 00:45:14 +04:00
|
|
|
enum zio_stage io_stage;
|
|
|
|
enum zio_stage io_pipeline;
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_flag_t io_orig_flags;
|
2010-05-29 00:45:14 +04:00
|
|
|
enum zio_stage io_orig_stage;
|
|
|
|
enum zio_stage io_orig_pipeline;
|
2016-10-14 03:59:18 +03:00
|
|
|
enum zio_stage io_pipeline_trace;
|
2008-12-03 23:09:06 +03:00
|
|
|
int io_error;
|
|
|
|
int io_child_error[ZIO_CHILD_TYPES];
|
|
|
|
uint64_t io_children[ZIO_CHILD_TYPES][ZIO_WAIT_TYPES];
|
|
|
|
uint64_t *io_stall;
|
2009-07-03 02:44:48 +04:00
|
|
|
zio_t *io_gang_leader;
|
2008-12-03 23:09:06 +03:00
|
|
|
zio_gang_node_t *io_gang_tree;
|
|
|
|
void *io_executor;
|
2008-11-20 23:01:55 +03:00
|
|
|
void *io_waiter;
|
2019-11-27 22:11:03 +03:00
|
|
|
void *io_bio;
|
2008-11-20 23:01:55 +03:00
|
|
|
kmutex_t io_lock;
|
|
|
|
kcondvar_t io_cv;
|
OpenZFS 9112 - Improve allocation performance on high-end systems
Overview
========
We parallelize the allocation process by creating the concept of
"allocators". There are a certain number of allocators per metaslab
group, defined by the value of a tunable at pool open time. Each
allocator for a given metaslab group has up to 2 active metaslabs; one
"primary", and one "secondary". The primary and secondary weight mean
the same thing they did in in the pre-allocator world; primary metaslabs
are used for most allocations, secondary metaslabs are used for ditto
blocks being allocated in the same metaslab group. There is also the
CLAIM weight, which has been separated out from the other weights, but
that is less important to understanding the patch. The active metaslabs
for each allocator are moved from their normal place in the metaslab
tree for the group to the back of the tree. This way, they will not be
selected for use by other allocators searching for new metaslabs unless
all the passive metaslabs are unsuitable for allocations. If that does
happen, the allocators will "steal" from each other to ensure that IOs
don't fail until there is truly no space left to perform allocations.
In addition, the alloc queue for each metaslab group has been broken
into a separate queue for each allocator. We don't want to dramatically
increase the number of inflight IOs on low-end systems, because it can
significantly increase txg times. On the other hand, we want to ensure
that there are enough IOs for each allocator to allow for good
coalescing before sending the IOs to the disk. As a result, we take a
compromise path; each allocator's alloc queue max depth starts at a
certain value for every txg. Every time an IO completes, we increase the
max depth. This should hopefully provide a good balance between the two
failure modes, while not dramatically increasing complexity.
We also parallelize the spa_alloc_tree and spa_alloc_lock, which cause
very similar contention when selecting IOs to allocate. This
parallelization uses the same allocator scheme as metaslab selection.
Performance Results
===================
Performance improvements from this change can vary significantly based
on the number of CPUs in the system, whether or not the system has a
NUMA architecture, the speed of the drives, the values for the various
tunables, and the workload being performed. For an fio async sequential
write workload on a 24 core NUMA system with 256 GB of RAM and 8 128 GB
SSDs, there is a roughly 25% performance improvement.
Future Work
===========
Analysis of the performance of the system with this patch applied shows
that a significant new bottleneck is the vdev disk queues, which also
need to be parallelized. Prototyping of this change has occurred, and
there was a performance improvement, but more work needs to be done
before its stability has been verified and it is ready to be upstreamed.
Authored by: Paul Dagnelie <pcd@delphix.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Serapheim Dimitropoulos <serapheim.dimitro@delphix.com>
Reviewed by: Alexander Motin <mav@FreeBSD.org>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Gordon Ross <gwr@nexenta.com>
Ported-by: Paul Dagnelie <pcd@delphix.com>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Porting Notes:
* Fix reservation test failures by increasing tolerance.
OpenZFS-issue: https://illumos.org/issues/9112
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/3f3cc3c3
Closes #7682
2018-02-12 23:56:06 +03:00
|
|
|
int io_allocator;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
/* FMA state */
|
2010-05-29 00:45:14 +04:00
|
|
|
zio_cksum_report_t *io_cksum_report;
|
2008-11-20 23:01:55 +03:00
|
|
|
uint64_t io_ena;
|
2011-11-08 04:26:52 +04:00
|
|
|
|
|
|
|
/* Taskq dispatching state */
|
|
|
|
taskq_ent_t io_tqent;
|
2008-11-20 23:01:55 +03:00
|
|
|
};
|
|
|
|
|
2020-02-11 01:00:05 +03:00
|
|
|
enum blk_verify_flag {
|
|
|
|
BLK_VERIFY_ONLY,
|
|
|
|
BLK_VERIFY_LOG,
|
|
|
|
BLK_VERIFY_HALT
|
|
|
|
};
|
|
|
|
|
Verify block pointers before writing them out
If a block pointer is corrupted (but the block containing it checksums
correctly, e.g. due to a bug that overwrites random memory), we can
often detect it before the block is read, with the `zfs_blkptr_verify()`
function, which is used in `arc_read()`, `zio_free()`, etc.
However, such corruption is not typically recoverable. To recover from
it we would need to detect the memory error before the block pointer is
written to disk.
This PR verifies BP's that are contained in indirect blocks and dnodes
before they are written to disk, in `dbuf_write_ready()`. This way,
we'll get a panic before the on-disk data is corrupted. This will help
us to diagnose what's causing the corruption, as well as being much
easier to recover from.
To minimize performance impact, only checks that can be done without
holding the spa_config_lock are performed.
Additionally, when corruption is detected, the raw words of the block
pointer are logged. (Note that `dprintf_bp()` is a no-op by default,
but if enabled it is not safe to use with invalid block pointers.)
Reviewed-by: Rich Ercolani <rincebrain@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Paul Zuchowski <pzuchowski@datto.com>
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #14817
2023-05-08 21:20:23 +03:00
|
|
|
enum blk_config_flag {
|
|
|
|
BLK_CONFIG_HELD, // SCL_VDEV held for writer
|
|
|
|
BLK_CONFIG_NEEDED, // SCL_VDEV should be obtained for reader
|
|
|
|
BLK_CONFIG_SKIP, // skip checks which require SCL_VDEV
|
|
|
|
};
|
|
|
|
|
2017-03-21 04:36:00 +03:00
|
|
|
extern int zio_bookmark_compare(const void *, const void *);
|
2016-10-14 03:59:18 +03:00
|
|
|
|
2009-02-18 23:51:31 +03:00
|
|
|
extern zio_t *zio_null(zio_t *pio, spa_t *spa, vdev_t *vd,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_done_func_t *done, void *priv, zio_flag_t flags);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
extern zio_t *zio_root(spa_t *spa,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_done_func_t *done, void *priv, zio_flag_t flags);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2022-07-29 01:52:46 +03:00
|
|
|
extern void zio_destroy(zio_t *zio);
|
|
|
|
|
2016-07-22 18:52:49 +03:00
|
|
|
extern zio_t *zio_read(zio_t *pio, spa_t *spa, const blkptr_t *bp,
|
2020-06-06 22:54:04 +03:00
|
|
|
struct abd *data, uint64_t lsize, zio_done_func_t *done, void *priv,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_priority_t priority, zio_flag_t flags, const zbookmark_phys_t *zb);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
extern zio_t *zio_write(zio_t *pio, spa_t *spa, uint64_t txg, blkptr_t *bp,
|
2016-07-22 18:52:49 +03:00
|
|
|
struct abd *data, uint64_t size, uint64_t psize, const zio_prop_t *zp,
|
2016-05-15 18:02:28 +03:00
|
|
|
zio_done_func_t *ready, zio_done_func_t *children_ready,
|
Remove ARC/ZIO physdone callbacks.
Those callbacks were introduced many years ago as part of a bigger
patch to smoothen the write throttling within a txg. They allow to
account completion of individual physical writes within a logical
one, improving cases when some of physical writes complete much
sooner than others, gradually opening the write throttle.
Few years after that ZFS got allocation throttling, working on a
level of logical writes and limiting number of writes queued to
vdevs at any point, and so limiting latency distribution between
the physical writes and especially writes of multiple copies.
The addition of scheduling deadline I proposed in #14925 should
further reduce the latency distribution. Grown memory sizes over
the past 10 years should also reduce importance of the smoothing.
While the use of physdone callback may still in theory provide
some smoother throttling, there are cases where we simply can not
afford it. Since dirty data accounting is protected by pool-wide
lock, in case of 6-wide RAIDZ, for example, it requires us to take
it 8 times per logical block write, creating huge lock contention.
My tests of this patch show radical reduction of the lock spinning
time on workloads when smaller blocks are written to RAIDZ pools,
when each of the disks receives 8-16KB chunks, but the total rate
reaching 100K+ blocks per second. Same time attempts to measure
any write time fluctuations didn't show anything noticeable.
While there, remove also io_child_count/io_parent_count counters.
They are used only for couple assertions that can be avoided.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes #14948
2023-06-15 20:49:03 +03:00
|
|
|
zio_done_func_t *done, void *priv, zio_priority_t priority,
|
|
|
|
zio_flag_t flags, const zbookmark_phys_t *zb);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
extern zio_t *zio_rewrite(zio_t *pio, spa_t *spa, uint64_t txg, blkptr_t *bp,
|
2020-06-06 22:54:04 +03:00
|
|
|
struct abd *data, uint64_t size, zio_done_func_t *done, void *priv,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_priority_t priority, zio_flag_t flags, zbookmark_phys_t *zb);
|
2008-12-03 23:09:06 +03:00
|
|
|
|
2013-05-10 23:47:54 +04:00
|
|
|
extern void zio_write_override(zio_t *zio, blkptr_t *bp, int copies,
|
2023-03-10 22:59:53 +03:00
|
|
|
boolean_t nopwrite, boolean_t brtwrite);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
extern void zio_free(spa_t *spa, uint64_t txg, const blkptr_t *bp);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
extern zio_t *zio_claim(zio_t *pio, spa_t *spa, uint64_t txg,
|
|
|
|
const blkptr_t *bp,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_done_func_t *done, void *priv, zio_flag_t flags);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2019-03-29 19:13:20 +03:00
|
|
|
extern zio_t *zio_trim(zio_t *pio, vdev_t *vd, uint64_t offset, uint64_t size,
|
2020-06-06 22:54:04 +03:00
|
|
|
zio_done_func_t *done, void *priv, zio_priority_t priority,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_flag_t flags, enum trim_flag trim_flags);
|
2019-03-29 19:13:20 +03:00
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
extern zio_t *zio_read_phys(zio_t *pio, vdev_t *vd, uint64_t offset,
|
2016-07-22 18:52:49 +03:00
|
|
|
uint64_t size, struct abd *data, int checksum,
|
2020-06-06 22:54:04 +03:00
|
|
|
zio_done_func_t *done, void *priv, zio_priority_t priority,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_flag_t flags, boolean_t labels);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
extern zio_t *zio_write_phys(zio_t *pio, vdev_t *vd, uint64_t offset,
|
2016-07-22 18:52:49 +03:00
|
|
|
uint64_t size, struct abd *data, int checksum,
|
2020-06-06 22:54:04 +03:00
|
|
|
zio_done_func_t *done, void *priv, zio_priority_t priority,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_flag_t flags, boolean_t labels);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
extern zio_t *zio_free_sync(zio_t *pio, spa_t *spa, uint64_t txg,
|
2022-10-27 19:54:54 +03:00
|
|
|
const blkptr_t *bp, zio_flag_t flags);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
Native Encryption for ZFS on Linux
This change incorporates three major pieces:
The first change is a keystore that manages wrapping
and encryption keys for encrypted datasets. These
commands mostly involve manipulating the new
DSL Crypto Key ZAP Objects that live in the MOS. Each
encrypted dataset has its own DSL Crypto Key that is
protected with a user's key. This level of indirection
allows users to change their keys without re-encrypting
their entire datasets. The change implements the new
subcommands "zfs load-key", "zfs unload-key" and
"zfs change-key" which allow the user to manage their
encryption keys and settings. In addition, several new
flags and properties have been added to allow dataset
creation and to make mounting and unmounting more
convenient.
The second piece of this patch provides the ability to
encrypt, decyrpt, and authenticate protected datasets.
Each object set maintains a Merkel tree of Message
Authentication Codes that protect the lower layers,
similarly to how checksums are maintained. This part
impacts the zio layer, which handles the actual
encryption and generation of MACs, as well as the ARC
and DMU, which need to be able to handle encrypted
buffers and protected data.
The last addition is the ability to do raw, encrypted
sends and receives. The idea here is to send raw
encrypted and compressed data and receive it exactly
as is on a backup system. This means that the dataset
on the receiving system is protected using the same
user key that is in use on the sending side. By doing
so, datasets can be efficiently backed up to an
untrusted system without fear of data being
compromised.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Jorgen Lundman <lundman@lundman.net>
Signed-off-by: Tom Caputi <tcaputi@datto.com>
Closes #494
Closes #5769
2017-08-14 20:36:48 +03:00
|
|
|
extern int zio_alloc_zil(spa_t *spa, objset_t *os, uint64_t txg,
|
|
|
|
blkptr_t *new_bp, uint64_t size, boolean_t *slog);
|
2008-11-20 23:01:55 +03:00
|
|
|
extern void zio_flush(zio_t *zio, vdev_t *vd);
|
2010-05-29 00:45:14 +04:00
|
|
|
extern void zio_shrink(zio_t *zio, uint64_t size);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2024-05-29 23:50:25 +03:00
|
|
|
extern size_t zio_get_compression_max_size(enum zio_compress compress,
|
|
|
|
uint64_t gcd_alloc, uint64_t min_alloc, size_t s_len);
|
2008-11-20 23:01:55 +03:00
|
|
|
extern int zio_wait(zio_t *zio);
|
|
|
|
extern void zio_nowait(zio_t *zio);
|
2021-07-20 17:03:33 +03:00
|
|
|
extern void zio_execute(void *zio);
|
|
|
|
extern void zio_interrupt(void *zio);
|
2016-05-23 20:41:29 +03:00
|
|
|
extern void zio_delay_init(zio_t *zio);
|
|
|
|
extern void zio_delay_interrupt(zio_t *zio);
|
2022-04-19 21:49:30 +03:00
|
|
|
extern void zio_deadman(zio_t *zio, const char *tag);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2016-10-14 03:59:18 +03:00
|
|
|
extern zio_t *zio_walk_parents(zio_t *cio, zio_link_t **);
|
|
|
|
extern zio_t *zio_walk_children(zio_t *pio, zio_link_t **);
|
2009-02-18 23:51:31 +03:00
|
|
|
extern zio_t *zio_unique_parent(zio_t *cio);
|
|
|
|
extern void zio_add_child(zio_t *pio, zio_t *cio);
|
2023-06-30 18:54:00 +03:00
|
|
|
extern void zio_add_child_first(zio_t *pio, zio_t *cio);
|
2009-02-18 23:51:31 +03:00
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
extern void *zio_buf_alloc(size_t size);
|
|
|
|
extern void zio_buf_free(void *buf, size_t size);
|
|
|
|
extern void *zio_data_buf_alloc(size_t size);
|
|
|
|
extern void zio_data_buf_free(void *buf, size_t size);
|
|
|
|
|
2016-07-22 18:52:49 +03:00
|
|
|
extern void zio_push_transform(zio_t *zio, struct abd *abd, uint64_t size,
|
2016-06-02 07:04:53 +03:00
|
|
|
uint64_t bufsize, zio_transform_func_t *transform);
|
|
|
|
extern void zio_pop_transforms(zio_t *zio);
|
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
extern void zio_resubmit_stage_async(void *);
|
|
|
|
|
|
|
|
extern zio_t *zio_vdev_child_io(zio_t *zio, blkptr_t *bp, vdev_t *vd,
|
2016-07-22 18:52:49 +03:00
|
|
|
uint64_t offset, struct abd *data, uint64_t size, int type,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_priority_t priority, zio_flag_t flags,
|
2020-06-06 22:54:04 +03:00
|
|
|
zio_done_func_t *done, void *priv);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2008-12-03 23:09:06 +03:00
|
|
|
extern zio_t *zio_vdev_delegated_io(vdev_t *vd, uint64_t offset,
|
OpenZFS 9290 - device removal reduces redundancy of mirrors
Mirrors are supposed to provide redundancy in the face of whole-disk
failure and silent damage (e.g. some data on disk is not right, but ZFS
hasn't detected the whole device as being broken). However, the current
device removal implementation bypasses some of the mirror's redundancy.
Note that in no case is incorrect data returned, but we might get a
checksum error when we should have been able to find the right data.
There are two underlying problems:
1. When we remove a mirror device, we only read one side of the mirror.
Since we can't verify the checksum, this side may be silently bad, but
the good data is on the other side of the mirror (which we didn't read).
This can cause the removal to "bake in" the busted data – all copies of
the data in the new location are the same, busted version, while we left
the good version behind.
The fix for this is to read and copy both sides of the mirror. If the
old and new vdevs are mirrors, we will read both sides of the old
mirror, and write each copy to the corresponding side of the new mirror.
(If the old and new vdevs have a different number of children, we will
do this as best as possible.) Even though we aren't verifying checksums,
this ensures that as long as there's a good copy of the data, we'll have
a good copy after the removal, even if there's silent damage to one side
of the mirror. If we're removing a mirror that has some silent damage,
we'll have exactly the same damage in the new location (assuming that
the new location is also a mirror).
2. When we read from an indirect vdev that points to a mirror vdev, we
only consider one copy of the data. This can lead to reduced effective
redundancy, because we might read a bad copy of the data from one side
of the mirror, and not retry the other, good side of the mirror.
Note that the problem is not with the removal process, but rather after
the removal has completed (having copied correct data to both sides of
the mirror), if one side of the new mirror is silently damaged, we
encounter the problem when reading the relocated data via the indirect
vdev. Also note that the problem doesn't occur when ZFS knows that one
side of the mirror is bad, e.g. when a disk entirely fails or is
offlined.
The impact is that reads (from indirect vdevs that point to mirrors) may
return a checksum error even though the good data exists on one side of
the mirror, and scrub doesn't repair all data on the mirror (if some of
it is pointed to via an indirect vdev).
The fix for this is complicated by "split blocks" - one logical block
may be split into two (or more) pieces with each piece moved to a
different new location. In this case we need to read all versions of
each split (one from each side of the mirror), and figure out which
combination of versions results in the correct checksum, and then repair
the incorrect versions.
This ensures that we supply the same redundancy whether you use device
removal or not. For example, if a mirror has small silent errors on all
of its children, we can still reconstruct the correct data, as long as
those errors are at sufficiently-separated offsets (specifically,
separated by the largest block size - default of 128KB, but up to 16MB).
Porting notes:
* A new indirect vdev check was moved from dsl_scan_needs_resilver_cb()
to dsl_scan_needs_resilver(), which was added to ZoL as part of the
sequential scrub work.
* Passed NULL for zfs_ereport_post_checksum()'s zbookmark_phys_t
parameter. The extra parameter is unique to ZoL.
* When posting indirect checksum errors the ABD can be passed directly,
zfs_ereport_post_checksum() is not yet ABD-aware in OpenZFS.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Ported-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://illumos.org/issues/9290
OpenZFS-commit: https://github.com/openzfs/openzfs/pull/591
Closes #6900
2018-02-13 22:37:56 +03:00
|
|
|
struct abd *data, uint64_t size, zio_type_t type, zio_priority_t priority,
|
2022-10-27 19:54:54 +03:00
|
|
|
zio_flag_t flags, zio_done_func_t *done, void *priv);
|
2008-12-03 23:09:06 +03:00
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
extern void zio_vdev_io_bypass(zio_t *zio);
|
|
|
|
extern void zio_vdev_io_reissue(zio_t *zio);
|
|
|
|
extern void zio_vdev_io_redone(zio_t *zio);
|
|
|
|
|
2017-12-21 20:13:06 +03:00
|
|
|
extern void zio_change_priority(zio_t *pio, zio_priority_t priority);
|
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
extern void zio_checksum_verified(zio_t *zio);
|
2008-12-03 23:09:06 +03:00
|
|
|
extern int zio_worst_error(int e1, int e2);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
extern enum zio_checksum zio_checksum_select(enum zio_checksum child,
|
|
|
|
enum zio_checksum parent);
|
|
|
|
extern enum zio_checksum zio_checksum_dedup_select(spa_t *spa,
|
|
|
|
enum zio_checksum child, enum zio_checksum parent);
|
2015-07-06 04:55:32 +03:00
|
|
|
extern enum zio_compress zio_compress_select(spa_t *spa,
|
|
|
|
enum zio_compress child, enum zio_compress parent);
|
Add zstd support to zfs
This PR adds two new compression types, based on ZStandard:
- zstd: A basic ZStandard compression algorithm Available compression.
Levels for zstd are zstd-1 through zstd-19, where the compression
increases with every level, but speed decreases.
- zstd-fast: A faster version of the ZStandard compression algorithm
zstd-fast is basically a "negative" level of zstd. The compression
decreases with every level, but speed increases.
Available compression levels for zstd-fast:
- zstd-fast-1 through zstd-fast-10
- zstd-fast-20 through zstd-fast-100 (in increments of 10)
- zstd-fast-500 and zstd-fast-1000
For more information check the man page.
Implementation details:
Rather than treat each level of zstd as a different algorithm (as was
done historically with gzip), the block pointer `enum zio_compress`
value is simply zstd for all levels, including zstd-fast, since they all
use the same decompression function.
The compress= property (a 64bit unsigned integer) uses the lower 7 bits
to store the compression algorithm (matching the number of bits used in
a block pointer, as the 8th bit was borrowed for embedded block
pointers). The upper bits are used to store the compression level.
It is necessary to be able to determine what compression level was used
when later reading a block back, so the concept used in LZ4, where the
first 32bits of the on-disk value are the size of the compressed data
(since the allocation is rounded up to the nearest ashift), was
extended, and we store the version of ZSTD and the level as well as the
compressed size. This value is returned when decompressing a block, so
that if the block needs to be recompressed (L2ARC, nop-write, etc), that
the same parameters will be used to result in the matching checksum.
All of the internal ZFS code ( `arc_buf_hdr_t`, `objset_t`,
`zio_prop_t`, etc.) uses the separated _compress and _complevel
variables. Only the properties ZAP contains the combined/bit-shifted
value. The combined value is split when the compression_changed_cb()
callback is called, and sets both objset members (os_compress and
os_complevel).
The userspace tools all use the combined/bit-shifted value.
Additional notes:
zdb can now also decode the ZSTD compression header (flag -Z) and
inspect the size, version and compression level saved in that header.
For each record, if it is ZSTD compressed, the parameters of the decoded
compression header get printed.
ZSTD is included with all current tests and new tests are added
as-needed.
Per-dataset feature flags now get activated when the property is set.
If a compression algorithm requires a feature flag, zfs activates the
feature when the property is set, rather than waiting for the first
block to be born. This is currently only used by zstd but can be
extended as needed.
Portions-Sponsored-By: The FreeBSD Foundation
Co-authored-by: Allan Jude <allanjude@freebsd.org>
Co-authored-by: Brian Behlendorf <behlendorf1@llnl.gov>
Co-authored-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Co-authored-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Co-authored-by: Michael Niewöhner <foss@mniewoehner.de>
Signed-off-by: Allan Jude <allan@klarasystems.com>
Signed-off-by: Allan Jude <allanjude@freebsd.org>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kjeld Schouten-Lebbing <kjeld@schouten-lebbing.nl>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Closes #6247
Closes #9024
Closes #10277
Closes #10278
2020-08-18 20:10:17 +03:00
|
|
|
extern uint8_t zio_complevel_select(spa_t *spa, enum zio_compress compress,
|
|
|
|
uint8_t child, uint8_t parent);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2018-03-15 20:56:55 +03:00
|
|
|
extern void zio_suspend(spa_t *spa, zio_t *zio, zio_suspend_reason_t);
|
2009-07-03 02:44:48 +04:00
|
|
|
extern int zio_resume(spa_t *spa);
|
2008-12-03 23:09:06 +03:00
|
|
|
extern void zio_resume_wait(spa_t *spa);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2020-02-11 01:00:05 +03:00
|
|
|
extern boolean_t zfs_blkptr_verify(spa_t *spa, const blkptr_t *bp,
|
Verify block pointers before writing them out
If a block pointer is corrupted (but the block containing it checksums
correctly, e.g. due to a bug that overwrites random memory), we can
often detect it before the block is read, with the `zfs_blkptr_verify()`
function, which is used in `arc_read()`, `zio_free()`, etc.
However, such corruption is not typically recoverable. To recover from
it we would need to detect the memory error before the block pointer is
written to disk.
This PR verifies BP's that are contained in indirect blocks and dnodes
before they are written to disk, in `dbuf_write_ready()`. This way,
we'll get a panic before the on-disk data is corrupted. This will help
us to diagnose what's causing the corruption, as well as being much
easier to recover from.
To minimize performance impact, only checks that can be done without
holding the spa_config_lock are performed.
Additionally, when corruption is detected, the raw words of the block
pointer are logged. (Note that `dprintf_bp()` is a no-op by default,
but if enabled it is not safe to use with invalid block pointers.)
Reviewed-by: Rich Ercolani <rincebrain@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Paul Zuchowski <pzuchowski@datto.com>
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #14817
2023-05-08 21:20:23 +03:00
|
|
|
enum blk_config_flag blk_config, enum blk_verify_flag blk_verify);
|
2020-02-11 01:00:05 +03:00
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
/*
|
|
|
|
* Initial setup and teardown.
|
|
|
|
*/
|
|
|
|
extern void zio_init(void);
|
|
|
|
extern void zio_fini(void);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fault injection
|
|
|
|
*/
|
|
|
|
struct zinject_record;
|
|
|
|
extern uint32_t zio_injection_enabled;
|
|
|
|
extern int zio_inject_fault(char *name, int flags, int *id,
|
|
|
|
struct zinject_record *record);
|
|
|
|
extern int zio_inject_list_next(int *id, char *name, size_t buflen,
|
|
|
|
struct zinject_record *record);
|
|
|
|
extern int zio_clear_fault(int id);
|
2022-04-19 21:49:30 +03:00
|
|
|
extern void zio_handle_panic_injection(spa_t *spa, const char *tag,
|
|
|
|
uint64_t type);
|
2018-05-03 01:36:20 +03:00
|
|
|
extern int zio_handle_decrypt_injection(spa_t *spa, const zbookmark_phys_t *zb,
|
|
|
|
uint64_t type, int error);
|
2008-11-20 23:01:55 +03:00
|
|
|
extern int zio_handle_fault_injection(zio_t *zio, int error);
|
2009-07-03 02:44:48 +04:00
|
|
|
extern int zio_handle_device_injection(vdev_t *vd, zio_t *zio, int error);
|
2017-08-15 01:17:15 +03:00
|
|
|
extern int zio_handle_device_injections(vdev_t *vd, zio_t *zio, int err1,
|
|
|
|
int err2);
|
2008-12-03 23:09:06 +03:00
|
|
|
extern int zio_handle_label_injection(zio_t *zio, int error);
|
2010-05-29 00:45:14 +04:00
|
|
|
extern void zio_handle_ignored_writes(zio_t *zio);
|
2016-05-23 20:41:29 +03:00
|
|
|
extern hrtime_t zio_handle_io_delay(zio_t *zio);
|
2024-04-22 19:42:38 +03:00
|
|
|
extern void zio_handle_import_delay(spa_t *spa, hrtime_t elapsed);
|
|
|
|
extern void zio_handle_export_delay(spa_t *spa, hrtime_t elapsed);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Checksum ereport functions
|
|
|
|
*/
|
2020-09-04 20:34:28 +03:00
|
|
|
extern int zfs_ereport_start_checksum(spa_t *spa, vdev_t *vd,
|
2018-03-31 21:12:51 +03:00
|
|
|
const zbookmark_phys_t *zb, struct zio *zio, uint64_t offset,
|
Clean up RAIDZ/DRAID ereport code
The RAIDZ and DRAID code is responsible for reporting checksum errors on
their child vdevs. Checksum errors represent events where a disk
returned data or parity that should have been correct, but was not. In
other words, these are instances of silent data corruption. The
checksum errors show up in the vdev stats (and thus `zpool status`'s
CKSUM column), and in the event log (`zpool events`).
Note, this is in contrast with the more common "noisy" errors where a
disk goes offline, in which case ZFS knows that the disk is bad and
doesn't try to read it, or the device returns an error on the requested
read or write operation.
RAIDZ/DRAID generate checksum errors via three code paths:
1. When RAIDZ/DRAID reconstructs a damaged block, checksum errors are
reported on any children whose data was not used during the
reconstruction. This is handled in `raidz_reconstruct()`. This is the
most common type of RAIDZ/DRAID checksum error.
2. When RAIDZ/DRAID is not able to reconstruct a damaged block, that
means that the data has been lost. The zio fails and an error is
returned to the consumer (e.g. the read(2) system call). This would
happen if, for example, three different disks in a RAIDZ2 group are
silently damaged. Since the damage is silent, it isn't possible to know
which three disks are damaged, so a checksum error is reported against
every child that returned data or parity for this read. (For DRAID,
typically only one "group" of children is involved in each io.) This
case is handled in `vdev_raidz_cksum_finish()`. This is the next most
common type of RAIDZ/DRAID checksum error.
3. If RAIDZ/DRAID is not able to reconstruct a damaged block (like in
case 2), but there happens to be additional copies of this block due to
"ditto blocks" (i.e. multiple DVA's in this blkptr_t), and one of those
copies is good, then RAIDZ/DRAID compares each sector of the data or
parity that it retrieved with the good data from the other DVA, and if
they differ then it reports a checksum error on this child. This
differs from case 2 in that the checksum error is reported on only the
subset of children that actually have bad data or parity. This case
happens very rarely, since normally only metadata has ditto blocks. If
the silent damage is extensive, there will be many instances of case 2,
and the pool will likely be unrecoverable.
The code for handling case 3 is considerably more complicated than the
other cases, for two reasons:
1. It needs to run after the main raidz read logic has completed. The
data RAIDZ read needs to be preserved until after the alternate DVA has
been read, which necessitates refcounts and callbacks managed by the
non-raidz-specific zio layer.
2. It's nontrivial to map the sections of data read by RAIDZ to the
correct data. For example, the correct data does not include the parity
information, so the parity must be recalculated based on the correct
data, and then compared to the parity that was read from the RAIDZ
children.
Due to the complexity of case 3, the rareness of hitting it, and the
minimal benefit it provides above case 2, this commit removes the code
for case 3. These types of errors will now be handled the same as case
2, i.e. the checksum error will be reported against all children that
returned data or parity.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #11735
2021-03-20 02:22:10 +03:00
|
|
|
uint64_t length, struct zio_bad_cksum *info);
|
2010-05-29 00:45:14 +04:00
|
|
|
extern void zfs_ereport_finish_checksum(zio_cksum_report_t *report,
|
2017-01-05 22:10:07 +03:00
|
|
|
const abd_t *good_data, const abd_t *bad_data, boolean_t drop_if_identical);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
|
|
|
extern void zfs_ereport_free_checksum(zio_cksum_report_t *report);
|
|
|
|
|
|
|
|
/* If we have the good data in hand, this function can be used */
|
2018-11-09 03:47:24 +03:00
|
|
|
extern int zfs_ereport_post_checksum(spa_t *spa, vdev_t *vd,
|
2018-03-31 21:12:51 +03:00
|
|
|
const zbookmark_phys_t *zb, struct zio *zio, uint64_t offset,
|
|
|
|
uint64_t length, const abd_t *good_data, const abd_t *bad_data,
|
|
|
|
struct zio_bad_cksum *info);
|
2010-05-29 00:45:14 +04:00
|
|
|
|
Clean up RAIDZ/DRAID ereport code
The RAIDZ and DRAID code is responsible for reporting checksum errors on
their child vdevs. Checksum errors represent events where a disk
returned data or parity that should have been correct, but was not. In
other words, these are instances of silent data corruption. The
checksum errors show up in the vdev stats (and thus `zpool status`'s
CKSUM column), and in the event log (`zpool events`).
Note, this is in contrast with the more common "noisy" errors where a
disk goes offline, in which case ZFS knows that the disk is bad and
doesn't try to read it, or the device returns an error on the requested
read or write operation.
RAIDZ/DRAID generate checksum errors via three code paths:
1. When RAIDZ/DRAID reconstructs a damaged block, checksum errors are
reported on any children whose data was not used during the
reconstruction. This is handled in `raidz_reconstruct()`. This is the
most common type of RAIDZ/DRAID checksum error.
2. When RAIDZ/DRAID is not able to reconstruct a damaged block, that
means that the data has been lost. The zio fails and an error is
returned to the consumer (e.g. the read(2) system call). This would
happen if, for example, three different disks in a RAIDZ2 group are
silently damaged. Since the damage is silent, it isn't possible to know
which three disks are damaged, so a checksum error is reported against
every child that returned data or parity for this read. (For DRAID,
typically only one "group" of children is involved in each io.) This
case is handled in `vdev_raidz_cksum_finish()`. This is the next most
common type of RAIDZ/DRAID checksum error.
3. If RAIDZ/DRAID is not able to reconstruct a damaged block (like in
case 2), but there happens to be additional copies of this block due to
"ditto blocks" (i.e. multiple DVA's in this blkptr_t), and one of those
copies is good, then RAIDZ/DRAID compares each sector of the data or
parity that it retrieved with the good data from the other DVA, and if
they differ then it reports a checksum error on this child. This
differs from case 2 in that the checksum error is reported on only the
subset of children that actually have bad data or parity. This case
happens very rarely, since normally only metadata has ditto blocks. If
the silent damage is extensive, there will be many instances of case 2,
and the pool will likely be unrecoverable.
The code for handling case 3 is considerably more complicated than the
other cases, for two reasons:
1. It needs to run after the main raidz read logic has completed. The
data RAIDZ read needs to be preserved until after the alternate DVA has
been read, which necessitates refcounts and callbacks managed by the
non-raidz-specific zio layer.
2. It's nontrivial to map the sections of data read by RAIDZ to the
correct data. For example, the correct data does not include the parity
information, so the parity must be recalculated based on the correct
data, and then compared to the parity that was read from the RAIDZ
children.
Due to the complexity of case 3, the rareness of hitting it, and the
minimal benefit it provides above case 2, this commit removes the code
for case 3. These types of errors will now be handled the same as case
2, i.e. the checksum error will be reported against all children that
returned data or parity.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #11735
2021-03-20 02:22:10 +03:00
|
|
|
void zio_vsd_default_cksum_report(zio_t *zio, zio_cksum_report_t *zcr);
|
2021-09-09 20:44:21 +03:00
|
|
|
extern void zfs_ereport_snapshot_post(const char *subclass, spa_t *spa,
|
|
|
|
const char *name);
|
Clean up RAIDZ/DRAID ereport code
The RAIDZ and DRAID code is responsible for reporting checksum errors on
their child vdevs. Checksum errors represent events where a disk
returned data or parity that should have been correct, but was not. In
other words, these are instances of silent data corruption. The
checksum errors show up in the vdev stats (and thus `zpool status`'s
CKSUM column), and in the event log (`zpool events`).
Note, this is in contrast with the more common "noisy" errors where a
disk goes offline, in which case ZFS knows that the disk is bad and
doesn't try to read it, or the device returns an error on the requested
read or write operation.
RAIDZ/DRAID generate checksum errors via three code paths:
1. When RAIDZ/DRAID reconstructs a damaged block, checksum errors are
reported on any children whose data was not used during the
reconstruction. This is handled in `raidz_reconstruct()`. This is the
most common type of RAIDZ/DRAID checksum error.
2. When RAIDZ/DRAID is not able to reconstruct a damaged block, that
means that the data has been lost. The zio fails and an error is
returned to the consumer (e.g. the read(2) system call). This would
happen if, for example, three different disks in a RAIDZ2 group are
silently damaged. Since the damage is silent, it isn't possible to know
which three disks are damaged, so a checksum error is reported against
every child that returned data or parity for this read. (For DRAID,
typically only one "group" of children is involved in each io.) This
case is handled in `vdev_raidz_cksum_finish()`. This is the next most
common type of RAIDZ/DRAID checksum error.
3. If RAIDZ/DRAID is not able to reconstruct a damaged block (like in
case 2), but there happens to be additional copies of this block due to
"ditto blocks" (i.e. multiple DVA's in this blkptr_t), and one of those
copies is good, then RAIDZ/DRAID compares each sector of the data or
parity that it retrieved with the good data from the other DVA, and if
they differ then it reports a checksum error on this child. This
differs from case 2 in that the checksum error is reported on only the
subset of children that actually have bad data or parity. This case
happens very rarely, since normally only metadata has ditto blocks. If
the silent damage is extensive, there will be many instances of case 2,
and the pool will likely be unrecoverable.
The code for handling case 3 is considerably more complicated than the
other cases, for two reasons:
1. It needs to run after the main raidz read logic has completed. The
data RAIDZ read needs to be preserved until after the alternate DVA has
been read, which necessitates refcounts and callbacks managed by the
non-raidz-specific zio layer.
2. It's nontrivial to map the sections of data read by RAIDZ to the
correct data. For example, the correct data does not include the parity
information, so the parity must be recalculated based on the correct
data, and then compared to the parity that was read from the RAIDZ
children.
Due to the complexity of case 3, the rareness of hitting it, and the
minimal benefit it provides above case 2, this commit removes the code
for case 3. These types of errors will now be handled the same as case
2, i.e. the checksum error will be reported against all children that
returned data or parity.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #11735
2021-03-20 02:22:10 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
/* Called from spa_sync(), but primarily an injection handler */
|
|
|
|
extern void spa_handle_ignored_writes(spa_t *spa);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2014-06-25 22:37:59 +04:00
|
|
|
/* zbookmark_phys functions */
|
2015-12-22 04:31:57 +03:00
|
|
|
boolean_t zbookmark_subtree_completed(const struct dnode_phys *dnp,
|
|
|
|
const zbookmark_phys_t *subtree_root, const zbookmark_phys_t *last_block);
|
2022-07-21 03:02:36 +03:00
|
|
|
boolean_t zbookmark_subtree_tbd(const struct dnode_phys *dnp,
|
|
|
|
const zbookmark_phys_t *subtree_root, const zbookmark_phys_t *last_block);
|
2015-12-22 04:31:57 +03:00
|
|
|
int zbookmark_compare(uint16_t dbss1, uint8_t ibs1, uint16_t dbss2,
|
|
|
|
uint8_t ibs2, const zbookmark_phys_t *zb1, const zbookmark_phys_t *zb2);
|
2012-12-14 03:24:15 +04:00
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif /* _ZIO_H */
|