Tenho um disco rígido de 64 GB e um disco rígido de 3 TB no meu sistema com o Ubuntu 14.04. O SSD possui uma pequena partição raiz com o restante do dispositivo alocado para um volume físico LVM. A partir desse volume físico de LVM, tenho dois volumes lógicos alocados, um para / usr e outro para / root. (/ home está no disco rígido de 3 TB.)
Como eu tinha 25 GB de SSD atualmente não utilizados, achei que seria interessante tentar usá-lo como um dispositivo de cache bcache com / home como dispositivo de apoio.
Eu criei um novo volume lógico usando o espaço restante no volume físico do LVM no SSD. Isso deixou as coisas assim:
# 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
Eu então fiz:
# make-bcache -C /dev/mapper/VG4-bcache
O sistema imediatamente trancou completamente. (Então, o acima é uma reconstrução, eu não tenho mais o comando que executei.)
Eu fiz algo estúpido sem perceber? Esta é uma configuração suportada? Eu estou querendo saber se vale a pena relatar isso como um bug ou não. Nada parece ter sido permanentemente prejudicado pelo acidente.
Eu definitivamente acho que você deve registrar um bug . Eu nunca pensei em usar um LV como bcache, apenas PV. E talvez (apenas talvez) você seja o primeiro que já tentou ... E provavelmente não é tratado ...
Você quer que eu continue com um SysBck e tente isso sozinho? (Hoje não mais: cansado demais!)
Você tem um backup do sistema ??? (você é tipo de usuário 4)
Sim, sim. Eu acidentalmente fiz a minha configuração para trás. Eu defini meu lvm como o dispositivo de armazenamento em cache e minha ramdrive como o dispositivo de apoio. Mas ainda assim, para responder sua pergunta, funciona.
Mas eu devo mencionar que lvm2 tem um recurso de cache, você pode também optar por usar isso (que é o que eu fiz) e, em seguida, usar bcache se você quiser armazenar em cache o lvm para ram
No meu caso, o problema foi devido ao dispositivo já estar sendo usado ativamente no bcache, como confirmado por 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
Parece falhar no seguinte
open("/dev/ssd/cache", O_RDWR|O_EXCL) = -1 EBUSY (Device or resource busy)
Antes dessa falha, o seguinte parece ter sucesso;
open("/dev/ssd/cache", O_RDONLY) = 4
ioctl(4, BLKSSZGET, 512) = 0
close(4) = 0
Isso me leva a acreditar que O_EXCL é responsável pelo EBUSY , indicando que talvez outro processo esteja bloqueando o dispositivo, no entanto, posso confirmar que /dev/ssd/cache não está montado, aberto ou em uso ( como visto em lsof ou fuser), e essa reinicialização não resolve o problema.
A tentativa de removê-lo do mapeador de dispositivos também não gera progresso;
$ dmsetup remove ssd-cache
device-mapper: remove ioctl on ssd-cache failed: Device or resource busy
Então, depois de executar lsblk , posso ver o seguinte:
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
Como você pode ver, o bcache0 é um filho do dispositivo em questão, e uma verificação rápida confirma isso;
$ 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
Portanto, o problema raiz no meu caso era que o próprio dispositivo já fazia parte do bcache e make-bcache não conseguiu detectar isso.
Espero que isso seja útil para outra pessoa no futuro.