lvm mit raidintegrity: imeta lv's auf ssd?

Probleme mit Samba, NFS, FTP und Co.
Antworten
reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

lvm mit raidintegrity: imeta lv's auf ssd?

Beitrag von reox » 04.04.2021 11:00:10

Mit lvm aus bullseye kann man auch dm-integrity für lvm raids verwenden. Ich hab mich damit ein wenig herumgespielt muss aber sagen das ist super langsam.
Mit Debianfio getestet:

Code: Alles auswählen

$ grep groupid r10_*_2.log  -A1
r10_int_2.log:randwrite: (groupid=0, jobs=1): err= 0: pid=852: Sun Apr  4 10:06:16 2021
r10_int_2.log-  write: IOPS=9, BW=9.93MiB/s (10.4MB/s)(596MiB/60007msec); 0 zone resets
--
r10_int_2.log:randread: (groupid=0, jobs=1): err= 0: pid=860: Sun Apr  4 10:06:16 2021
r10_int_2.log-  read: IOPS=120, BW=121MiB/s (126MB/s)(7266MiB/60256msec)
--
r10_int_2.log:seqread: (groupid=0, jobs=1): err= 0: pid=984: Sun Apr  4 10:06:16 2021
r10_int_2.log-  read: IOPS=393, BW=394MiB/s (413MB/s)(23.1GiB/60047msec)
--
r10_int_2.log:seqwrite: (groupid=0, jobs=1): err= 0: pid=985: Sun Apr  4 10:06:16 2021
r10_int_2.log-  write: IOPS=25, BW=25.0MiB/s (26.3MB/s)(1503MiB/60006msec); 0 zone resets



r10_noint_2.log:randwrite: (groupid=0, jobs=1): err= 0: pid=1131: Sun Apr  4 10:10:18 2021
r10_noint_2.log-  write: IOPS=24, BW=24.2MiB/s (25.4MB/s)(1453MiB/60016msec); 0 zone resets
--
r10_noint_2.log:randread: (groupid=0, jobs=1): err= 0: pid=1165: Sun Apr  4 10:10:18 2021
r10_noint_2.log-  read: IOPS=221, BW=221MiB/s (232MB/s)(13.0GiB/60170msec)
--
r10_noint_2.log:seqread: (groupid=0, jobs=1): err= 0: pid=1177: Sun Apr  4 10:10:18 2021
r10_noint_2.log-  read: IOPS=538, BW=538MiB/s (564MB/s)(31.6GiB/60076msec)
--
r10_noint_2.log:seqwrite: (groupid=0, jobs=1): err= 0: pid=1178: Sun Apr  4 10:10:18 2021
r10_noint_2.log-  write: IOPS=58, BW=58.0MiB/s (60.8MB/s)(3483MiB/60045msec); 0 zone resets

Jeweils ein 4 Platten RAID10 mit und ohne --raidintegrity.
Wie man sieht, das wird etwa um die hälfte langsamer - beim schreiben aber auch beim lesen - was Sinn macht, weil beim schreiben die Checksums geschrieben werden und beim Lesen eben auch gelesen und verglichen.
Ich hab auch die bitmap methode getestet, die ist beim schreiben in der mitte zwischen den beiden aber beim lesen auf dem selben niveau wie das journal (macht ebenfalls Sinn).
(übrigens, die platten sind auch nicht die schnellsten: NoPaste-Eintrag41346)

Ich hab mir dann noch gedacht, es sollte doch möglich sein das integrity volume auf eine andere disk zu legen.
Zumal ja kein Datenverlust droht wenn diese Daten weg wären.
Ich hätt da noch eine SSD aber pvmove lässt mich nicht:

Code: Alles auswählen

# pvmove -n r10_int_rimage_0_imeta /dev/sdd /dev/sda2
  Unable to pvmove device used for raid with integrity.
Ich les unter https://www.kernel.org/doc/html/latest/ ... grity.html nichts was dagegen sprechen würde, dass es eigentlich gehen sollte, zumal es diese option gibt:

Code: Alles auswählen

meta_device:device
Don’t interleave the data and metadata on the device. Use a separate device for metadata.
Ist einfach davon auszugehen, dass weder die erstellung der metadaten auf einem anderen volume als auch das verschieben in lvm noch nicht drin ist? Oder gibt es eine andere Möglichkeit das zu verschieben oder direkt woanders anzulegen?

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: lvm mit raidintegrity: imeta lv's auf ssd?

Beitrag von reox » 05.04.2021 13:26:04

Hab mal im code gestöbert - das ist dort tatsächlich hardcodiert: https://sourceware.org/git/?p=lvm2.git; ... 9e551#l552
Schaut also schlecht aus das man es einstellen kann...

Wäre aber trotzdem interessant zu wissen ob es grundsätzlich eine schlechte Idee ist?

Antworten