2013-08-28 13:45:09 +02: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
|
|
|
|
|
* or http://www.opensolaris.org/os/licensing.
|
|
|
|
|
* 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
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
2020-05-07 18:36:33 +02:00
|
|
|
* Copyright (c) 2012, 2020 by Delphix. All rights reserved.
|
2017-05-19 21:33:11 +02:00
|
|
|
* Copyright (c) 2017 Datto Inc.
|
2017-06-27 01:56:09 +02:00
|
|
|
* Copyright 2017 RackTop Systems.
|
2017-10-26 21:26:09 +02:00
|
|
|
* Copyright (c) 2017 Open-E, Inc. All Rights Reserved.
|
2013-08-28 13:45:09 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _LIBZFS_CORE_H
|
2021-06-03 23:50:07 +02:00
|
|
|
#define _LIBZFS_CORE_H extern __attribute__((visibility("default")))
|
2013-08-28 13:45:09 +02:00
|
|
|
|
|
|
|
|
#include <libnvpair.h>
|
|
|
|
|
#include <sys/param.h>
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
|
#include <sys/fs/zfs.h>
|
|
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int libzfs_core_init(void);
|
|
|
|
|
_LIBZFS_CORE_H void libzfs_core_fini(void);
|
2013-08-28 13:45:09 +02:00
|
|
|
|
2021-10-07 19:31:26 +02:00
|
|
|
struct zfs_cmd;
|
|
|
|
|
_LIBZFS_CORE_H int lzc_ioctl_fd(int, unsigned long, struct zfs_cmd *);
|
|
|
|
|
|
2017-01-23 18:49:57 +01:00
|
|
|
/*
|
2021-06-03 23:50:07 +02:00
|
|
|
* NB: this type should be kept binary-compatible with dmu_objset_type_t.
|
2017-01-23 18:49:57 +01:00
|
|
|
*/
|
|
|
|
|
enum lzc_dataset_type {
|
|
|
|
|
LZC_DATSET_TYPE_ZFS = 2,
|
|
|
|
|
LZC_DATSET_TYPE_ZVOL
|
|
|
|
|
};
|
|
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_snapshot(nvlist_t *, nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_create(const char *, enum lzc_dataset_type, nvlist_t *,
|
|
|
|
|
uint8_t *, uint_t);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_clone(const char *, const char *, nvlist_t *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_promote(const char *, char *, int);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_destroy_snaps(nvlist_t *, boolean_t, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_bookmark(nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_get_bookmarks(const char *, nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_get_bookmark_props(const char *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_destroy_bookmarks(nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_load_key(const char *, boolean_t, uint8_t *, uint_t);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_unload_key(const char *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_change_key(const char *, uint64_t, nvlist_t *, uint8_t *,
|
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 19:36:48 +02:00
|
|
|
uint_t);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_initialize(const char *, pool_initialize_func_t,
|
2019-03-29 17:13:20 +01:00
|
|
|
nvlist_t *, nvlist_t **);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_trim(const char *, pool_trim_func_t, uint64_t, boolean_t,
|
|
|
|
|
nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_redact(const char *, const char *, nvlist_t *);
|
2013-08-28 13:45:09 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_snaprange_space(const char *, const char *, uint64_t *);
|
2013-08-28 13:45:09 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_hold(nvlist_t *, int, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_release(nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_get_holds(const char *, nvlist_t **);
|
2013-09-04 14:00:57 +02:00
|
|
|
|
2014-06-05 23:19:08 +02:00
|
|
|
enum lzc_send_flags {
|
2014-11-03 21:15:08 +01:00
|
|
|
LZC_SEND_FLAG_EMBED_DATA = 1 << 0,
|
2016-07-11 19:45:52 +02:00
|
|
|
LZC_SEND_FLAG_LARGE_BLOCK = 1 << 1,
|
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 19:36:48 +02:00
|
|
|
LZC_SEND_FLAG_COMPRESS = 1 << 2,
|
|
|
|
|
LZC_SEND_FLAG_RAW = 1 << 3,
|
2020-01-10 19:16:58 +01:00
|
|
|
LZC_SEND_FLAG_SAVED = 1 << 4,
|
2014-06-05 23:19:08 +02:00
|
|
|
};
|
|
|
|
|
|
2022-02-21 02:31:32 +01:00
|
|
|
_LIBZFS_CORE_H int lzc_send_wrapper(int (*)(int, void *), int, void *);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_send(const char *, const char *, int,
|
|
|
|
|
enum lzc_send_flags);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_send_resume(const char *, const char *, int,
|
2016-01-06 22:22:48 +01:00
|
|
|
enum lzc_send_flags, uint64_t, uint64_t);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_send_space(const char *, const char *,
|
|
|
|
|
enum lzc_send_flags, uint64_t *);
|
2016-06-16 19:01:33 +02:00
|
|
|
|
|
|
|
|
struct dmu_replay_record;
|
|
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_send_redacted(const char *, const char *, int,
|
|
|
|
|
enum lzc_send_flags, const char *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_send_resume_redacted(const char *, const char *, int,
|
Implement Redacted Send/Receive
Redacted send/receive allows users to send subsets of their data to
a target system. One possible use case for this feature is to not
transmit sensitive information to a data warehousing, test/dev, or
analytics environment. Another is to save space by not replicating
unimportant data within a given dataset, for example in backup tools
like zrepl.
Redacted send/receive is a three-stage process. First, a clone (or
clones) is made of the snapshot to be sent to the target. In this
clone (or clones), all unnecessary or unwanted data is removed or
modified. This clone is then snapshotted to create the "redaction
snapshot" (or snapshots). Second, the new zfs redact command is used
to create a redaction bookmark. The redaction bookmark stores the
list of blocks in a snapshot that were modified by the redaction
snapshot(s). Finally, the redaction bookmark is passed as a parameter
to zfs send. When sending to the snapshot that was redacted, the
redaction bookmark is used to filter out blocks that contain sensitive
or unwanted information, and those blocks are not included in the send
stream. When sending from the redaction bookmark, the blocks it
contains are considered as candidate blocks in addition to those
blocks in the destination snapshot that were modified since the
creation_txg of the redaction bookmark. This step is necessary to
allow the target to rehydrate data in the case where some blocks are
accidentally or unnecessarily modified in the redaction snapshot.
The changes to bookmarks to enable fast space estimation involve
adding deadlists to bookmarks. There is also logic to manage the
life cycles of these deadlists.
The new size estimation process operates in cases where previously
an accurate estimate could not be provided. In those cases, a send
is performed where no data blocks are read, reducing the runtime
significantly and providing a byte-accurate size estimate.
Reviewed-by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed-by: Matt Ahrens <mahrens@delphix.com>
Reviewed-by: Prashanth Sreenivasa <pks@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: Chris Williamson <chris.williamson@delphix.com>
Reviewed-by: Pavel Zhakarov <pavel.zakharov@delphix.com>
Reviewed-by: Sebastien Roy <sebastien.roy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes #7958
2019-06-19 18:48:13 +02:00
|
|
|
enum lzc_send_flags, uint64_t, uint64_t, const char *);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_receive(const char *, nvlist_t *, const char *,
|
|
|
|
|
boolean_t, boolean_t, int);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_receive_resumable(const char *, nvlist_t *, const char *,
|
|
|
|
|
boolean_t, boolean_t, int);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_receive_with_header(const char *, nvlist_t *,
|
|
|
|
|
const char *, boolean_t, boolean_t, boolean_t, int,
|
|
|
|
|
const struct dmu_replay_record *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_receive_one(const char *, nvlist_t *, const char *,
|
|
|
|
|
boolean_t, boolean_t, boolean_t, int, const struct dmu_replay_record *, int,
|
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 19:36:48 +02:00
|
|
|
uint64_t *, uint64_t *, uint64_t *, nvlist_t **);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_receive_with_cmdprops(const char *, nvlist_t *,
|
|
|
|
|
nvlist_t *, uint8_t *, uint_t, const char *, boolean_t, boolean_t,
|
|
|
|
|
boolean_t, int, const struct dmu_replay_record *, int, uint64_t *,
|
|
|
|
|
uint64_t *, uint64_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_send_space(const char *, const char *,
|
|
|
|
|
enum lzc_send_flags, uint64_t *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_send_space_resume_redacted(const char *, const char *,
|
Implement Redacted Send/Receive
Redacted send/receive allows users to send subsets of their data to
a target system. One possible use case for this feature is to not
transmit sensitive information to a data warehousing, test/dev, or
analytics environment. Another is to save space by not replicating
unimportant data within a given dataset, for example in backup tools
like zrepl.
Redacted send/receive is a three-stage process. First, a clone (or
clones) is made of the snapshot to be sent to the target. In this
clone (or clones), all unnecessary or unwanted data is removed or
modified. This clone is then snapshotted to create the "redaction
snapshot" (or snapshots). Second, the new zfs redact command is used
to create a redaction bookmark. The redaction bookmark stores the
list of blocks in a snapshot that were modified by the redaction
snapshot(s). Finally, the redaction bookmark is passed as a parameter
to zfs send. When sending to the snapshot that was redacted, the
redaction bookmark is used to filter out blocks that contain sensitive
or unwanted information, and those blocks are not included in the send
stream. When sending from the redaction bookmark, the blocks it
contains are considered as candidate blocks in addition to those
blocks in the destination snapshot that were modified since the
creation_txg of the redaction bookmark. This step is necessary to
allow the target to rehydrate data in the case where some blocks are
accidentally or unnecessarily modified in the redaction snapshot.
The changes to bookmarks to enable fast space estimation involve
adding deadlists to bookmarks. There is also logic to manage the
life cycles of these deadlists.
The new size estimation process operates in cases where previously
an accurate estimate could not be provided. In those cases, a send
is performed where no data blocks are read, reducing the runtime
significantly and providing a byte-accurate size estimate.
Reviewed-by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed-by: Matt Ahrens <mahrens@delphix.com>
Reviewed-by: Prashanth Sreenivasa <pks@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: Chris Williamson <chris.williamson@delphix.com>
Reviewed-by: Pavel Zhakarov <pavel.zakharov@delphix.com>
Reviewed-by: Sebastien Roy <sebastien.roy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes #7958
2019-06-19 18:48:13 +02:00
|
|
|
enum lzc_send_flags, uint64_t, uint64_t, uint64_t, const char *,
|
|
|
|
|
int, uint64_t *);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H uint64_t lzc_send_progress(int);
|
2013-08-28 13:45:09 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H boolean_t lzc_exists(const char *);
|
2013-08-28 13:45:09 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_rollback(const char *, char *, int);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_rollback_to(const char *, const char *);
|
2013-08-28 13:45:09 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_rename(const char *, const char *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_destroy(const char *);
|
2018-06-27 23:37:54 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_channel_program(const char *, const char *, uint64_t,
|
2018-02-08 17:35:09 +01:00
|
|
|
uint64_t, nvlist_t *, nvlist_t **);
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_channel_program_nosync(const char *, const char *,
|
|
|
|
|
uint64_t, uint64_t, nvlist_t *, nvlist_t **);
|
2018-02-08 17:16:23 +01:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_sync(const char *, nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_reopen(const char *, boolean_t);
|
2017-05-19 21:33:11 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_pool_checkpoint(const char *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_pool_checkpoint_discard(const char *);
|
2016-12-16 23:11:29 +01:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_wait(const char *, zpool_wait_activity_t, boolean_t *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_wait_tag(const char *, zpool_wait_activity_t, uint64_t,
|
|
|
|
|
boolean_t *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_wait_fs(const char *, zfs_wait_activity_t, boolean_t *);
|
Add subcommand to wait for background zfs activity to complete
Currently the best way to wait for the completion of a long-running
operation in a pool, like a scrub or device removal, is to poll 'zpool
status' and parse its output, which is neither efficient nor convenient.
This change adds a 'wait' subcommand to the zpool command. When invoked,
'zpool wait' will block until a specified type of background activity
completes. Currently, this subcommand can wait for any of the following:
- Scrubs or resilvers to complete
- Devices to initialized
- Devices to be replaced
- Devices to be removed
- Checkpoints to be discarded
- Background freeing to complete
For example, a scrub that is in progress could be waited for by running
zpool wait -t scrub <pool>
This also adds a -w flag to the attach, checkpoint, initialize, replace,
remove, and scrub subcommands. When used, this flag makes the operations
kicked off by these subcommands synchronous instead of asynchronous.
This functionality is implemented using a new ioctl. The type of
activity to wait for is provided as input to the ioctl, and the ioctl
blocks until all activity of that type has completed. An ioctl was used
over other methods of kernel-userspace communiction primarily for the
sake of portability.
Porting Notes:
This is ported from Delphix OS change DLPX-44432. The following changes
were made while porting:
- Added ZoL-style ioctl input declaration.
- Reorganized error handling in zpool_initialize in libzfs to integrate
better with changes made for TRIM support.
- Fixed check for whether a checkpoint discard is in progress.
Previously it also waited if the pool had a checkpoint, instead of
just if a checkpoint was being discarded.
- Exposed zfs_initialize_chunk_size as a ZoL-style tunable.
- Updated more existing tests to make use of new 'zpool wait'
functionality, tests that don't exist in Delphix OS.
- Used existing ZoL tunable zfs_scan_suspend_progress, together with
zinject, in place of a new tunable zfs_scan_max_blks_per_txg.
- Added support for a non-integral interval argument to zpool wait.
Future work:
ZoL has support for trimming devices, which Delphix OS does not. In the
future, 'zpool wait' could be extended to add the ability to wait for
trim operations to complete.
Reviewed-by: Matt Ahrens <matt@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: John Gallagher <john.gallagher@delphix.com>
Closes #9162
2019-09-14 03:09:06 +02:00
|
|
|
|
2021-06-03 23:50:07 +02:00
|
|
|
_LIBZFS_CORE_H int lzc_set_bootenv(const char *, const nvlist_t *);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_get_bootenv(const char *, nvlist_t **);
|
2021-11-30 15:46:25 +01:00
|
|
|
|
|
|
|
|
_LIBZFS_CORE_H int lzc_get_vdev_prop(const char *, nvlist_t *, nvlist_t **);
|
|
|
|
|
_LIBZFS_CORE_H int lzc_set_vdev_prop(const char *, nvlist_t *, nvlist_t **);
|
|
|
|
|
|
2013-08-28 13:45:09 +02:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#endif /* _LIBZFS_CORE_H */
|