bcache поддерживает использование логического тома LVM как устройство кэша?
У меня есть SSD на 64 ГБ и жесткий диск на 3 ТБ в моей системе под управлением Ubuntu 14.04. SSD имеет небольшой корневой раздел с отдыхом устройства, выделенного физическому тому LVM. От этого физический том LVM у меня есть два выделенные логических тома, один для/usr и один для корня/. (/домой находится на жестком диске на 3 ТБ.)
Так как у меня было приблизительно 25 ГБ в настоящее время неиспользованного SSD, я думал, что будет интересно попытаться использовать его в качестве bcache устройства кэша с / домой как отступающее устройство.
Я создал новый логический том, использующий остающееся пространство на физическом томе 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
Система сразу заперта полностью. (Таким образом, вышеупомянутое является реконструкцией, у меня нет фактической команды, которую я больше выполнял.)
Я делал что-то глупое, не понимая это? Действительно ли это - поддерживаемая конфигурация? Я задаюсь вопросом, стоит ли сообщить об этом как об ошибке или нет. Ничто, кажется, не было постоянно повреждено из-за катастрофического отказа.
3 ответа
Я определенно думаю, что необходимо зарегистрировать ошибку . Я даже не думал об использовании LV как bcache, только PV. И возможно (просто, возможно) Вы - первый, кого когда-либо судят... И это, вероятно, не обрабатывается...
Вы хотите, чтобы я возобновил SysBck и попробовал это сам? (Не сегодня больше: слишком усталый!)
Вы имеете системное резервное копирование ??? (Вы - пользовательский тип 4)
Да это делает. Я случайно сделал свою установку назад. Я установил свой lvm как устройство кэширования и мой ramdrive как отступающее устройство. Но, для ответа на вопрос это действительно работает.
, Но я должен упомянуть, что lvm2 имеет возможность кэширования, Вы могли бы также решить использовать это (который является тем, что я сделал), и затем используйте bcache, если Вы хотите кэшировать lvm для трамбовки
В моем случае проблема, уже произошла из-за устройства активно используясь в 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 или термофиксаторе), и что перезагрузка не разрешает проблему.
Попытка удалить его из картопостроителя устройства также не приводит ни к какому прогрессу;
$ 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 не удалось обнаружить это.
Надо надеяться, это будет полезно для кого-то еще в будущем.