В моей системе с Ubuntu 14.04 установлен 64-Гбайт SSD и 3 ТБ жесткий диск. SSD имеет небольшой корневой раздел с остальной частью устройства, выделенный физическому тому LVM. Из этого физического объема LVM у меня выделено два логических тома: один для / usr и один для / root. (/ home находится на жестком диске 3 ТБ.)
Поскольку у меня было около 25 ГБ SSD, которые в настоящее время не используются, я подумал, что было бы интересно попробовать использовать его в качестве устройства кэширования bcache с / home в качестве резервного устройства .
Я создал новый логический том, используя оставшееся место на физическом томе LVM на SSD. Это оставило такие вещи:
# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 VG4 lvm2 a-- 53.57g 0
/dev/sdb2 VG6 lvm2 a-- 2.69t 0
# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
VG4-usr VG4 -wi-ao--- 19.31g
VG4-var VG4 -wi-ao--- 9.31g
bcache VG4 -wi-ao--- 24.95g
home VG6 -wi-ao--- 2.69t
Затем я сделал:
# make-bcache -C /dev/mapper/VG4-bcache
Система сразу же полностью заблокирована. (Итак, вышеперечисленное является реконструкцией, у меня нет фактической команды, которую я выполнил.)
Я сделал что-то глупое, не осознавая этого? Является ли это поддерживаемой конфигурацией? Мне интересно, стоит ли сообщать об этом как об ошибке или нет. По всей видимости, ничто не пострадало от катастрофы.
Да, да. Я случайно сделал свою настройку назад. Я установил свой lvm как устройство для кеширования и мой ramdrive в качестве поддерживающего устройства. Но, чтобы ответить на ваш вопрос, он работает.
Но я должен упомянуть, что у lvm2 есть функция кеширования, вы можете также использовать ее (что я и сделал), а затем использовать bcache, если вы хотите кэшировать lvm для ram
В моем случае проблема была связана с тем, что устройство уже активно используется в bcache, что подтверждено bcache-super-show.
$ make-bcache -B /dev/ssd/cache
Can't open dev /dev/ssd/cache: Device or resource busy
$ make-bcache -C /dev/ssd/cache
Can't open dev /dev/ssd/cache: Device or resource busy
$ pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/md100-crypt hdd lvm2 a-- 3.64t 186.30g
/dev/mapper/md101-crypt ssd lvm2 a-- 119.17g 32.23g
/dev/md0 system lvm2 a-- 13.81g 4.50g
$ lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
data hdd -wi-ao--- 3.46t
cache ssd -wi-ao--- 29.75g
data ssd -wi-ao--- 57.20g
root system -wi-ao— 9.31g
Кажется, что не удалось выполнить следующие
open("/dev/ssd/cache", O_RDWR|O_EXCL) = -1 EBUSY (Device or resource busy)
До этого отказа кажется следующее:
open("/dev/ssd/cache", O_RDONLY) = 4
ioctl(4, BLKSSZGET, 512) = 0
close(4) = 0
Это заставляет меня думать, что O_EXCL отвечает за EBUSY, указывая, что, возможно, другой процесс удерживает блокировку однако, я могу подтвердить, что /dev/ssd/cache не установлен, не открыт или не используется (как видно из lsof или fuser), и что перезагрузка не решает проблему.
Попытка удалить ее из device-mapper также не дает никакого прогресса;
$ dmsetup remove ssd-cache
device-mapper: remove ioctl on ssd-cache failed: Device or resource busy
Итак, после запуска lsblk я вижу следующее:
sdb 8:16 0 119.2G 0 disk
└─sdb1 8:17 0 119.2G 0 part
└─md101 9:101 0 119.2G 0 raid1
└─md101-crypt (dm-3) 252:3 0 119.2G 0 crypt
├─ssd-data (dm-4) 252:4 0 57.2G 0 lvm /mnt/ssd/data
└─ssd-cache (dm-5) 252:5 0 29.8G 0 lvm
└─bcache0 251:0 0 29.8G 0 disk
Как вы можете видеть, bcache0 является дочерним соответствующее устройство, и быстрая проверка подтверждает это:
$ bcache-super-show /dev/ssd/cache
sb.magic ok
sb.first_sector 8 [match]
sb.csum 9F5D50331A2A10B9 [match]
sb.version 1 [backing device]
dev.label (empty)
dev.uuid 8ba675a3-d9e4-4d47-8403-655c226f578f
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 0 [detached]
cset.uuid c006c316-d396-40cf-bde8-8bd4d0a017e8
Таким образом, проблема с корнем в моем случае состояла в том, что само устройство уже было частью bcache, а make-bcache не удалось обнаружить это.
Надеюсь, это будет полезно кому-то еще в будущем.