Adopt pyzfs from ClusterHQ
This commit introduces several changes:
* Update LICENSE and project information
* Give a good PEP8 talk to existing Python source code
* Add RPM/DEB packaging for pyzfs
* Fix some outstanding issues with the existing pyzfs code caused by
changes in the ABI since the last time the code was updated
* Integrate pyzfs Python unittest with the ZFS Test Suite
* Add missing libzfs_core functions: lzc_change_key,
lzc_channel_program, lzc_channel_program_nosync, lzc_load_key,
lzc_receive_one, lzc_receive_resumable, lzc_receive_with_cmdprops,
lzc_receive_with_header, lzc_reopen, lzc_send_resume, lzc_sync,
lzc_unload_key, lzc_remap
Note: this commit slightly changes zfs_ioc_unload_key() ABI. This allow
to differentiate the case where we tried to unload a key on a
non-existing dataset (ENOENT) from the situation where a dataset has
no key loaded: this is consistent with the "change" case where trying
to zfs_ioc_change_key() from a dataset with no key results in EACCES.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #7230
2018-03-18 08:34:45 +00:00
|
|
|
#
|
|
|
|
# Copyright 2015 ClusterHQ
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
#
|
2018-03-03 10:10:34 +00:00
|
|
|
|
|
|
|
"""
|
|
|
|
Important `libzfs_core` constants.
|
|
|
|
"""
|
|
|
|
|
2018-08-22 10:59:51 +00:00
|
|
|
from __future__ import absolute_import, division, print_function
|
2020-02-28 01:14:21 +00:00
|
|
|
import errno
|
|
|
|
import sys
|
|
|
|
|
|
|
|
|
|
|
|
# Compat for platform-specific errnos
|
|
|
|
if sys.platform.startswith('freebsd'):
|
|
|
|
ECHRNG = errno.ENXIO
|
|
|
|
ECKSUM = 97 # EINTEGRITY
|
|
|
|
ETIME = errno.ETIMEDOUT
|
|
|
|
else:
|
|
|
|
ECHRNG = errno.ECHRNG
|
|
|
|
ECKSUM = errno.EBADE
|
|
|
|
ETIME = errno.ETIME
|
2018-08-22 10:59:51 +00:00
|
|
|
|
Adopt pyzfs from ClusterHQ
This commit introduces several changes:
* Update LICENSE and project information
* Give a good PEP8 talk to existing Python source code
* Add RPM/DEB packaging for pyzfs
* Fix some outstanding issues with the existing pyzfs code caused by
changes in the ABI since the last time the code was updated
* Integrate pyzfs Python unittest with the ZFS Test Suite
* Add missing libzfs_core functions: lzc_change_key,
lzc_channel_program, lzc_channel_program_nosync, lzc_load_key,
lzc_receive_one, lzc_receive_resumable, lzc_receive_with_cmdprops,
lzc_receive_with_header, lzc_reopen, lzc_send_resume, lzc_sync,
lzc_unload_key, lzc_remap
Note: this commit slightly changes zfs_ioc_unload_key() ABI. This allow
to differentiate the case where we tried to unload a key on a
non-existing dataset (ENOENT) from the situation where a dataset has
no key loaded: this is consistent with the "change" case where trying
to zfs_ioc_change_key() from a dataset with no key results in EACCES.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #7230
2018-03-18 08:34:45 +00:00
|
|
|
|
|
|
|
# https://stackoverflow.com/a/1695250
|
2019-11-11 07:24:14 +00:00
|
|
|
def enum_with_offset(offset, sequential, named):
|
|
|
|
enums = dict(((b, a + offset) for a, b in enumerate(sequential)), **named)
|
Adopt pyzfs from ClusterHQ
This commit introduces several changes:
* Update LICENSE and project information
* Give a good PEP8 talk to existing Python source code
* Add RPM/DEB packaging for pyzfs
* Fix some outstanding issues with the existing pyzfs code caused by
changes in the ABI since the last time the code was updated
* Integrate pyzfs Python unittest with the ZFS Test Suite
* Add missing libzfs_core functions: lzc_change_key,
lzc_channel_program, lzc_channel_program_nosync, lzc_load_key,
lzc_receive_one, lzc_receive_resumable, lzc_receive_with_cmdprops,
lzc_receive_with_header, lzc_reopen, lzc_send_resume, lzc_sync,
lzc_unload_key, lzc_remap
Note: this commit slightly changes zfs_ioc_unload_key() ABI. This allow
to differentiate the case where we tried to unload a key on a
non-existing dataset (ENOENT) from the situation where a dataset has
no key loaded: this is consistent with the "change" case where trying
to zfs_ioc_change_key() from a dataset with no key results in EACCES.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #7230
2018-03-18 08:34:45 +00:00
|
|
|
return type('Enum', (), enums)
|
|
|
|
|
|
|
|
|
2019-11-11 07:24:14 +00:00
|
|
|
def enum(*sequential, **named):
|
|
|
|
return enum_with_offset(0, sequential, named)
|
|
|
|
|
|
|
|
|
2018-03-03 10:10:34 +00:00
|
|
|
#: Maximum length of any ZFS name.
|
|
|
|
MAXNAMELEN = 255
|
Adopt pyzfs from ClusterHQ
This commit introduces several changes:
* Update LICENSE and project information
* Give a good PEP8 talk to existing Python source code
* Add RPM/DEB packaging for pyzfs
* Fix some outstanding issues with the existing pyzfs code caused by
changes in the ABI since the last time the code was updated
* Integrate pyzfs Python unittest with the ZFS Test Suite
* Add missing libzfs_core functions: lzc_change_key,
lzc_channel_program, lzc_channel_program_nosync, lzc_load_key,
lzc_receive_one, lzc_receive_resumable, lzc_receive_with_cmdprops,
lzc_receive_with_header, lzc_reopen, lzc_send_resume, lzc_sync,
lzc_unload_key, lzc_remap
Note: this commit slightly changes zfs_ioc_unload_key() ABI. This allow
to differentiate the case where we tried to unload a key on a
non-existing dataset (ENOENT) from the situation where a dataset has
no key loaded: this is consistent with the "change" case where trying
to zfs_ioc_change_key() from a dataset with no key results in EACCES.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: loli10K <ezomori.nozomu@gmail.com>
Closes #7230
2018-03-18 08:34:45 +00:00
|
|
|
#: Default channel program limits
|
|
|
|
ZCP_DEFAULT_INSTRLIMIT = 10 * 1000 * 1000
|
|
|
|
ZCP_DEFAULT_MEMLIMIT = 10 * 1024 * 1024
|
|
|
|
#: Encryption wrapping key length
|
|
|
|
WRAPPING_KEY_LEN = 32
|
|
|
|
#: Encryption key location enum
|
|
|
|
zfs_key_location = enum(
|
|
|
|
'ZFS_KEYLOCATION_NONE',
|
|
|
|
'ZFS_KEYLOCATION_PROMPT',
|
|
|
|
'ZFS_KEYLOCATION_URI'
|
|
|
|
)
|
|
|
|
#: Encryption key format enum
|
|
|
|
zfs_keyformat = enum(
|
|
|
|
'ZFS_KEYFORMAT_NONE',
|
|
|
|
'ZFS_KEYFORMAT_RAW',
|
|
|
|
'ZFS_KEYFORMAT_HEX',
|
|
|
|
'ZFS_KEYFORMAT_PASSPHRASE'
|
|
|
|
)
|
|
|
|
# Encryption algorithms enum
|
|
|
|
zio_encrypt = enum(
|
|
|
|
'ZIO_CRYPT_INHERIT',
|
|
|
|
'ZIO_CRYPT_ON',
|
|
|
|
'ZIO_CRYPT_OFF',
|
|
|
|
'ZIO_CRYPT_AES_128_CCM',
|
|
|
|
'ZIO_CRYPT_AES_192_CCM',
|
|
|
|
'ZIO_CRYPT_AES_256_CCM',
|
|
|
|
'ZIO_CRYPT_AES_128_GCM',
|
|
|
|
'ZIO_CRYPT_AES_192_GCM',
|
|
|
|
'ZIO_CRYPT_AES_256_GCM'
|
|
|
|
)
|
2018-08-20 17:11:52 +00:00
|
|
|
# ZFS-specific error codes
|
2019-11-11 07:24:14 +00:00
|
|
|
zfs_errno = enum_with_offset(1024, [
|
|
|
|
'ZFS_ERR_CHECKPOINT_EXISTS',
|
|
|
|
'ZFS_ERR_DISCARDING_CHECKPOINT',
|
|
|
|
'ZFS_ERR_NO_CHECKPOINT',
|
|
|
|
'ZFS_ERR_DEVRM_IN_PROGRESS',
|
|
|
|
'ZFS_ERR_VDEV_TOO_BIG',
|
|
|
|
'ZFS_ERR_IOC_CMD_UNAVAIL',
|
|
|
|
'ZFS_ERR_IOC_ARG_UNAVAIL',
|
|
|
|
'ZFS_ERR_IOC_ARG_REQUIRED',
|
|
|
|
'ZFS_ERR_IOC_ARG_BADTYPE',
|
|
|
|
'ZFS_ERR_WRONG_PARENT',
|
|
|
|
'ZFS_ERR_FROM_IVSET_GUID_MISSING',
|
|
|
|
'ZFS_ERR_FROM_IVSET_GUID_MISMATCH',
|
|
|
|
'ZFS_ERR_SPILL_BLOCK_FLAG_MISSING',
|
|
|
|
'ZFS_ERR_UNKNOWN_SEND_STREAM_FEATURE',
|
|
|
|
'ZFS_ERR_EXPORT_IN_PROGRESS',
|
|
|
|
'ZFS_ERR_BOOKMARK_SOURCE_NOT_ANCESTOR',
|
2020-03-17 17:30:33 +00:00
|
|
|
'ZFS_ERR_STREAM_TRUNCATED',
|
2020-07-31 16:01:41 +00:00
|
|
|
'ZFS_ERR_STREAM_LARGE_BLOCK_MISMATCH',
|
2020-07-03 18:05:50 +00:00
|
|
|
'ZFS_ERR_RESILVER_IN_PROGRESS',
|
|
|
|
'ZFS_ERR_REBUILD_IN_PROGRESS',
|
2020-08-01 15:41:31 +00:00
|
|
|
'ZFS_ERR_BADPROP',
|
2021-11-30 14:46:25 +00:00
|
|
|
'ZFS_ERR_VDEV_NOTSUP',
|
2021-02-21 16:19:43 +00:00
|
|
|
'ZFS_ERR_NOT_USER_NAMESPACE',
|
2022-09-27 23:34:27 +00:00
|
|
|
'ZFS_ERR_RESUME_EXISTS',
|
Better handling for future crypto parameters
The intent is that this is like ENOTSUP, but specifically for when
something can't be done because we have no support for the requested
crypto parameters; eg unlocking a dataset or receiving a stream
encrypted with a suite we don't support.
Its not intended to be recoverable without upgrading ZFS itself.
If the request could be made to work by enabling a feature or modifying
some other configuration item, then some other code should be used.
load-key: In the future we might have more crypto suites (ie new values
for the `encryption` property. Right now trying to load a key on such
a future crypto suite will look up suite parameters off the end of the
crypto table, resulting in misbehaviour and/or crashes (or, with debug
enabled, trip the assertion in `zio_crypt_key_unwrap`).
Instead, lets check the value we got from the dataset, and if we can't
handle it, abort early.
recv: When receiving a raw stream encrypted with an unknown crypto
suite, `zfs recv` would report a generic `invalid backup stream`
(EINVAL). While technically correct, its not super helpful, so lets
ship a more specific error code and message.
Reviewed-by: Tino Reichardt <milky-zfs@mcmilk.de>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes #14577
2023-03-07 22:05:14 +00:00
|
|
|
'ZFS_ERR_CRYPTO_NOTSUP',
|
RAID-Z expansion feature
This feature allows disks to be added one at a time to a RAID-Z group,
expanding its capacity incrementally. This feature is especially useful
for small pools (typically with only one RAID-Z group), where there
isn't sufficient hardware to add capacity by adding a whole new RAID-Z
group (typically doubling the number of disks).
== Initiating expansion ==
A new device (disk) can be attached to an existing RAIDZ vdev, by
running `zpool attach POOL raidzP-N NEW_DEVICE`, e.g. `zpool attach tank
raidz2-0 sda`. The new device will become part of the RAIDZ group. A
"raidz expansion" will be initiated, and the new device will contribute
additional space to the RAIDZ group once the expansion completes.
The `feature@raidz_expansion` on-disk feature flag must be `enabled` to
initiate an expansion, and it remains `active` for the life of the pool.
In other words, pools with expanded RAIDZ vdevs can not be imported by
older releases of the ZFS software.
== During expansion ==
The expansion entails reading all allocated space from existing disks in
the RAIDZ group, and rewriting it to the new disks in the RAIDZ group
(including the newly added device).
The expansion progress can be monitored with `zpool status`.
Data redundancy is maintained during (and after) the expansion. If a
disk fails while the expansion is in progress, the expansion pauses
until the health of the RAIDZ vdev is restored (e.g. by replacing the
failed disk and waiting for reconstruction to complete).
The pool remains accessible during expansion. Following a reboot or
export/import, the expansion resumes where it left off.
== After expansion ==
When the expansion completes, the additional space is available for use,
and is reflected in the `available` zfs property (as seen in `zfs list`,
`df`, etc).
Expansion does not change the number of failures that can be tolerated
without data loss (e.g. a RAIDZ2 is still a RAIDZ2 even after
expansion).
A RAIDZ vdev can be expanded multiple times.
After the expansion completes, old blocks remain with their old
data-to-parity ratio (e.g. 5-wide RAIDZ2, has 3 data to 2 parity), but
distributed among the larger set of disks. New blocks will be written
with the new data-to-parity ratio (e.g. a 5-wide RAIDZ2 which has been
expanded once to 6-wide, has 4 data to 2 parity). However, the RAIDZ
vdev's "assumed parity ratio" does not change, so slightly less space
than is expected may be reported for newly-written blocks, according to
`zfs list`, `df`, `ls -s`, and similar tools.
Sponsored-by: The FreeBSD Foundation
Sponsored-by: iXsystems, Inc.
Sponsored-by: vStack
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Authored-by: Matthew Ahrens <mahrens@delphix.com>
Contributions-by: Fedor Uporov <fuporov.vstack@gmail.com>
Contributions-by: Stuart Maybee <stuart.maybee@comcast.net>
Contributions-by: Thorsten Behrens <tbehrens@outlook.com>
Contributions-by: Fmstrat <nospam@nowsci.com>
Contributions-by: Don Brady <dev.fs.zfs@gmail.com>
Signed-off-by: Don Brady <dev.fs.zfs@gmail.com>
Closes #15022
2023-11-08 18:19:41 +00:00
|
|
|
'ZFS_ERR_RAIDZ_EXPAND_IN_PROGRESS',
|
2019-11-11 07:24:14 +00:00
|
|
|
],
|
|
|
|
{}
|
|
|
|
)
|
|
|
|
# compat before we used the enum helper for these values
|
|
|
|
ZFS_ERR_CHECKPOINT_EXISTS = zfs_errno.ZFS_ERR_CHECKPOINT_EXISTS
|
2022-08-01 16:49:35 +00:00
|
|
|
assert (ZFS_ERR_CHECKPOINT_EXISTS == 1024)
|
2019-11-11 07:24:14 +00:00
|
|
|
ZFS_ERR_DISCARDING_CHECKPOINT = zfs_errno.ZFS_ERR_DISCARDING_CHECKPOINT
|
|
|
|
ZFS_ERR_NO_CHECKPOINT = zfs_errno.ZFS_ERR_NO_CHECKPOINT
|
|
|
|
ZFS_ERR_DEVRM_IN_PROGRESS = zfs_errno.ZFS_ERR_DEVRM_IN_PROGRESS
|
|
|
|
ZFS_ERR_VDEV_TOO_BIG = zfs_errno.ZFS_ERR_VDEV_TOO_BIG
|
|
|
|
ZFS_ERR_WRONG_PARENT = zfs_errno.ZFS_ERR_WRONG_PARENT
|
2021-11-30 14:46:25 +00:00
|
|
|
ZFS_ERR_VDEV_NOTSUP = zfs_errno.ZFS_ERR_VDEV_NOTSUP
|
RAID-Z expansion feature
This feature allows disks to be added one at a time to a RAID-Z group,
expanding its capacity incrementally. This feature is especially useful
for small pools (typically with only one RAID-Z group), where there
isn't sufficient hardware to add capacity by adding a whole new RAID-Z
group (typically doubling the number of disks).
== Initiating expansion ==
A new device (disk) can be attached to an existing RAIDZ vdev, by
running `zpool attach POOL raidzP-N NEW_DEVICE`, e.g. `zpool attach tank
raidz2-0 sda`. The new device will become part of the RAIDZ group. A
"raidz expansion" will be initiated, and the new device will contribute
additional space to the RAIDZ group once the expansion completes.
The `feature@raidz_expansion` on-disk feature flag must be `enabled` to
initiate an expansion, and it remains `active` for the life of the pool.
In other words, pools with expanded RAIDZ vdevs can not be imported by
older releases of the ZFS software.
== During expansion ==
The expansion entails reading all allocated space from existing disks in
the RAIDZ group, and rewriting it to the new disks in the RAIDZ group
(including the newly added device).
The expansion progress can be monitored with `zpool status`.
Data redundancy is maintained during (and after) the expansion. If a
disk fails while the expansion is in progress, the expansion pauses
until the health of the RAIDZ vdev is restored (e.g. by replacing the
failed disk and waiting for reconstruction to complete).
The pool remains accessible during expansion. Following a reboot or
export/import, the expansion resumes where it left off.
== After expansion ==
When the expansion completes, the additional space is available for use,
and is reflected in the `available` zfs property (as seen in `zfs list`,
`df`, etc).
Expansion does not change the number of failures that can be tolerated
without data loss (e.g. a RAIDZ2 is still a RAIDZ2 even after
expansion).
A RAIDZ vdev can be expanded multiple times.
After the expansion completes, old blocks remain with their old
data-to-parity ratio (e.g. 5-wide RAIDZ2, has 3 data to 2 parity), but
distributed among the larger set of disks. New blocks will be written
with the new data-to-parity ratio (e.g. a 5-wide RAIDZ2 which has been
expanded once to 6-wide, has 4 data to 2 parity). However, the RAIDZ
vdev's "assumed parity ratio" does not change, so slightly less space
than is expected may be reported for newly-written blocks, according to
`zfs list`, `df`, `ls -s`, and similar tools.
Sponsored-by: The FreeBSD Foundation
Sponsored-by: iXsystems, Inc.
Sponsored-by: vStack
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Mark Maybee <mark.maybee@delphix.com>
Authored-by: Matthew Ahrens <mahrens@delphix.com>
Contributions-by: Fedor Uporov <fuporov.vstack@gmail.com>
Contributions-by: Stuart Maybee <stuart.maybee@comcast.net>
Contributions-by: Thorsten Behrens <tbehrens@outlook.com>
Contributions-by: Fmstrat <nospam@nowsci.com>
Contributions-by: Don Brady <dev.fs.zfs@gmail.com>
Signed-off-by: Don Brady <dev.fs.zfs@gmail.com>
Closes #15022
2023-11-08 18:19:41 +00:00
|
|
|
ZFS_ERR_RAIDZ_EXPAND_IN_PROGRESS = zfs_errno.ZFS_ERR_RAIDZ_EXPAND_IN_PROGRESS
|
2018-08-20 17:11:52 +00:00
|
|
|
|
2018-03-03 10:10:34 +00:00
|
|
|
# vim: softtabstop=4 tabstop=4 expandtab shiftwidth=4
|