web-dev-qa-db-ja.com

bcacheは、キャッシュデバイスとしてのLVM論理ボリュームの使用をサポートしていますか？

Ubuntu 14.04を実行しているシステムに64GB SSDと3TBハードドライブがあります。 SSDには小さなルートパーティションがあり、残りのデバイスはLVM物理ボリュームに割り当てられています。そのLVM物理ボリュームから、/ usr用と/ root用の2つの論理ボリュームが割り当てられています。 （/ homeは3TBハードドライブ上にあります。）

現在約25GBのSSDが未使用であるため、/ homeをバッキングデバイスとしてbcacheキャッシュデバイスとして使用することは興味深いと思いました。

SSD上のLVM物理ボリューム上の残りのスペースを使用して、新しい論理ボリュームを作成しました。その結果、次のようになりました。

# 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

システムはすぐに完全にロックアップしました。 （したがって、上記は再構成であり、実際に実行したコマンドはもうありません。）

私はそれを実現せずに愚かなことをしましたか？これはサポートされている構成ですか？これをバグとして報告する価値があるかどうか疑問に思っています。クラッシュによって永続的に害を受けたものはないようです。

crashbcache
1
saf

私は間違いなくバグを報告すべきだと思います。 LVをbcacheとして使用することも考えたことがありません。PVのみです。そして多分（たぶん）あなたはこれまでに試した最初の人です...そしておそらくそれは処理されません...

SysBckを続行して、これを自分で試してほしいですか？ （今日はもうありません：疲れすぎです！）

システムバックアップ ??? （あなたはユーザータイプ4です）

0
Fabby

はい、そうです。誤って逆方向にセットアップしました。キャッシュデバイスとしてlvmを設定し、バッキングデバイスとしてramdriveを設定します。しかし、それでもあなたの質問に答えるにはうまくいきます。

ただし、lvm2にはキャッシュ機能があるので、それを使用すること（これは私が行ったことです）を選択し、lvmをRAMにキャッシュする場合はbcacheを使用することもできます。

0
thistleknot

私の場合、bcache-super-showで確認されているように、この問題はbcacheで既にアクティブに使用されているデバイスが原因でした。

$ 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がこれを検出できなかったことです。

これが将来、他の誰かに役立つことを願っています。

0
sleepycal