web-dev-qa-db-fra.com

Bcache prend-il en charge l'utilisation d'un volume logique LVM comme périphérique de cache?

J'ai un SSD de 64 Go et un disque dur de 3 To dans mon système exécutant Ubuntu 14.04. Le SSD a une petite partition racine avec le reste du périphérique alloué à un volume physique LVM. À partir de ce volume physique LVM, j'ai deux volumes logiques alloués, un pour/usr et un pour/root. (/ home se trouve sur le disque dur de 3 To.)

Étant donné que j'avais environ 25 Go de SSD actuellement inutilisés, j'ai pensé qu'il serait intéressant d'essayer de l'utiliser comme périphérique de cache bcache avec/home comme périphérique de sauvegarde.

J'ai créé un nouveau volume logique en utilisant l'espace restant sur le volume physique LVM sur le SSD. Cela a laissé les choses ressembler à ceci:

# 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

J'ai ensuite fait:

# make-bcache -C /dev/mapper/VG4-bcache

Le système s'est immédiatement verrouillé complètement. (Donc, ce qui précède est une reconstruction, je n'ai plus la commande que j'ai exécutée.)

Ai-je fait quelque chose de stupide sans m'en rendre compte? S'agit-il d'une configuration prise en charge? Je me demande s'il vaut la peine de signaler cela comme un bug ou non. Rien ne semble avoir été définitivement endommagé par l'accident.

crashbcache
1
saf

Je pense définitivement que vous devez signaler un bug . Je n'ai même jamais pensé à utiliser un LV comme bcache, seulement PV. Et peut-être (juste peut-être) vous êtes le premier à avoir essayé ... Et ce n'est probablement pas géré ...

Voulez-vous que je procède à un SysBck et que j'essaye moi-même? (Plus aujourd'hui: trop fatigué!)

Avez-vous une sauvegarde du système ??? (vous êtes un utilisateur de type 4)

0
Fabby

Oui. J'ai accidentellement fait ma configuration à l'envers. J'ai défini mon lvm comme périphérique de mise en cache et mon ramdrive comme périphérique de sauvegarde. Mais pourtant, pour répondre à votre question cela fonctionne.

Mais je dois mentionner que lvm2 a une fonction de mise en cache, vous pourriez aussi bien choisir d'utiliser cela (ce que j'ai fait), puis d'utiliser bcache si vous souhaitez mettre en cache le lvm à ram

0
thistleknot

Dans mon cas, le problème était dû au fait que l'appareil était déjà activement utilisé dans bcache, comme l'a confirmé 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

Semble échouer sur les points suivants

open("/dev/ssd/cache", O_RDWR|O_EXCL) = -1 EBUSY (Device or resource busy)

Avant cet échec, ce qui suit semble réussir;

open("/dev/ssd/cache", O_RDONLY) = 4
ioctl(4, BLKSSZGET, 512) = 0
close(4)             = 0

Cela m'amène à croire que O_EXCL est responsable du EBUSY, ce qui indique qu'un autre processus détient peut-être un verrou sur l'appareil, mais je peux confirmer que /dev/ssd/cache n'est pas monté, ouvert ou en cours d'utilisation (comme vu dans lsof ou fuser), et ce redémarrage ne résout pas le problème.

Tenter de le supprimer du mappeur de périphériques ne produit également aucun progrès;

$ dmsetup remove ssd-cache
device-mapper: remove ioctl on ssd-cache failed: Device or resource busy

Ainsi, après avoir exécuté lsblk, je peux voir ce qui suit;

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

Comme vous pouvez le voir, bcache0 est un enfant de l'appareil en question, et une vérification rapide le confirme;

$ 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

Par conséquent, le problème racine dans mon cas était que le périphérique lui-même faisait déjà partie de bcache, et make-bcache n'a pas pu détecter cela.

J'espère que cela sera utile à quelqu'un d'autre à l'avenir.

0
sleepycal