Vad har LVM och en matryoshka gemensamt?

God dag.
Jag vill dela med mig av praktisk erfarenhet av att bygga ett lagringssystem för KVM med hjälp av md RAID + LVM.

Programmet kommer att innehålla:

• Montering av md RAID 1 med NVMe SSD.
• Montering av md RAID 6 med SATA SSD och vanliga diskar.
• Egenskaper för TRIM/DISCARD i SSD RAID 1/6.
• Skapande av en startbar md RAID 1/6-array med en uppsättning gemensamma diskar.
• Installation av systemet på NVMe RAID 1 i avsaknad av stöd för NVMe i BIOS.
• Användning av LVM-cache och LVM-thin.
• Användning av BTRFS-snapshots och send/receive för säkerhetskopiering.
• Användning av LVM-thin snapshots och thin_delta för BTRFS-liknande säkerhetskopiering.

Om det låter intressant, var vänlig scrolla ner.

Ansvarsfriskrivning

Författaren tar inget ansvar för konsekvenserna av att använda eller inte använda material/ exempel/ kod/ råd/ data från denna artikel. Genom att läsa eller på något sätt använda detta material tar du ansvar för alla konsekvenser av dessa åtgärder. Möjliga konsekvenser inkluderar:

• Brända till krispighet NVMe SSD.
• Fullständigt förbrukad skrivresurs och fel på SSD-enheter.
• Total förlust av all data på alla lagringsenheter, inklusive säkerhetskopior.
• Defekt datorutrustning.
• Tappad tid, nerver och pengar.
• Alla andra konsekvenser som inte är listade ovan.

Hårdvara

Tillgängligt var:

Ett moderkort från omkring 2013 baserat på Z87-chipset med Intel Core i7 / Haswell.

• Processor med 4 kärnor, 8 trådar
• 32 Gigabyte DDR3 RAM
• 1 x 16 eller 2 x 8 PCIe 3.0
• 1 x 4 + 1 x 1 PCIe 2.0
• 6 x 6 GBps SATA 3-anslutningar

SAS-adapter LSI SAS9211-8I omprogrammerad till IT / HBA-läge. Firmware med RAID-stöd har avsiktligt bytts ut mot HBA-firmware för att:

1. Man enkelt ska kunna slänga denna adapter och byta till vilken annan som helst som finns tillgänglig.
2. TRIM/Discard fungerade normalt på diskarna, då dessa kommandon inte alls stöds i RAID-firmware, medan HBA i stort sett inne har något emot vilka kommandon som skickas via bussen.

Hårddiskar, — 8 stycken HGST Travelstar 7K1000 med 1 TB kapacitet i 2.5" formfaktor, avsedd för bärbara datorer. Dessa diskar var tidigare i en RAID 6-array. I det nya systemet kommer de också att användas. För lagring av lokala säkerhetskopior.

Dessutom lades till:

6 stycken SATA SSD-modeller Samsung 860 QVO 2TB. Från dessa SSD kunde stor kapacitet, SLC-cache och önskvärdhet av tillförlitlighet, samt ett lågt pris förväntas. Det var obligatoriskt med stöd för discard/zero som verifieras med en rad i dmesg:

kernel: ata1.00: Aktiverar discard_zeroes_data

2 stycken NVMe SSD av modell Samsung SSD 970 EVO 500GB.

För dessa SSD:er är hastigheten för slumpmässig läsning/ skrivning och hållbarhet viktig för dina behov. En kylare till dem. Absolut nödvändigt. Annars bränner du dem till en krispig konsistens vid första RAID-synkroniseringen.

StarTech PEX8M2E2-adapter för 2 x NVMe SSD installerad i PCIe 3.0 8x slot. Detta är, återigen, bara en HBA, men för NVMe. Den skiljer sig från billigare adaptrar genom att den inte kräver stöd för PCIe bifurkation från moderkortet tack vare den inbyggda PCIe-switch. Kommer att fungera även i de äldsta systemen som har PCIe, även om det är en x1 PCIe 1.0 slot. Naturligtvis, med motsvarande hastighet. Det finns inga RAID-funktioner där. Ingen inbyggd BIOS ombord. Så, ditt system kommer inte magiskt att lära sig att starta från NVMe, än mindre att göra NVMe RAID tack vare denna enhet.

Denna komponent valdes uteslutande på grund av att det bara fanns en ledig 8x PCIe 3.0 i systemet, och om det fanns 2 lediga slots, kan den lätt bytas ut mot två billiga PEX4M2E1 eller motsvarande, som kan köpas var som helst för priser från 600 rubel.

Avståendet från alla möjliga hårdvaru- eller inbyggda chipset/BIO RAID:er gjordes medvetet, för att möjliggöra en fullständig ersättning av hela systemet, förutom själva SSD/HDD, samtidigt som alla data bevaras. Idéellt för att även kunna spara det installerade operativsystemet vid flytt till helt ny/annat hårdvara. Huvudsakligen att det finns SATA- och PCIe-portar. Det är som en live CD eller bootbar USB, bara mycket snabbare och lite mer skrymmande.

HumorFör som ni vet, ibland måste man snabbt ta hela arrayen med sig. Och man vill inte förlora data. För detta ändamål är alla nämnda lagringsmedia smart placerade i hållare i standard 5.25 chassi.

Självklart för experiment med olika metoder för SSD-cache i Linux.

Hårdvaru-RAID är tråkigt. Sätter på det. Det fungerar eller inte. Men med mdadm finns det alltid alternativ.

Programvara

Tidigare var Debian 8 Jessie installerat på hårdvaran som är nära EOL. En RAID 6 byggdes med de ovan nämnda HDD:erna i par med LVM. På den kördes virtuella maskiner i kvm/libvirt.

Eftersom författaren har rätt erfarenhet av att skapa bärbara startbara SATA/NVMe flashenheter och för att inte förstöra den vanliga apt-mallen, valdes Ubuntu 18.04 som målsystem, som redan har stabiliserat sig tillräckligt men fortfarande har tre års support kvar.

I det nämnda systemet finns alla nödvändiga drivrutiner för hårdvaran direkt från början. Ingen tredje parts programvara eller drivrutiner kommer att behövas.

Förberedelse för installation

För att installera systemet behöver vi Ubuntu Desktop Image. Den serverversionen har en ganska komplicerad installerare som visar en överdriven och icke-avstängd självständighet genom att alltid installera UEFI-systempartitionen på en av diskarna, vilket förstör hela estetiken. Därför installeras det bara i UEFI-läge. Det finns inga andra alternativ.

Det här är oacceptabelt för oss.

Varför?Tyvärr är UEFI-booting extremt dåligt kompatibel med mjukvarubaserad RAID, eftersom ingen erbjuder reservutrymme för UEFI ESP-partitionen. Det finns recept på nätet som föreslår att placera ESP-partitionen på en flashenhet i USB-porten, men detta är en felpunkt. Det finns också recept som använder mjukvarubaserad mdadm RAID 1 med metadata version 0.9 som inte hindrar UEFI BIOS från att se den här partitionen, men detta håller bara tills det lyckosamma ögonblicket då BIOS eller ett annat operativsystem på hårdvaran skriver något till ESP utan att synkronisera med de andra speglarna.

Dessutom beror UEFI-booting på NVRAM, som inte flyttas tillsammans med diskarna till det nya systemet, eftersom den är en del av moderkortet.

Så vi kommer inte att uppfinna den nya cykeln. Vi har redan en färdig, beprövad gammaldags cykel som nu kallas Legacy/BIOS boot, som har det stolta namnet CSM på UEFI-kompatibla system. Vi tar bara ner den från hyllan, smörjer den, pumpar däcken och torkar av den med en fuktig trasa.

Desktop-versionen av Ubuntu klarar inte att installeras korrekt med Legacy-bootloadern, men här finns åtminstone alternativ.

Så vi samlar ihop hårdvaran och laddar systemet från en startbar flashenhet med Ubuntu Live. Vi kommer att behöva ladda ner paket, så vi ställer in nätverket, vilket som helst fungerar. Om det inte fungerar kan de nödvändiga paketen laddas ner i förväg till flashenheten.

Vi går in i Desktop-miljön, öppnar terminalemulatorn, och så kör vi:

#sudo bash

Hur…?Raden ovan är en kanonisk utlösare för debatter om sudo. Med bbästa resultatet (subjektiv åsikt).Större möjligheter kommer med ettbästa resultatet (subjektiv åsikt).större ansvar. Frågan är om du kan ta det på dig. Många anser att användningen av sudo på det sättet är, åtminstone oansvarigt. Men:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

Varför inte ZFS…?När vi installerar programvara på vår dator, i grund och botten lånar vi ut vår hårdvara till utvecklarna av denna programvara.
När vi litar på denna programvara med att skydda våra data, tar vi i skuld en kostnad motsvarande återställningen av dessa data, som vi en dag måste betala.

Ur den synvinkeln är ZFS en Ferrari, medan mdadm+lvm mer liknar en cykel.

Subjektivt föredrar författaren att låna en okänd person en kreditcykel istället för en Ferrari. Priset är lågt. Inga rättigheter krävs. Enklare vägtrafikregler. Parkering är gratis. Framkomligheten är bättre. Man kan alltid fästa ben på cykeln, och man kan även reparera cykeln själv.

Varför då BTRFS…?För att ladda operativsystemet behöver vi ett filsystem som stöds av Legacy/BIOS GRUB från början, och som dessutom stödjer snapshots i realtid. Vi kommer att använda det för ⁄boot-partitionen. Dessutom föredrar författaren att använda detta filsystem för ⁄ (roten) utan att glömma att det för annan programvara kan skapas separata partitioner på LVM och monteras i de nödvändiga katalogerna.

Varken bilder virtuella maskinereller databaser kommer vi att lagra på detta filsystem.
Detta filsystem kommer endast att användas för att skapa ögonblicksbilder av systemet utan att stänga av det, följt av att dessa ögonblicksbilder överförs till en säkerhetsdisk med hjälp av send/receive.

Dessutom föredrar författaren oftast att hålla så lite programvara som möjligt direkt på hårdvaran och köra all annan mjukvara i virtuella maskiner med hjälp av hållare för GPU och PCI-USB-värdkontrollrar i KVM via IOMMU.

På hårdvaran finns endast lagring av data, virtualisering och säkerhetskopiering kvar.

Om du litar mer på ZFS, är de i princip utbytbara för det angivna användningsområdet.

Trots detta ignorerar författaren medvetet de inbyggda funktionerna för spegling ⁄ RAID och redundans som finns i ZFS, BTRFS och LVM.

Som ett ytterligare argument har BTRFS egenskapen att omvandla slumpmässiga skrivningar till sekventiella, vilket har en mycket positiv inverkan på hastigheten för synkronisering av snapshots / säkerhetskopior på HDD.

Vi skannar om alla enheter:

#udevadm control --reload-rules && udevadm trigger

Vi ser oss omkring:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Modell Namespace Användning Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


Partitionering av "diskar"

NVMe SSD

Men vi kommer inte att partitionera dem. Vår BIOS ser ändå inte dessa enheter. Så de går helt in i mjukvaru-RAID. Vi kommer inte ens att skapa några partitioner där. Om man vill göra det "enligt kanon" eller "principiellt" – skapa en stor partition, precis som för HDD.

SATA HDD

Här behöver vi inte uppfinna något nytt. Vi kommer att skapa en partition för allt. Vi skapar en partition eftersom dessa diskar syns i BIOS och det kan till och med försöka starta från dem. Vi kommer även senare att installera GRUB på dessa diskar så att systemet oväntat kan starta.

#cat >hdd.part << EOF
etikett: dos
etikett-id: 0x00000000
enhet: /dev/sdg
enhet: sektorer

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part

SATA SSD

Här är det mest intressant.

För det första har våra enheter en storlek på 2 TB. Detta ligger inom gränserna för MBR, vilket vi kommer att dra nytta av. Om nödvändigt kan det bytas ut mot GPT. GPT-diskar har ett kompatibilitetslager som gör att MBR-kompatibla system kan se de första 4 partitionerna om de ligger inom de första 2 terabyterna. Det viktigaste är att den startande partitionen och partitionen bios_grub på dessa diskar ligger i början. Detta gör det till och med möjligt att göra Legacy/BIOS-start från GPT-diskar.

Men det är inte vårt fall.

Här kommer vi att skapa två partitioner. Den första kommer att vara 1 GB stor och användas för RAID 1 /boot.

Den andra kommer att användas för RAID 6 och ta upp allt kvarvarande ledigt utrymme förutom ett litet icke-partionerat område i slutet av lagringsenheten.

Vad är det för icke-partionerat område?Enligt källor på nätet har våra SATA SSD:er en dynamiskt utökad SLC-cache på mellan 6 och 78 gigabyte. 6 gigabyte får vi "kostnadsfritt" på grund av skillnaden mellan "gigabyte" och "gibibyte" i lagringsenhetens datablad. De andra 72 gigabyten tilldelas på grund av outnyttjat utrymme.

Här bör det noteras att cachen är SLC och utrymmet används i 4 bit MLC-läge. Det som effektivt innebär för oss är att för varje 4 gigabyte ledigt utrymme får vi bara 1 gigabyte SLC-cache.

Vi multiplicerar 72 gigabyte med 4 och får 288 gigabyte. Detta är det lediga utrymme som vi inte kommer att partitionera för att låta enheterna fullt utnyttja SLC-cachen.

På så sätt får vi effektivt upp till 312 gigabyte SLC-cache totalt från sex lagringsenheter. Av alla lagringsenheter kommer 2 att användas i RAID för redundans.

Denna mängd cache kommer att göra att vi sällan stöter på situationer där skrivningar inte går via cachen. Detta kompenserar extremt bra för den mest nedslående nackdelen med QLC-minne – den extremt låga skrivhastigheten när data skrivs utan att passera cachen. Om dina belastningar inte överensstämmer med detta rekommenderar jag att du noga överväger hur länge dina SSD:er kommer att klara en sådan belastning med hänsyn till TBW i specifikationen.

#cat >ssd.part << EOF
etikett: dos
etikett-id: 0x00000000
enhet: /dev/sda
enhet: sektorer

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part

Skapande av enheter

Först behöver vi döpa om maskinen. Detta är nödvändigt eftersom värdnamnet är en del av namnet på enheten någonstans i mdadm och påverkar något. Enheter kan självklart döpas om senare, men det är onödiga åtgärder.

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

Varför –assume-clean…?För att inte initiera enheterna. För båda RAID-nivåerna 1 och 6 är detta acceptabelt. Allt kan fungera utan initiering om det är en ny enhet. Dessutom är initiering av SSD-enheter vid skapandet en slöseri med TBW-resurser. Vi använder TRIM/DISCARD där det är möjligt på de sammansatta SSD-enheterna för att "initiera" dem.

För SSD RAID 1 stöds DISCARD ur lådan.

För SSD RAID 6 måste DISCARD aktiveras i kärnmodulens inställningar.

Detta bör göras endast om alla SSD-enheter som används i nivåer 4/5/6 i detta system har fungerande stöd för discard_zeroes_data. Ibland dyker det upp konstiga enheter som rapporterar till kärnan att de stödjer denna funktion, men i verkligheten gör de det inte, eller funktionen fungerar inte alltid. För närvarande finns det praktiskt taget stöd överallt, men äldre enheter och felaktiga firmwareversioner förekommer. Av denna anledning är DISCARD-stödet som standard inaktiverat för RAID 6.

Observera, nästa kommando kommer att förstöra all data på NVMe-enheterna genom att "initiera" enheten med "nollor".

#blkdiscard /dev/md0

Om något går fel, försök ange steg.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

Varför så stor…?Ökningen av chunk-storleken påverkar hastigheten för slumpmässig läsning av block upp till och med chunk-storleken. Detta sker eftersom en operation av motsvarande storlek eller mindre kan utföras helt på en enhet. Därför summeras IOPS från alla enheter. Enligt statistik överskrider 99% av IO inte 512K.

I RAID 6 är IOPS för skrivning alltid mindre eller lika med IOPS för en enda enhet. Vid slumpmässig läsning kan IOPS vara högre än för en enda enhet flera gånger, och här är blockstorleken avgörande.
Författaren ser ingen mening i att försöka optimera en parameter som är dålig för RAID 6 enligt design, och istället optimerar vad RAID 6 gör bra.
Den dåliga slumpmässiga skrivningen av RAID 6 kommer vi att kompensera med cache på NVMe och tricks med thin-provisioning.

Vi har ännu inte aktiverat DISCARD för RAID 6. Så vi kommer inte att "initiera" denna array ännu. Vi gör det senare, efter operativsystemets installation.

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

LVM på NVMe RAID

För hastighet vill vi placera rotfilsystemet på NVMe RAID 1 som /dev/md0.
Denna snabba array kommer vi dock fortfarande behöva för andra behov, såsom swap, metdata och LVM-cache samt metdata för LVM-thin, därför kommer vi att skapa en LVM VG på denna array.

#pvcreate /dev/md0
#vgcreate root /dev/md0

Vi skapar en partition för rotfilsystemet.

#lvcreate -L 128G --name root root

Vi skapar en partition för swap som är i storlek med RAM-minnet.

#lvcreate -L 32G --name swap root

Installation av OS

Sammantaget har vi allt som behövs för att installera systemet.

Vi startar installationsguiden från Ubuntu Live-miljön. Vanlig installation. Endast under valet av diskar för installation måste vi ange följande:

• /dev/md1, — точка монтирования /boot, ФС — BTRFS
• /dev/root/root (a.k.a /dev/mapper/root-root), — точка монтирования / (корень), ФС — BTRFS
• /dev/root/swap (a.k.a /dev/mapper/root-swap), — использовать как раздел подкачки
• Installera bootloader på /dev/sda

När BTRFS väljs som rotfilsystem kommer installationsprogrammet automatiskt att skapa två BTRFS-volymer med namnen "@" för / (rot) och "@home" för /home.

Vi startar installationen…

Installationen kommer att avslutas med en modal dialog som meddelar om ett bootloader installationsfel. Tyvärr, blir det inte möjligt att stänga dialogen på vanligt sätt och fortsätta installationen. Logga ut från systemet och logga in igen, för att hamna på skrivbordet för Ubuntu Live. Öppna terminalen, och återigen:

#sudo bash

Vi skapar en chroot-miljö för att fortsätta installationen:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

Låt oss konfigurera nätverket och värdnamnet i chroot:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

Vi går in i chroot-miljön:

#chroot /mnt/chroot

Först installerar vi paketen:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

Vi kontrollerar och åtgärdar alla paket som har installerats felaktigt på grund av en ofullständig systeminstallation:

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

Om något gick snett kan det hända att du först behöver redigera /etc/apt/sources.list

Vi justerar inställningarna för RAID 6-modulen för att aktivera TRIM/DISCARD:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

Vi justerar lite av våra arrayer:

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

Vad var det..?Vi har skapat en uppsättning udev-regler som kommer att göra följande:

• Ställ in en adekvat cachestorlek för RAID 6 för år 2020. Standardvärdet verkar inte ha ändrats sedan Linux skapades och är sedan länge otillräckligt.
• Reservera minst IO under kontroller/synkronisering av arrayerna. Detta är nödvändigt för att förhindra att dina arrayer fastnar i ett tillstånd av evig synkronisering under belastning.
• Begränsa maximalt IO under kontroller/synkronisering av arrayerna. Detta är viktigt för att synkronisering/kontroll av SSD RAID inte ska överhetta dina lagringsenheter. Särskilt viktigt för NVMe. (Kommer du ihåg kylflänsen? Jag skämtade inte.)
• Förhindra att diskarna stoppar spinnandet av spindeln (HDD) via APM och ställ in en sömntimeout för diskens kontroller på 7 timmar. Du kan helt stänga av APM om dina diskar stödjer det (-B 255). Med standardvärdet kommer diskarna att stängas av efter fem sekunder. Därefter vill operativsystemet återställa diskens cache, diskarna kommer att snurra igen, och processen börjar om. Diskar har ett begränsat maximalt antal snurrningar av spindeln. Denna enkla cykel som är standard kan lätt döda dina diskar på några år. Detta drabbar inte alla diskar, men våra
• Ställ in readahead på snurrande diskar till 1 megabyte - två sekventiella block/chunk RAID 6
• Förhindra readahead på själva arrayerna.

Låt oss redigera /etc/fstab:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
Varför så..?Vi kommer att söka efter partitionen /boot via UUID eftersom namnen på arrayerna teoretiskt kan ändras.

Vi kommer att söka efter övriga partitioner via LVM-namn i formatet /dev/mapper/vg-lv, eftersom de identifierar partitionerna tillräckligt unikt.

Vi använder inte UUID för LVM eftersom UUID för LVM-volymer och deras snapshotar kan överlappa.Mountar vi /dev/mapper/root-root två gånger..?Ja. Precis så. Detta är en egenskap hos BTRFS. Detta filsystem kan monteras flera gånger med olika subvol.

Med anledning av denna egenskap rekommenderar jag att aldrig skapa LVM-snapshotar av aktiva BTRFS-volymer. Du kan få en överraskning vid omstart.

Vi regenererar konfigurationen för mdadm:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

Vi justerar inställningarna för LVM:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"]
issue_discards=1}
}
EOF

Vad var det..?Vi har aktiverat automatisk utvidgning av LVM thin-pooler när 90 % av utrymmet är upptaget med 5 % av volymen.

Vi har ökat det maximala antalet cacheblock för LVM-cache.

Vi har förhindrat LVM från att söka efter LVM-volymer (PV) på:

• enheter som innehåller LVM-cache (cdata)
• enheter som är cachelagrade med LVM-cache förbi cachen (<lv_name>_corig). Den cachelagrade enheten kommer ändå att skannas genom cache (bara <lv_name>).
• enheter som innehåller metadata för LVM-cache (cmeta)
• alla enheter i VG med namnet images. Här kommer vi att ha avbilder av virtuella maskiners diskar, och vi vill inte att LVM på värden aktiverar volymer som tillhör gästoperativsystemet.
• alla enheter i VG med namnet backup. Här kommer vi att ha säkerhetskopior av avbilder av virtuella maskiner.
• alla enheter vars namn slutar med "gpv" (guest physical volume)

Vi har aktiverat DISCARD-stöd när vi frigör ledigt utrymme på LVM VG. Var försiktig. Detta kommer att göra borttagning av LV på SSD ganska långsam. Särskilt gäller detta SSD RAID 6. Men enligt planen kommer vi att använda thin provisioning, så det här kommer inte att hindra oss.

Vi uppdaterar initramfs-avbilden:

#update-initramfs -u -k all

Vi installerar och konfigurerar grub:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

Vilka diskar ska vi välja?Alla som sd*. Systemet ska kunna starta från vilken fungerande SATA-disk eller SSD som helst.

Varför har vi dödat os-prober..?För överdriven självständighet och nyfikenhet.

Det fungerar inte korrekt om någon av RAID:erna är i ett degraderat tillstånd. Det försöker söka efter OS på partitioner som används i virtuella maskiner som körs på denna hårdvara.

Om du behöver det kan du låta det vara, men tänk på allt ovanstående. Jag rekommenderar att du söker efter lösningar för att bli av med nyfikenheten på nätet.

Härmed avslutar vi den ursprungliga installationen. Det är dags att starta om till det nyinstallerade operativsystemet. Glöm inte att ta bort den bootbara Live CD/USB:n.

#exit
#reboot

Som boot-enhet väljer vi vilken som helst av SATA SSD.

LVM på SATA SSD

Vid det här laget har vi redan startat upp till det nya operativsystemet, konfigurerat nätverket, apt, öppnat terminalemulatorn och kört:

#sudo bash

Vi fortsätter.

Vi "initialiserar" matrisen av SATA SSD:

#blkdiscard /dev/md2

Om det inte fungerar, försök:

#blkdiscard --step 65536 /dev/md2
Vi skapar LVM VG på SATA SSD:

#pvcreate /dev/md2
#vgcreate data /dev/md2

Varför ytterligare en VG..?Vi har redan en VG med namnet root. Varför inte lägga till allt i en VG?

Om det finns flera PV i VG måste alla PV vara närvarande (online) för att VG ska aktiveras korrekt. Undantaget är LVM RAID, som vi avsiktligt inte använder.

Vi vill verkligen att när det sker ett fel (läs dataloss) i någon av RAID 6-arrayerna, så att operativsystemet laddas som det ska och ger oss möjlighet att lösa problemet.

För detta syfte kommer vi på den första abstraheringsnivån att isolera varje typ av fysisk "bärare" i en separat VG.

Om vi pratar vetenskapligt, så tillhör olika RAID-arrayer olika "pålitlighetsområden". Det är inte bra att skapa en ytterligare gemensam felpunkt för dem genom att stoppa dem i en VG.

Att ha LVM på "hårdvarunivå" kommer att göra det möjligt för oss att dela upp olika RAID-arrayer på olika sätt genom att kombinera dem. Till exempel, att köra samtidigt bcache + LVM thin, bcache + BTRFS, LVM cache + LVM thin, en komplex ZFS-konfiguration med cachar eller vilken annan hemsk kombination som helst, för att prova och jämföra allt detta.

På "hårdvarunivå" kommer vi inte att använda något annat än de gamla goda "tjocka" LVM-volymerna. Undantaget från denna regel kan möjligen vara partitionen för säkerhetskopiering.

Jag tror att många läsare har börjat misstänka något angående matryoshkan vid det här laget.

LVM på SATA HDD

#pvcreate /dev/md3
#vgcreate backup /dev/md3

Ännu en ny VG..?Vi vill verkligen att när diskarrayen som vi kommer att använda för att säkerhetskopiera data går ner, så ska vårt operativsystem fortsätta att fungera som det ska, med fortsatt tillgång till icke-säkerhetskopierade data. Därför, för att undvika problem med aktiveringen av VG, skapar vi en separat VG.

Inställning av LVM-cache

Vi skapar en LV på NVMe RAID 1 för att använda den som en cachande enhet.

#lvcreate -L 70871154688B --name cache root

Varför så lite…?Det handlar om att våra NVMe SSD:er också har SLC-cache. 4 gigabyte "gratis" och 18 gigabyte dynamiskt på grund av det lediga utrymmet som upptas i 3-bit MLC. När denna cache har uttömts kommer NVMe SSD:er att vara inte mycket snabbare än våra SATA SSD:er med cache. Just därför finns det ingen mening med att göra LVM-cachepartitionen mycket större än dubbla storleken på NVMe-lagringens SLC-cache. För de använda NVMe-lagringarna anser författaren att det är rimligt att göra en cache på 32-64 gigabyte.

Den angivna storleken på partitionen är nödvändig för att organisera 64 gigabyte cache, lagra cache-metadata och en backup av metadata.

Jag vill också nämna att efter en plötslig avstängning av systemet kommer LVM att märka hela cachen som smutsig och synkronisera den på nytt. Dessutom kommer detta att upprepas varje gång lvchange används på den här enheten fram till nästa omstart av systemet. Därför rekommenderar jag att genast återskapa cachen med hjälp av ett lämpligt skript.

Vi skapar ett LV på SATA RAID 6 för att använda det som en cachad enhet.

#lvcreate -L 3298543271936B --name cache data

Varför bara tre terabyte..?Så att SATA SSD RAID 6 kan användas för andra ändamål vid behov. Den cachade utrymmesstorleken kan ökas dynamiskt, på språng, utan att stänga av systemet. För detta behöver cachen tillfälligt stoppas och aktiveras igen, men en av de utmärkande fördelarna med LVM-cache framför bcache är att detta kan göras på språng.

Vi skapar en ny VG för caching.

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

Vi skapar ett LV på den cachade enheten.

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

Här har vi genast tagit upp allt ledigt utrymme på /dev/data/cache så att alla andra nödvändiga partitioner skapas direkt på /dev/root/cache. Om något skapades någon annanstans kan det flyttas med hjälp av pvmove.

Vi skapar och aktiverar cachen:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

Varför en sådan chunksize..?Genom praktiska experiment har författaren kommit fram till att bästa resultat uppnås om storleken på LVM-cachen överensstämmer med storleken på LVM thin-blocket. Samtidigt visar sig konfigurationen prestera bättre vid mindre blockstorlekar i samband med slumpmässiga skrivningar.

64k är den minimi blockstorlek som tillåts för LVM thin.

Var försiktig med writeback..!Ja. Denna typ av cache skjuter upp synkroniseringen av skrivningar till den cachade enheten. Detta innebär att vid förlust av cachen kan data gå förlorade på den cachade enheten. Senare kommer författaren att berätta vilka åtgärder, förutom NVMe RAID 1, som kan vidtas för att kompensera för denna risk.

Denna typ av cache har valts med avsikt för att kompensera för den låga prestandan hos RAID 6 vid slumpmässiga skrivningar.

Låt oss kontrollera vad vi har åstadkommit:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Enheter
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

På /dev/data/cache ska endast [cachedata_corig] placeras. Om något är fel, använd pvmove.

Cachen kan stängas av vid behov med ett enda kommando:

#lvconvert -y --uncache cache/cachedata

Detta görs online. LVM synkroniserar bara cachen till disken, tar bort den och döper om cachedata_corig tillbaka till cachedata.

Inställning av LVM thin

Vi gör en ungefärlig uppskattning av hur mycket utrymme vi behöver för metadata för LVM thin:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 byte uppskattad metadata områdesstorlek för "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

Vi rundar av till 4 gigabyte: 4294967296B

Vi multiplicerar med två och lägger till 4194304B för LVM PV metadata: 8594128896B
Vi skapar en separat partition på NVMe RAID 1 för att lagra LVM thin-metadata och dess säkerhetskopiering:

#lvcreate -L 8594128896B --name images root

Varför..?Här kan en fråga uppstå, varför lagra LVM thin-metadata separat, om de ändå kommer att cachas på NVMe och arbeta snabbt.

Även om hastighet är viktig, är det långt ifrån den huvudsakliga orsaken. Det handlar om att cachen är en enskild felpunkt. Något kan hända med den, och om LVM thin-metadata är cachade kan det leda till en total förlust av allt. Utan hela metadata blir det i princip omöjligt att återställa de tunna volymerna.

Genom att flytta metadata till en separat, icke-cachad men snabb volym, garanterar vi att metadata bevaras i händelse av förlust eller skada på cachen. I det här fallet kommer alla skador orsakade av cachförlust att lokaliseras inom de tunna volymerna, vilket avsevärt förenklar återställningsproceduren. Med stor sannolikhet kommer dessa skador att kunna återställas med hjälp av FS-loggar.

Dessutom, om en ögonblicksbild av den tunna volymen tidigare har tagits, och efter det har cachen en gång fullständigt synkroniserats, kommer integriteten av ögonblicksbilden att garanteras vid förlust av cachen, på grund av de interna egenskaperna hos LVM thin.

Vi skapar en ny VG som kommer att ansvara för thin-provisioning:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
Vi skapar en pool:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
Varför -Z yDessutom, för vad detta läge faktiskt är avsett — att förhindra att data från en virtuell maskin läcker till en annan vid omfördelning av utrymme — används zeroing också för att öka hastigheten för slumpmässiga skrivningar med block mindre än 64k. Varje skrivning mindre än 64k i ett tidigare icke-allokerat område av den tunna volymen kommer att omvandlas till 64K som är anpassade till cachegränsen. Detta gör att operationen kan utföras helt via cachen utan att passera den cachade enheten.

Vi flyttar LV till motsvarande PV:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

Låt oss kontrollera:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Enheter
[lvol0_pmspare] 4294967296B /dev/root/images(0)
tunneltank 274877906944B tunneltank_tdata(0)
[tunneltank_tdata] 274877906944B /dev/cache/cachedata(0)
[tunneltank_tmeta] 4294967296B /dev/root/images(1024)

Vi skapar en tunn volym för tester:

#lvcreate -V 64G --thin-pool thin-pool --name test images

Vi installerar paket för tester och övervakning:

#apt-get install sysstat fio

Så här kan vi övervaka beteendet hos vår lagringskonfiguration i realtid:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

Så här kan vi testa vår konfiguration:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

Varning! Resurs!Den här koden kommer att köra 36 olika tester, var och en av dem kommer att pågå i 4 sekunder. Hälften av testerna handlar om skrivning. Under 4 sekunder kan man skriva en hel del på NVMe. Upp till 3 gigabyte per sekund. Så varje körning av skrivtesterna kan använda upp till 216 gigabyte SSD-resurser.

Läsa och skriva på en gång?Ja. Det är meningsfullt att köra läsa- och skrivtester separat. Dessutom är det viktigt att se till att alla cache-minnen är synkroniserade, så att tidigare skrivningar inte påverkar läsningen.

Resultaten kommer att variera kraftigt vid första körningen jämfört med efterföljande körningar, beroende på cache-fyllning och tunna volymer, samt om systemet har lyckats synkronisera cachen som fylldes vid den föregående körningen.

Förutom detta rekommenderar jag att mäta hastigheten på en redan fylld tunn volym, som just fått en snapshot. Författaren har haft möjlighet att observera hur slumpmässig skrivning plötsligt ökar strax efter att den första snapshoten skapats, särskilt när cachen inte är helt fylld. Detta beror på copy-on-write-semantiken, blockutjämning av cache och den tunna volymen, och det faktum att slumpmässig skrivning på RAID 6 omvandlas till slumpmässig läsning med RAID 6 följt av skrivning till cache. I vår konfiguration är slumpmässig läsning på RAID 6 upp till 6 gånger (antalet SATA SSD i arrayen) snabbare än skrivning. Eftersom blocken för CoW tilldelas sekventiellt från den tunna poolen, omvandlas skrivningen för det mesta också till sekventiell.

Båda dessa funktioner kan nyttjas fördelaktigt.

Cache-'koherent' snapshots

För att minska risken för dataförlust vid skador/förlust av cache föreslår författaren att införa en praktik med rotation av snapshots som garanterar deras integritet i sådana fall.

För det första, tack vare att metadata för tunna volymer är placerade på ett icke-cacheat enhet, kommer metadata att vara intakt, och eventuella förluster kommer att isoleras inom datablokkarna.

Den följande rotationcykeln av snapshots garanterar dataintegritet inom snapshots i händelse av cacheförlust:

1. För varje tunn volym med namnet <namn> skapar vi en snapshot med namnet <namn>.cached
2. Låt oss sätta migrationsgränsen på ett rimligt högt värde: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. I cykeln kontrollerar vi antalet smutsiga block i cachen: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' tills vi får noll. Om nollan dröjer för länge kan den temporärt skapas genom att ställa om cachen till writethrough-läge. Men med tanke på hastighetskarakteristikerna hos våra SATA och NVMe SSD:er, samt deras TBW-resurs, kommer du antingen att kunna fånga ögonblicket ganska snabbt utan att ändra cacheläge, eller så kommer din hårdvara att förbruka hela sin resurs på bara några dagar. På grund av resursbegränsningar är systemet i princip oförmöget att vara under 100 % skrivbelastning konstant. Våra NVMe SSD:er kommer helt att förbruka sin resurs vid 100 % skrivbelastning 3-4 dagar. SATA SSD:er kommer att leva ungefär två gånger längre. Därför kommer vi att anta att den största delen av belastningen går på läsning, och att skrivningen ger relativt kortvariga toppar med extremt hög aktivitet i kombination med låg genomsnittlig belastning.
4. Så snart vi fångar (eller skapar) nollan – byt namn på <namn>.cached till <namn>.committed. Den gamla <namn>.committed tas bort.
5. Valfritt, om cachen är fylld till 100 %, kan den återskapas med ett skript, vilket på så sätt rensar den. Med en halvtom cache fungerar systemet mycket snabbare vid skrivning.
6. Vi ställer in migration threshold på noll: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata Detta kommer tillfälligt att förbjuda synkronisering av cachen till den primära enheten.
7. Vi väntar tills det finns tillräckligt många förändringar i cachen #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' eller timern går.
8. Vi upprepar processen.

Varför komplicera med migration threshold…?Saken är den att i verklig praktik är "slumptals"-skrivning faktiskt inte helt slumpmässig. Om vi har skrivit något till en sektor på 4 kilobyte, finns det en stor sannolikhet att det kommer att göras en skrivning till denna eller en av de närliggande (+- 32K) sektorerna inom några minuter.

Genom att ställa in migration threshold på noll skjuter vi upp synkroniseringen av skrivningen till SATA SSD:n och aggregerar flera förändringar av en 64K-block i cachen. På så sätt sparar vi betydligt på resursen för SATA SSD.

Men var är koden..?Tyvärr anser författaren att han inte är tillräckligt kompetent inom utvecklingen av bash-skript eftersom han är en 100 % självlärd och praktiserar "google"-driven utveckling, därför anser han att den skrämmande koden som kommer under hans händer inte bör användas av någon annan.

Jag tror att proffsen inom detta område själva kommer att kunna avbilda hela den ovan beskrivna logiken vid behov, och kanske till och med snyggt utforma det som en systemd-tjänst, som författaren försökte göra.

En enkel rotationsschema för snapshots gör att vi ständigt kan ha en fullt synkroniserad snapshot på SATA SSD, och med hjälp av verktyget thin_delta kan vi ta reda på vilka block som har ändrats efter att den skapades, och därmed lokalisera skador på de primära volymerna, vilket kraftigt förenklar återställningen.

TRIM/DISCARD i libvirt/KVM

Eftersom datalagret kommer att användas för KVM under libvirt, vore det bra att lära våra VM att inte bara ta upp ledigt utrymme utan också frigöra onödigt utrymme.

Detta görs genom att emulera stöd för TRIM/DISCARD på virtuella diskar. För att göra detta måste vi ändra kontrollerstypen till virtio-scsi och redigera xml.

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>