注意

本文档适用于 Ceph 开发版本。

BlueStore Configuration Reference

设备

BlueStore 管理 一个、两个 或在某些情况下三个存储设备。devices是 Linux/Unix 意义下的“设备”。这意味着它们是列在/dev或/devices下的资产。

在最简单的情况下，BlueStore 消耗单个存储设备的全部。这个设备被称为主设备。主设备由block数据目录中的符号链接标识。

数据目录是一个tmpfs挂载点。当这个数据目录被启动或ceph-volume激活时，它会被填充包含有关 OSD 信息元数据文件和链接：例如，OSD 的标识符、OSD 所属集群的名称以及 OSD 的私钥环。

在更复杂的情况下，BlueStore 部署在 一个或两个 额外的设备上：

  • A 预写日志 (WAL) 设备(在数据目录中标识为block.wal) 可以用来将 BlueStore 的内部日志或预写日志分离出来。只有当 WAL 设备比主设备更快时（例如，如果 WAL 设备是 SSD 而主设备是 HDD），使用 WAL 设备才是有利的。

  • A DB 设备(在数据目录中标识为block.db) 可以用来存储 BlueStore 的内部元数据。BlueStore（或更精确地说，嵌入的 RocksDB）将尽可能多的元数据放在 DB 设备上以提高性能。如果 DB 设备已满，元数据将回退到主设备（在没有 DB 设备的情况下，元数据原本位于主设备上）。同样，只有当 DB 设备比主设备更快时，配置 DB 设备才是有利的。

如果只有少量快速存储可用（例如，少于 1GB），我们建议将可用空间用作 WAL 设备。但如果有多余的快速存储可用，配置 DB 设备更有意义。因为 BlueStore 日志始终放在可用的最快设备上，使用 DB 设备提供了与使用 WAL 设备相同的好处，同时允许额外的元数据存储在主设备之外（前提是它适合）。 allowing additional metadata to be stored off the primary device (provided that it fits). DB devices make this possible because whenever a DB device is specified but an explicit WAL device is not, the WAL will be implicitly colocated with the DB on the faster device.

要配置单个设备（共位于）BlueStore OSD，运行以下命令：

ceph-volume lvm prepare --bluestore --data <device>

要指定 WAL 设备或 DB 设备，运行以下命令：

ceph-volume lvm prepare --bluestore --data <device> --block.wal <wal-device> --block.db <db-device>

Note

选项--data可以接受以下设备作为其参数：使用vg/lv语法指定的逻辑卷、现有的逻辑卷和 GPT 分区。

配置策略

BlueStore 与 Filestore 不同，因为它有几种部署 BlueStore OSD 的方法。然而，通过检查这两种常见配置，可以阐明 BlueStore 的整体部署策略：

仅块（数据）

如果所有设备都是同一类型（例如，它们都是 HDD），并且没有可用于存储元数据的快速设备，那么指定仅块设备并让block.db和block.wal未分离是有意义的。对于单个lvm command for a single /dev/sda设备的命令如下：

ceph-volume lvm create --bluestore --data /dev/sda

如果用于 BlueStore OSD 的设备是预先创建的逻辑卷，那么对名为lvm调用如下：ceph-vg/block-lv的逻辑卷的

ceph-volume lvm create --bluestore --data ceph-vg/block-lv

块和块.db

如果你有一组快速和慢速设备的混合（例如，SSD 或 HDD），我们建议将block.db放在较快的设备上，而block（即数据）存储在较慢的设备上（即旋转驱动器）。

你必须手动创建这些卷组和这些逻辑卷。因为 Theceph-volume工具目前无法自动完成[创建它们？]。

以下步骤说明了手动创建卷组和逻辑卷的过程。对于此示例，我们假设有四个旋转驱动器sda, sdb, sdc, and sdd）和一个（快速）SSDsdx。首先，要创建卷组，运行以下命令：

vgcreate ceph-block-0 /dev/sda
vgcreate ceph-block-1 /dev/sdb
vgcreate ceph-block-2 /dev/sdc
vgcreate ceph-block-3 /dev/sdd

接下来，要为block，请运行以下命令：

lvcreate -l 100%FREE -n block-0 ceph-block-0
lvcreate -l 100%FREE -n block-1 ceph-block-1
lvcreate -l 100%FREE -n block-2 ceph-block-2
lvcreate -l 100%FREE -n block-3 ceph-block-3

创建逻辑卷/dev/sdx中有一个 200GB SSD，我们可以通过运行以下命令创建四个 50GB 逻辑卷：

vgcreate ceph-db-0 /dev/sdx
lvcreate -L 50GB -n db-0 ceph-db-0
lvcreate -L 50GB -n db-1 ceph-db-0
lvcreate -L 50GB -n db-2 ceph-db-0
lvcreate -L 50GB -n db-3 ceph-db-0

最后，要创建四个 OSD，运行以下命令：

ceph-volume lvm create --bluestore --data ceph-block-0/block-0 --block.db ceph-db-0/db-0
ceph-volume lvm create --bluestore --data ceph-block-1/block-1 --block.db ceph-db-0/db-1
ceph-volume lvm create --bluestore --data ceph-block-2/block-2 --block.db ceph-db-0/db-2
ceph-volume lvm create --bluestore --data ceph-block-3/block-3 --block.db ceph-db-0/db-3

完成此步骤后，应该有四个 OSD，block应该在四个 HDD 上，并且每个 HDD 上都应该有一个 50GB 逻辑卷

尺寸

当使用一个混合旋转和固态驱动器设置时，重要的是要为 BlueStore 创建一个足够大的block.db逻辑卷。与block.db关联的逻辑卷应该尽可能大as large as possible.

它是block.db大小的一部分。对于 RGW 工作负载，建议block. For RGW workloads, it is recommended that the block.db至少是block大小的 4%。因为 RGW 大量使用block.db存储元数据（特别是 omap keys）。例如，如果block大小是 1TB，那么block.db应该至少有 40GB。对于 RBD 工作负载，但是，block.db通常不需要 1% 到 2% 的block大小。

在较旧的版本中，内部级别大小是 BlueStore 可以充分利用与 L0、L0+L1、L1+L2 等对应的特定分区/逻辑卷大小——也就是说，在默认设置下，大小约为 3GB、30GB、300GB 等。大多数部署不会从适应 L3 和更高级别的尺寸中显著受益，尽管 DB 压缩可以通过将数字加倍到 6GB、60GB 和 600GB 来促进。

Nautilus 14.2.12、Octopus 15.2.6 及后续版本中的改进允许更好地利用任意大小的 DB 设备。此外，太平洋版本带来了实验性的动态级别支持。由于这些进步，较旧版本的用户可能希望今天通过配置较大的 DB 设备来提前计划，以便在将来升级时实现规模效益。

当firefly 发布。Firefly 将延迟至少另一个冲刺，以便我们可以对新代码进行一些操作经验，并进行一些额外的测试，然后再承诺长期支持。使用一组快速和慢速设备，没有必要为block.db或block.wal创建单独的逻辑卷。BlueStore 将自动在这些设备的空间内共位于这些设备。block.

自动缓存大小调整

BlueStore 可以配置为自动调整其缓存，前提是满足某些条件：必须将 TCMalloc 配置为内存分配器，并且必须启用bluestore_cache_autotune配置选项（注意：它目前默认启用）。当自动缓存大小调整生效时，BlueStore 尝试将 OSD 堆内存使用量保持在某个目标大小（由osd_memory_target确定）。这种方法使用了一种尽力而为的算法，并且缓存不会缩小到osd_memory_cache_min的值定义的大小以下。缓存比率是根据优先级层次结构选择的。但如果优先级信息不可用，则bluestore_cache_meta_ratio和bluestore_cache_kv_ratio选项中指定的值将用作回退缓存比率。

bluestore_cache_autotune

自动调整分配给各种 BlueStore 缓存的存储空间比率，同时尊重最小值。

type:

bool

default:

true

参见:

bluestore_cache_size, bluestore_cache_meta_ratio

osd_memory_target

当 TCMalloc 可用时并且缓存自动调整已启用时，尝试保持内存中映射的这些字节数。注意：这可能无法完全匹配进程的 RSS 内存使用量。虽然进程映射的堆内存总量通常应该接近此目标，但没有保证内核实际上会回收已未映射的内存。在初始开发期间，发现某些内核导致 OSD 的 RSS 内存超过映射内存高达 20%。然而，人们认为，当内存压力很大时，内核通常会更积极地回收未映射的内存。你的体验可能会有所不同。

type:

size

default:

4Gi

min:

896_M

参见:

bluestore_cache_autotune, osd_memory_cache_min, osd_memory_base, osd_memory_target_autotune

bluestore_cache_autotune_interval

当缓存自动调整启用时，在重新平衡之间等待的秒数。bluestore_cache_autotune_interval设置 Ceph 重新计算各种缓存分配比率的速度。注意：设置此间隔太小会导致 CPU 使用率高和性能降低。

type:

float

default:

5.0

参见:

bluestore_cache_autotune

osd_memory_base

当 TCMalloc 和缓存自动调整启用时，估计 OSD 将需要的最小字节数内存。这用于帮助自动调整器估计缓存的预期总内存消耗。

type:

size

default:

768Mi

参见:

bluestore_cache_autotune

osd_memory_expected_fragmentation

当 TCMalloc 和缓存自动调整启用时，估计内存碎片化的百分比。这用于帮助自动调整器估计缓存的预期总内存消耗。

type:

float

default:

0.15

允许范围:

[0, 1]

参见:

bluestore_cache_autotune

osd_memory_cache_min

当 TCMalloc 和缓存自动调整启用时，设置用于缓存的内存的最小量。注意：设置此值太低会导致严重的缓存颠簸。

type:

size

default:

128Mi

min:

128_M

参见:

bluestore_cache_autotune

osd_memory_cache_resize_interval

当 TCMalloc 和缓存自动调整启用时，等待此多少秒重新调整缓存。此设置更改 BlueStore 可用于缓存的可用内存总量。注意：设置此间隔太小会导致内存分配器颠簸和性能降低。

type:

float

default:

1.0

参见:

bluestore_cache_autotune

手动缓存大小调整

每个 OSD 用于其 BlueStore 缓存的内存量由bluestore_cache_size配置选项确定。如果未指定该选项（即，如果它保持为 0），则 Ceph 使用不同的配置选项来确定默认内存预算：bluestore_cache_size_hdd如果主设备是 HDD，或bluestore_cache_size_ssd如果主设备是 SSD。

BlueStore 和 Ceph OSD 守护进程的其他部分都尽力在内存预算内工作。请注意，除了配置的缓存大小之外，OSD 本身也消耗内存。由于内存碎片和其他分配器开销，还有额外的利用率。

配置的缓存内存预算可用于存储以下类型的内容：

  • 键/值元数据（即 RocksDB 的内部缓存）

  • BlueStore 元数据

  • BlueStore 数据（即最近读取或最近写入的对象数据）

缓存内存使用受配置选项bluestore_cache_meta_ratio和bluestore_cache_kv_ratio支配。缓存中保留用于数据的部分受相关bluestore_cache_size[_ssd|_hdd]选项和主设备设备类的影响，以及“meta”和“kv”比率。此数据部分可以使用以下公式计算：<effective_cache_size> * (1 - bluestore_cache_meta_ratio - bluestore_cache_kv_ratio).

bluestore_cache_size

BlueStore 将用于其缓存的内存量。如果为零，bluestore_cache_size_hdd或bluestore_cache_size_ssd将被使用。

type:

size

default:

0B

bluestore_cache_size_hdd

当由 HDD 支撑时，BlueStore 将用于其缓存的默认内存量。

type:

size

default:

1Gi

参见:

bluestore_cache_size

bluestore_cache_size_ssd

当由 SSD 支撑时，BlueStore 将用于其缓存的默认内存量。

type:

size

default:

3Gi

参见:

bluestore_cache_size

bluestore_cache_meta_ratio

用于元数据的 BlueStore 缓存比率

type:

float

default:

0.45

参见:

bluestore_cache_size

bluestore_cache_kv_ratio

用于键/值数据库（RocksDB）的 BlueStore 缓存比率

type:

float

default:

0.45

参见:

bluestore_cache_size

校验和

BlueStore 校验所有元数据和写入磁盘的所有数据。元数据校验由 RocksDB 处理，并使用crc32c算法。相比之下，数据校验由 BlueStore 处理，可以使用crc32c, xxhash32或xxhash64。尽管如此，crc32c是默认校验和算法，它适用于大多数用途。

完整数据校验增加了 BlueStore 必须存储和管理的管理元数据量。尽可能（例如，当客户端提示数据按顺序写入和读取时），BlueStore 将校验较大的块。然而，在许多情况下，它必须为每个 4 KB 数据块存储一个校验和值（通常 4 字节）。

通过将校验和截断为 1 或 2 个字节并减少元数据开销，可以获取较小的校验和值。这种方法的缺点是增加了随机错误未被检测到的可能性：给定 32 位（4 字节）校验和，约为四亿分之一；给定 16 位（2 字节）校验和，约为 65536 分之一；给定 8 位（1 字节）校验和，约为 256 分之一。要使用较小的校验和值，请选择crc32c_16或crc32c_8作为校验和算法。

The checksum algorithm可以通过每个池的配置选项或全局配置选项指定。例如：csum_type configuration option or via the global configuration option. For example:

ceph osd pool set <pool-name> csum_type <algorithm>
bluestore_csum_type

要使用的默认校验和算法。

type:

str

default:

crc32c

valid choices:

  • none

  • crc32c

  • crc32c_16

  • crc32c_8

  • xxhash32

  • xxhash64

内联压缩

BlueStore 支持使用snappy, zlib, lz4或zstd.

BlueStore 中的数据是否压缩取决于两个因素：（1）压缩模式compression mode和（2）与写入操作相关联的任何客户端提示。

  • none: 从不压缩数据。

  • passive: 除非写入操作具有压缩 hint set.

  • aggressive: 除非写入操作具有不可压缩 hint set.

  • force: 尽可能压缩数据，无论什么情况。

有关压缩和不可压缩I/O 提示的更多信息，请参阅rados_set_alloc_hint().

注意，只有当数据块将足够减少大小（由bluestore compression required ratio设置确定）时，BlueStore 中的数据才会被压缩。无论使用哪种压缩模式，如果数据块太大，则它将被丢弃，原始（未压缩）数据将存储代替。例如，如果bluestore compression required ratio被设置为.7，则只有当压缩数据的大小不超过原始数据大小的 70% 时，才会进行数据压缩。

The compression mode, compression algorithm, compression required ratio, min blob size, and max blob size设置可以由每个池属性或全局配置选项指定。要指定池属性，运行以下命令：

ceph osd pool set <pool-name> compression_algorithm <algorithm>
ceph osd pool set <pool-name> compression_mode <mode>
ceph osd pool set <pool-name> compression_required_ratio <ratio>
ceph osd pool set <pool-name> compression_min_blob_size <size>
ceph osd pool set <pool-name> compression_max_blob_size <size>
bluestore_compression_algorithm

如果未设置每个池属性compression_algorithm，则使用的默认压缩器（如果有）。请注意，zstd是firefly 发布。Firefly 将延迟至少另一个冲刺，以便我们可以对新代码进行一些操作经验，并进行一些额外的测试，然后再承诺长期支持。由于压缩少量数据时 CPU 开销很高，因此推荐用于 BlueStore。

type:

str

default:

snappy

valid choices:

  • <空字符串>

  • snappy

  • zlib

  • zstd

  • lz4

bluestore_compression_mode

如果未设置每个池属性compression_mode，则使用压缩的默认策略。none意味着从不使用压缩。passive意味着当clients hint数据可压缩时使用压缩。aggressive意味着除非客户端提示数据不可压缩，否则使用压缩。force意味着即使在客户端提示数据不可压缩的情况下，也使用压缩。

type:

str

default:

none

valid choices:

  • none

  • passive

  • aggressive

  • force

bluestore_compression_required_ratio

压缩后数据块的大小与原始大小的比率必须至少为这个小值，才能存储压缩版本。

type:

float

default:

0.875

bluestore_compression_min_blob_size

小于此值的块永远不会被压缩。每个池属性compression_min_blob_size覆盖此设置。

type:

size

default:

0B

bluestore_compression_min_blob_size_hdd

非旋转（SSD、NVMe）媒体的bluestore compression min blob size默认值。

type:

size

default:

8Ki

参见:

bluestore_compression_min_blob_size

bluestore_compression_min_blob_size_ssd

非旋转（SSD、NVMe）媒体的bluestore compression min blob size默认值。

type:

size

default:

64Ki

参见:

bluestore_compression_min_blob_size

bluestore_compression_max_blob_size

大于此值的块在压缩之前会被分成最多bluestore_compression_max_blob_size字节的小块。compression_max_blob_size覆盖此设置。

type:

size

default:

0B

bluestore_compression_max_blob_size_hdd

非旋转（SSD、NVMe）媒体的bluestore compression max blob size默认值。

type:

size

default:

64Ki

参见:

bluestore_compression_max_blob_size

bluestore_compression_max_blob_size_ssd

非旋转（SSD、NVMe）媒体的bluestore compression max blob size默认值。

type:

size

default:

64Ki

参见:

bluestore_compression_max_blob_size

RocksDB 分片

BlueStore 维护几种类型的内部键值数据，所有这些数据都存储在 RocksDB 中。BlueStore 中的每种数据类型都分配了一个唯一的前缀。

在太平洋或以后的版本中部署的 OSD 默认使用 RocksDB 分片。但是，如果 Ceph 从以前的版本升级到太平洋或以后的版本，则在太平洋之前创建的任何 OSD 上都会禁用分片。

要启用分片并将太平洋的默认值应用于特定 OSD，停止 OSD 并运行以下命令：

ceph-bluestore-tool \
 --path <data path> \
 --sharding="m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L P" \
 reshard
bluestore_rocksdb_cf

启用 BlueStore 的 RocksDB 分片。当true, bluestore_rocksdb_cfs使用时。仅当 OSD 正在执行--mkfs.

type:

bool

default:

true

时应用。下次 OSD 运行时从磁盘检索分片。

Definition of BlueStore’s RocksDB sharding. The optimal value depends on multiple factors, and modification is inadvisable. This setting is used only when OSD is doing --mkfs. Next runs of OSD retrieve sharding from disk.

type:

str

default:

m(3) p(3,0-12) O(3,0-13)=block_cache={type=binned_lru} L=min_write_buffer_number_to_merge=32 P=min_write_buffer_number_to_merge=32

限流

bluestore_throttle_bytes

在我们限流 IO 提交之前，飞行中的最大字节数

type:

size

default:

64Mi

bluestore_throttle_deferred_bytes

在我们限流 IO 提交之前，延迟写入的最大字节数

type:

size

default:

128Mi

bluestore_throttle_cost_per_io

每次 IO 向事务成本（以字节为单位）添加的开销

type:

size

default:

0B

bluestore_throttle_cost_per_io_hdd

旋转媒体（HDD）的默认

type:

uint

default:

670000

参见:

bluestore_throttle_cost_per_io

非旋转（固态）媒体的默认

Default bluestore_throttle_cost_per_io for non-rotation (solid state) media

type:

uint

default:

4000

参见:

bluestore_throttle_cost_per_io

SPDK 使用

要使用 SPDK 驱动程序驱动 NVMe 设备，你必须首先准备你的系统。请参阅SPDK 文档.

SPDK 提供一个脚本，将自动配置设备。以 root 权限运行此脚本：

sudo src/spdk/scripts/setup.sh

你需要使用“spdk:”前缀指定主题 NVMe 设备的设备选择器用于bluestore_block_path.

在以下示例中，你首先通过运行以下命令找到 Intel NVMe SSD 的设备选择器：

lspci -mm -n -D -d 8086:0953

设备选择器的形式是DDDD:BB:DD.FF或DDDD.BB.DD.FF.

Next, 假设0000:01:00.0是lspci命令输出的设备选择器，你可以通过运行以下命令指定设备选择器：

bluestore_block_path = "spdk:trtype:PCIe traddr:0000:01:00.0"

你也可以指定通过 TCP 传输指定的远程 NVMeoF 目标，如下所示：

bluestore_block_path = "spdk:trtype:TCP traddr:10.67.110.197 trsvcid:4420 subnqn:nqn.2019-02.io.spdk:cnode1"

要在每个节点上运行多个 SPDK 实例，你必须确保每个实例使用自己的 DPDK 内存，方法是针对每个实例指定它将使用的 DPDK 内存量（以 MB 为单位）。

在大多数情况下，单个设备可用于数据、DB 和 WAL。我们将此策略描述为共位于这些组件。务必输入以下设置以确保所有 I/O 都通过 SPDK 发出：

bluestore_block_db_path = ""
bluestore_block_db_size = 0
bluestore_block_wal_path = ""
bluestore_block_wal_size = 0

如果不输入这些设置，则当前实现将使用内核文件系统符号填充 SPDK 映射文件，并使用内核驱动程序发出 DB/WAL I/O。

最小分配大小

BlueStore 在底层存储设备上分配的存储量有一个配置的最小值。实际上，这是即使最小的 RADOS 对象在每个 OSD 的主设备上也能消耗的最小容量。与此相关的问题配置选项--bluestore_min_alloc_size--derivesbluestore_min_alloc_size_hdd或bluestore_min_alloc_size_ssd的值，取决于 OSD 的rotational属性。因此，如果 OSD 是在 HDD 上创建的，BlueStore 将使用bluestore_min_alloc_size_hdd的当前值初始化；但是，对于 SSD OSD（包括 NVMe 设备），BlueStore 将使用bluestore_min_alloc_size_ssd.

的当前值初始化。

这些更改是由 Ceph RADOS GateWay (RGW) 部署（这些部署托管大量小文件（S3/Swift 对象））所经历的存储放大引起的。

For example, when an RGW client stores a 1 KB S3 object, that object is written to a single RADOS object. In accordance with the default min_alloc_size值，分配 4 KB 的底层驱动器空间。百分比会迅速减少。

有一个很容易被忽略的额外细节：刚才描述的放大现象发生在每个副本上。例如，当使用默认的三个副本（3R）时，1 KB S3 对象实际上会闲置大约 9 KB 的存储设备容量。如果使用纠删码（EC）而不是复制，则放大可能更高：对于k=4, m=2池，我们的 1 KB S3 对象分配了 24 KB（即 4 KB 乘以 6）的设备容量。

当 RGW 桶池包含许多相对较大的用户对象时，这种现象的影响通常可以忽略不计。然而，对于可以预期有相当一部分相对较小的用户对象的部署，应该考虑这种影响。

4KB 默认值与传统的 HDD 和 SSD 设备很好地匹配。但是，某些新型粗-IU（间接单元）QLC SSD 在bluestore_min_alloc_size_ssd指定在 OSD 创建时与设备的 IU 匹配时表现最佳：这可能为 8KB、16KB，甚至 64KB。这些新型存储驱动器可以实现与传统 TLC SSD 相当的读取性能，比 HDD 更快的写入性能，以及比 TLC SSD 更高的密度和更低的成本。

注意，在创建这些新型设备上的 OSD 时，必须小心地仅将非默认值应用于适当的设备，而不要应用于传统的 HDD 和 SSD 设备。通过仔细排序 OSD 创建、自定义 OSD 设备类以及特别是使用中央配置掩码.

在 Quincy 和以后的版本中，你可以使用bluestore_use_optimal_io_size_for_min_alloc_size选项来允许自动发现正确的值，因为每个 OSD 创建时都会发现。请注意，使用bcache, OpenCAS, dmcrypt, ATA over Ethernet, iSCSI，或其他设备层叠和抽象技术可能会使确定正确值变得复杂。此外，在 VMware 存储上部署的 OSD 有时被发现报告的rotational属性与底层硬件不匹配。

我们建议通过日志和管理套接字在启动时检查这些 OSD，以确保它们的行为正确。请注意，这种检查可能无法像预期的那样与旧内核一起工作。要检查此问题，请检查/sys/block/<drive>/queue/optimal_io_size.

Note

的存在和值。min_alloc_sizeveniently 报告。ceph osd metadata.

在运行 Reef 或以后的 Ceph 版本时，每个 OSD 中嵌入的

ceph osd metadata osd.1701 | egrep rotational\|alloc

这种空间放大可能会表现为ceph df报告的原始数据与存储数据的不寻常的高比率。此外，%USE / VAR值，与其他明显相同的 OSD 相比，这些值异常高。最后，使用具有不匹配ceph osd df可能会报告min_alloc_size值的 OSD 的池中可能会出现意外的平衡器行为。

此 BlueStore 属性在 OSD 创建时生效；如果更改此属性，则除非 OSD 被销毁并使用适当的选项值重新部署，否则特定 OSD 的行为不会改变。only at OSD creation; if the attribute is changed later, a specific OSD’s behavior will not change unless and until the OSD is destroyed and redeployed with the appropriate option value(s). Upgrading to a later Ceph release will firefly 发布。Firefly 将延迟至少另一个冲刺，以便我们可以对新代码进行一些操作经验，并进行一些额外的测试，然后再承诺长期支持。更改由较旧版本部署或使用其他设置使用的 OSD 的值。

bluestore_min_alloc_size

较小的分配大小通常意味着当触发写时，读取的数据更少（例如，写入最近快照的内容）。类似地，在执行覆盖之前，写入的数据量小于

type:

uint

default:

0

bluestore_min_alloc_size_hdd

旋转媒体的默认 min_alloc_size 值

type:

size

default:

4Ki

参见:

bluestore_min_alloc_size

bluestore_min_alloc_size_ssd

非旋转（固态）媒体的默认 min_alloc_size 值

type:

size

default:

4Ki

参见:

bluestore_min_alloc_size

bluestore_use_optimal_io_size_for_min_alloc_size

发现媒体最佳 IO 大小并用于 min_alloc_size

type:

bool

default:

false

参见:

bluestore_min_alloc_size

DSA（数据流加速器）使用

如果你想使用 DML 库来驱动 DSA 设备以卸载持久内存 (PMEM) 上的读写操作，你需要安装DML和idxd-config库。这将仅在具有 SPR（Sapphire Rapids）CPU 的机器上工作。

After installing the DML software, configure the shared work queues (WQs) with reference to the following WQ configuration example:

accel-config config-wq --group-id=1 --mode=shared --wq-size=16 --threshold=15 --type=user --name="MyApp1" --priority=10 --block-on-fault=1 dsa0/wq0.1
accel-config config-engine dsa0/engine0.1 --group-id=1
accel-config enable-device dsa0
accel-config enable-wq dsa0/wq0.1

由 Ceph 基金会带给您

Ceph 文档是一个社区资源，由非盈利的 Ceph 基金会资助和托管Ceph Foundation. 如果您想支持这一点和我们的其他工作，请考虑加入现在加入.