Anzeige:
Ergebnis 1 bis 2 von 2

Thema: LVM Cache wird bleibt nicht dauerhaft

  1. #1
    /linux/user Avatar von torsten_boese
    Registriert seit
    Dec 2003
    Beiträge
    660

    LVM Cache bleibt nicht dauerhaft

    Hallo zusammen,

    ich möchte ein LVM mit CACHE erstellen.

    dazu habe ich mich an dieser Anelitung orientiert:
    Code:
    Cache mode
    
    
           The default cache mode is "writethrough".  Writethrough ensures that any data written will be stored  both  in
           the  cache  pool LV and on the origin LV.  The loss of a device associated with the cache pool LV in this case
           would not mean the loss of any data.
    
           A second cache mode is "writeback".  Writeback delays writing data blocks from the cache pool back to the ori‐
           0. Create an origin LV we wish to cache (yours may already exist)
           # lvcreate -L 10G -n lv1 vg /dev/slow
    
           1. Create a cache data LV
           # lvcreate -L 1G -n cache1 vg /dev/fast
    
           2. Create a cache metadata LV
           # lvcreate -L 8M -n cache1meta vg /dev/fast
    
           3. Create a cache pool LV
           # lvconvert --type cache-pool --poolmetadata vg/cache1meta vg/cache1
    
           4. Create a cache LV by combining the cache pool LV and origin LV,
              and use the writethrough cache mode.
           # lvconvert --type cache --cachepool vg/cache1 \
                --cachemode writethrough vg/lv1
    Meinem System:
    Debian Stretch
    /dev/md3 : Raid5 Device aus HDD's, welches die Nutzdaten enthalten soll
    /dev/sdi : SSD - Soll den CACHE beherbergen.

    Auf beiden Devices habe ich eine LVM-Partition erstellt.

    Das LVM-CACHE-Device habe ich folgendermaßen aufgesetzt:
    Code:
    root@tb:/home/torsten# vgcreate media /dev/md3p1 /dev/sdi1
      Physical volume "/dev/md3p1" successfully created.
      Physical volume "/dev/sdi1" successfully created.
      Volume group "media" successfully created
    root@tb:/home/torsten# lvcreate -l 1907658 -n lv media /dev/md3p1
      Logical volume "lv" created.
    root@tb:/home/torsten# lvcreate -l 28567 -n lv_cache media /dev/sdi1
      Logical volume "lv_cache" created.
    root@tb:/home/torsten# lvcreate -l 25 -n lv_cache_meta media /dev/sdi1
      Logical volume "lv_cache_meta" created.
    root@tb:/home/torsten# lvconvert --type cache-pool --poolmetadata media/lv_cache_meta media/lv_cache
      Using 128.00 KiB chunk size instead of default 64.00 KiB, so cache pool has less then 1000000 chunks.
      WARNING: Converting logical volume media/lv_cache and media/lv_cache_meta to cache pool's data and metadata volumes with metadata wiping.
      THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
    Do you really want to convert media/lv_cache and media/lv_cache_meta? [y/n]: y
      Converted media/lv_cache to cache pool.
    root@tb:/home/torsten# lvconvert --type cache --cachepool media/lv_cache --cachemode writeback  media/lv
    Do you want wipe existing metadata of cache pool volume media/lv_cache? [y/n]: y
      Logical volume media/lv is now cached.
    Ein Blick auf

    Code:
    root@tb:/home/torsten# lvs -a -o +devices
      LV               VG        Attr       LSize   Pool       Origin     Data%  Meta%  Move Log Cpy%Sync Convert Devices
      2gb              daten-2gb -wi-a-----   1.82t                                                               /dev/sdk1(0)
      home1            home      -wi-ao---- 417.20g                                                               /dev/mapper/md1p1_crypt(0)
      lv               media     Cwi-a-C---   7.28t [lv_cache] [lv_corig] 0.00   7.10            0.00             lv_corig(0)
      [lv_cache]       media     Cwi---C--- 111.59g                       0.00   7.10            0.00             lv_cache_cdata(0)
      [lv_cache_cdata] media     Cwi-ao---- 111.59g                                                               /dev/sdi1(0)
      [lv_cache_cmeta] media     ewi-ao---- 100.00m                                                               /dev/sdi1(28567)
      [lv_corig]       media     owi-aoC---   7.28t                                                               /dev/md3p1(0)
      [lvol0_pmspare]  media     ewi------- 100.00m                                                               /dev/sdi1(28592)
    sieht so weit gut aus. Ich kann das LV auf formatieren und beschreiben. Jedoch nach einem Neustart oder wenn ich das LV mittels

    Code:
    root@tb:/home/torsten# vgchange -a n
      0 logical volume(s) in volume group "daten-2gb" now active
      /usr/sbin/cache_check: execvp failed: No such file or directory
      WARNING: Integrity check of metadata for pool media/lv_cache failed.
      0 logical volume(s) in volume group "media" now active
      Logical volume home/home1 contains a filesystem in use.
      Can't deactivate volume group "home" with 1 open logical volume(s)
    root@tb:/home/torsten# vgchange -a y
      1 logical volume(s) in volume group "daten-2gb" now active
      /usr/sbin/cache_check: execvp failed: No such file or directory
      Check of pool media/lv_cache failed (status:2). Manual repair required!
      0 logical volume(s) in volume group "media" now active
      1 logical volume(s) in volume group "home" now active
    versuche zu deaktivieren und wieder zu erwecken, kommen die Fehlermeldungen. Aus meiner Sicht habe ich mich an das Kochrezept gehalten. Es gibt noch ziemlich identische Anleitungen im Ubuntu- und RedHat-Wiki.
    Wa mache ich falsch? Verdächtig finde ich Meldung
    Code:
    Do you want wipe existing metadata of cache pool volume media/lv_cache? [y/n]: y
    , da diese in keinem der Anleitungen erwähnt wird.
    Laut
    Code:
    root@tb:/home/torsten# lvs -a -o +devices
      LV               VG        Attr       LSize   Pool       Origin     Data%  Meta%  Move Log Cpy%Sync Convert Devices
      2gb              daten-2gb -wi-a-----   1.82t                                                               /dev/sdk1(0)
      home1            home      -wi-ao---- 417.20g                                                               /dev/mapper/md1p1_crypt(0)
      lv               media     Cwi---C---   7.28t [lv_cache] [lv_corig]                                         lv_corig(0)
      [lv_cache]       media     Cwi---C--- 111.59g                                                               lv_cache_cdata(0)
      [lv_cache_cdata] media     Cwi------- 111.59g                                                               /dev/sdi1(0)
      [lv_cache_cmeta] media     ewi------- 100.00m                                                               /dev/sdi1(28567)
      [lv_corig]       media     owi---C---   7.28t                                                               /dev/md3p1(0)
      [lvol0_pmspare]  media     ewi------- 100.00m                                                               /dev/sdi1(28592)
    siehts auch noch ok aus, aber das META-Device ist laut den Meldungen oben nicht ansprechbar.

    Mittels
    Code:
    root@tb:/home/torsten# lvdisplay media/lv
      --- Logical volume ---
      LV Path                /dev/media/lv
      LV Name                lv
      VG Name                media
      LV UUID                w2j58l-29Rm-uizI-9VsI-OWxZ-AhnK-5NZYow
      LV Write Access        read/write
      LV Creation host, time tb, 2018-10-09 07:46:45 +0200
      LV Status              NOT available
      LV Size                7.28 TiB
      Current LE             1907658
      Segments               1
      Allocation             inherit
      Read ahead sectors     auto
    
    root@tb:/home/torsten# vgdisplay media
      --- Volume group ---
      VG Name               media
      System ID
      Format                lvm2
      Metadata Areas        2
      Metadata Sequence No  7
      VG Access             read/write
      VG Status             resizable
      MAX LV                0
      Cur LV                1
      Open LV               0
      Max PV                0
      Cur PV                2
      Act PV                2
      VG Size               7.39 TiB
      PE Size               4.00 MiB
      Total PE              1936275
      Alloc PE / Size       1936275 / 7.39 TiB
      Free  PE / Size       0 / 0
      VG UUID               wrUWVU-mQYs-tXhv-xoZy-2RhV-fEUC-KQFuKT
    kan man sehen, dass die VG nur aus zwei PV's besteht. Müssten aber, wenn ich nicht falsch liege, drei sein.

    Code:
    root@tb:/home/torsten# lvscan
      ACTIVE            '/dev/daten-2gb/2gb' [1.82 TiB] inherit
      inactive          '/dev/media/lv' [7.28 TiB] inherit
      ACTIVE            '/dev/home/home1' [417.20 GiB] inherit
    Noch eine Verständnis-Frage zum Cache-Mode. Der Writeback Mode beinhaltet bei Ausfall des Cache-Devices das Risiko von Daten verlust (im Gegensatz zum Writethrough Mode). Bezieht sich dieser Datenverlust nur auf die Daten im Cache oder kommt es einem defekten Gerät gleich?
    Ich Frage deswegen, weil ich nicht in der Lage war das "ursprüngliche LVM" ohne Cache einzubinden, was aber, nach meiner Überlegung (Die natürlich falsch sein kann), gehen sollte.


    Danke für eure Hilfe!
    Geändert von torsten_boese (09.10.18 um 13:09 Uhr)

  2. #2
    /linux/user Avatar von torsten_boese
    Registriert seit
    Dec 2003
    Beiträge
    660

Ähnliche Themen

  1. squid läuft aber cache bleibt leer
    Von Batou84 im Forum Linux als Server
    Antworten: 9
    Letzter Beitrag: 20.07.09, 19:44
  2. Kann OpenSuse 10.0 nicht installie. Bleibt hängen bei "Paketauswahl wird ausgewertet"
    Von rebuss im Forum System installieren und konfigurieren
    Antworten: 3
    Letzter Beitrag: 25.04.06, 15:13
  3. DNS - Cache funktioniert nicht
    Von Morten_B im Forum Linux als Server
    Antworten: 15
    Letzter Beitrag: 16.03.03, 20:21
  4. Antworten: 0
    Letzter Beitrag: 25.01.03, 00:39
  5. Squid -- warum bleibt mein cache-verzeichnis leer?
    Von theodorix im Forum Router und Netzaufbau
    Antworten: 1
    Letzter Beitrag: 18.08.02, 21:42

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •