我正在尝试使用本地 SSD 的 raid 作为缓存设备在谷歌云的一个实例中设置 bcache，但在该过程的附加阶段一切都失败了。出于测试目的，我创建了一个带有空白磁盘（两个 SSD 和四个本地 SSD）的新实例。目标是使用一个常规 SSD 作为后备设备，并与 4 个本地 SSD 形成一个 raid，并使用该设备作为缓存。
在下面的输出中，您可以看到所采取的步骤（使用 raid 时的结果是相同的，为了简单起见，我在这里只使用了一个本地 SSD，因为我相信问题与 raid 无关，而是与磁盘本身有关）。当使用本地 SSD 作为缓存设备时，我无法将缓存设备连接到支持设备。当我使用常规 SSD 作为缓存设备时，您可以看到一切都按预期工作。
各位专家的问题是：本地 SSD 是否有任何已知的限制，或者我是否做错了什么（或者可能需要一些额外的步骤）？
作为参考，这些是正在使用的设备：
/dev/sdb => Backing Device
/dev/sdc => SSD Caching Device
/dev/nvme0n1 => Local SSD Single Caching Device
# apt update && apt install mdadm bcache-tools -y
# make-bcache -B /dev/sdb
UUID: cb10650f-cf60-4a96-81eb-7149ae650f94
Set UUID: dc0a7f3a-de46-4b00-84f4-4aa40c203745
version: 1
block_size: 1
data_offset: 16
# mkfs.ext4 -L cached /dev/bcache0
# make-bcache -C /dev/nvme0n1
UUID: c5a33c1e-e1ef-4d3d-a5ac-5d0adc340f43
Set UUID: 228dcba5-6085-47a1-b2e9-eff68dd6ac14
version: 0
nbuckets: 768000
block_size: 8
bucket_size: 1024
nr_in_set: 1
nr_this_dev: 0
first_bucket: 1
# bcache-super-show /dev/nvme0n1
sb.magic ok
sb.first_sector 8 [match]
sb.csum 674DD52F06C4562B [match]
sb.version 3 [cache device]
dev.label (empty)
dev.uuid c5a33c1e-e1ef-4d3d-a5ac-5d0adc340f43
dev.sectors_per_block 8
dev.sectors_per_bucket 1024
dev.cache.first_sector 1024
dev.cache.cache_sectors 786430976
dev.cache.total_sectors 786432000
dev.cache.ordered yes
dev.cache.discard no
dev.cache.pos 0
dev.cache.replacement 0 [lru]
cset.uuid 228dcba5-6085-47a1-b2e9-eff68dd6ac14
# echo 228dcba5-6085-47a1-b2e9-eff68dd6ac14 > /sys/block/bcache0/bcache/attach
-bash: echo: write error: Invalid argument
# make-bcache -C /dev/sdc
UUID: 55c95063-9aa7-4d2c-8c8c-d4d34d35a7ad
Set UUID: 2de3ccef-a7eb-4620-8b6d-265d0a06da17
version: 0
nbuckets: 204800
block_size: 1
bucket_size: 1024
nr_in_set: 1
nr_this_dev: 0
first_bucket: 1
# bcache-super-show /dev/sdc
sb.magic ok
sb.first_sector 8 [match]
sb.csum 11E99ECE7A83EABE [match]
sb.version 3 [cache device]
dev.label (empty)
dev.uuid 55c95063-9aa7-4d2c-8c8c-d4d34d35a7ad
dev.sectors_per_block 1
dev.sectors_per_bucket 1024
dev.cache.first_sector 1024
dev.cache.cache_sectors 209714176
dev.cache.total_sectors 209715200
dev.cache.ordered yes
dev.cache.discard no
dev.cache.pos 0
dev.cache.replacement 0 [lru]
cset.uuid 2de3ccef-a7eb-4620-8b6d-265d0a06da17
# echo 2de3ccef-a7eb-4620-8b6d-265d0a06da17 > /sys/block/bcache0/bcache/attach
# bcache-super-show /dev/sdc
sb.magic ok
sb.first_sector 8 [match]
sb.csum 11E99ECE7A83EABE [match]
sb.version 3 [cache device]
dev.label (empty)
dev.uuid 55c95063-9aa7-4d2c-8c8c-d4d34d35a7ad
dev.sectors_per_block 1
dev.sectors_per_bucket 1024
dev.cache.first_sector 1024
dev.cache.cache_sectors 209714176
dev.cache.total_sectors 209715200
dev.cache.ordered yes
dev.cache.discard no
dev.cache.pos 0
dev.cache.replacement 0 [lru]
cset.uuid 2de3ccef-a7eb-4620-8b6d-265d0a06da17
# bcache-super-show /dev/sdb
sb.magic ok
sb.first_sector 8 [match]
sb.csum 2E55F82F4131C19B [match]
sb.version 1 [backing device]
dev.label (empty)
dev.uuid cb10650f-cf60-4a96-81eb-7149ae650f94
dev.sectors_per_block 1
dev.sectors_per_bucket 1024
dev.data.first_sector 16
dev.data.cache_mode 0 [writethrough]
dev.data.cache_state 1 [clean]
cset.uuid 2de3ccef-a7eb-4620-8b6d-265d0a06da17
答案1
经过一些详细的审查后，我意识到问题出在不同设备的块大小上。当调整 make-bcache 命令时，一切都按预期工作：
make-bcache --block 4k -B /dev/sdb
make-bcache --block 4k -C /dev/nvme0n1