LVM nebezpečí a upozornění

Řešení 1:

Shrnutí

Rizika používání LVM:

• Chybí při zápisu problémů s mezipamětí pomocí SSD nebo hypervizoru VM
• Obnovení dat je obtížnější kvůli složitějším strukturám na disku
• Je těžší správně změnit velikost souborových systémů
• Snímky se obtížně používají, jsou pomalé a chybné
• Správná konfigurace vyžaduje určité dovednosti vzhledem k těmto problémům

První dva problémy s LVM se kombinují:pokud mezipaměť zápisu nefunguje správně a máte výpadek napájení (např. selže PSU nebo UPS), možná budete muset obnovit zálohu, což znamená značné prostoje. Klíčovým důvodem pro použití LVM je vyšší doba provozuschopnosti (při přidávání disků, změně velikosti souborových systémů atd.), ale je důležité správně nastavit ukládání do mezipaměti, aby LVM skutečně nezkrátilo dobu provozuschopnosti.

-- Aktualizováno prosinec 2019:menší aktualizace na btrfs a ZFS jako alternativy k snímkům LVM

Snížení rizik

LVM může stále dobře fungovat, pokud:

• Získejte nastavení mezipaměti pro zápis přímo v hypervisoru, jádře a SSD
• Vyhněte se snímkům LVM
• Ke změně velikosti souborových systémů použijte nejnovější verze LVM
• Mějte dobré zálohy

Podrobnosti

V minulosti jsem to docela dost zkoumal, protože jsem zažil nějakou ztrátu dat spojenou s LVM. Hlavní rizika a problémy LVM, kterých jsem si vědom, jsou:

Chybí ukládání do mezipaměti pro zápis na pevný disk kvůli hypervizorům virtuálních počítačů, ukládání do mezipaměti disku nebo starým linuxovým jádrům a ztěžuje obnovu dat kvůli složitějším strukturám na disku – podrobnosti viz níže. Viděl jsem, že se kompletní nastavení LVM na několika discích poškodila bez jakékoli šance na obnovu a LVM plus ukládání do mezipaměti pevného disku je nebezpečná kombinace.

• Zápis do mezipaměti a změna pořadí zápisu na pevném disku je důležitý pro dobrý výkon, ale může selhat při správném vyprázdnění bloků na disk kvůli hypervizorům VM, ukládání do mezipaměti pevného disku, starým linuxovým jádrům atd.
• Zápisové bariéry znamenají, že jádro zaručuje, že dokončí určité zápisy na disk před zápisem na disk s "bariérou", aby bylo zajištěno, že se souborové systémy a RAID mohou obnovit v případě náhlého výpadku napájení nebo havárie. Takové bariéry mohou použít operaci FUA (Force Unit Access) k okamžitému zápisu určitých bloků na disk, což je efektivnější než úplné vyprázdnění mezipaměti. Bariéry lze zkombinovat s efektivním řazením tagovaných/nativních příkazů (vydáváním více diskových vstupně-výstupních požadavků najednou), aby pevný disk mohl provádět inteligentní změnu pořadí zápisu bez zvýšení rizika ztráty dat.
• Hypervizory VM může mít podobné problémy:spuštění LVM v hostu Linuxu nad hypervizorem VM, jako je VMware, Xen, KVM, Hyper-V nebo VirtualBox, může způsobit podobné problémy jako jádro bez bariér zápisu, kvůli ukládání do mezipaměti a přeskupování zápisu . Pečlivě zkontrolujte dokumentaci svého hypervizoru, zda neobsahuje možnost „vyprázdnění na disk“ nebo mezipaměť pro zápis (přítomná v KVM, VMware, Xen, VirtualBox a dalších) – a otestujte ji pomocí svého nastavení. Některé hypervizory, jako je VirtualBox, mají výchozí nastavení, které ignoruje jakékoli vyprázdnění disku od hosta.
• Podnikové servery s LVM by měly vždy používat řadič RAID zálohovaný baterií a zakažte ukládání do mezipaměti zápisu na pevný disk (řadič má mezipaměť pro zápis zálohovanou baterií, která je rychlá a bezpečná) - viz tento komentář od autora tohoto záznamu XFS FAQ. Může být také bezpečné vypnout bariéry proti zápisu v jádře, ale doporučuje se testování.
• Pokud nemáte řadič RAID zálohovaný baterií, deaktivace ukládání do mezipaměti pevného disku výrazně zpomalí zápisy, ale zajistí bezpečnost LVM. Měli byste také použít ekvivalent data=ordered ext3 možnost (nebo data=journal pro větší bezpečnost) plus barrier=1 aby bylo zajištěno, že ukládání do mezipaměti jádra neovlivní integritu. (Nebo použijte ext4, který ve výchozím nastavení povoluje bariéry.) Toto je nejjednodušší možnost a poskytuje dobrou integritu dat za cenu výkonu. (Linux změnil výchozí možnost ext3 na nebezpečnější data=writeback před časem, takže se nespoléhejte na výchozí nastavení pro FS.)
• Zakázat ukládání do mezipaměti zápisu na pevný disk :přidejte hdparm -q -W0 /dev/sdX pro všechny disky v /etc/rc.local (pro SATA) nebo použijte sdparm pro SCSI/SAS. Nicméně podle tohoto záznamu v XFS FAQ (který je na toto téma velmi dobrý) může SATA disk toto nastavení zapomenout po zotavení z chyby disku - takže byste měli použít SCSI/SAS, nebo pokud musíte použít SATA, vložte příkaz hdparm v úloze cron běžící přibližně každou minutu.
• Chcete-li zachovat povolenou mezipaměť zápisu na SSD / pevný disk pro lepší výkon:toto je složitá oblast – viz část níže.
• Pokud používáte jednotky s pokročilým formátováním tj. 4 kB fyzické sektory, viz níže – deaktivace ukládání do mezipaměti může mít jiné problémy.
• UPS je kritický jak pro podniky, tak pro SOHO, ale nestačí k tomu, aby byl LVM bezpečný:cokoli, co způsobí vážné selhání nebo ztrátu napájení (např. selhání UPS, PSU nebo vybití baterie notebooku), může ztratit data v mezipaměti pevného disku.
• Velmi stará linuxová jádra (2.6.x z roku 2009) :Ve velmi starých verzích jádra 2.6.32 a dřívějších je neúplná podpora bariéry proti zápisu (2.6.31 má určitou podporu, zatímco 2.6.33 funguje pro všechny typy cílových zařízení) - RHEL 6 používá 2.6.32 s mnoha záplatami. Pokud tato stará jádra 2.6 nejsou pro tyto problémy opravena, může dojít ke ztrátě velkého množství metadat FS (včetně žurnálů) při selhání pevného disku, který zanechá data v zapisovacích vyrovnávací paměti pevných disků (řekněme 32 MB na disk pro běžné disky SATA). Ztráta 32 MB naposledy zapsaných metadat FS a dat žurnálu, o kterých si jádro myslí, že jsou již na disku, obvykle znamená velké poškození FS a tím i ztrátu dat.
• Shrnutí: musíte dávat pozor na souborový systém, RAID, VM hypervisor a nastavení pevného disku/SSD používané s LVM. Pokud používáte LVM, musíte mít velmi dobré zálohy a nezapomeňte konkrétně zálohovat metadata LVM, nastavení fyzického oddílu, MBR a zaváděcí sektory svazku. Je také vhodné používat jednotky SCSI/SAS, protože je méně pravděpodobné, že budou lhát o tom, jak provádějí ukládání do mezipaměti zápisu – použití disků SATA vyžaduje větší opatrnost.

Uchování mezipaměti zápisu zapnuté pro výkon (a vypořádání se s lžícími jednotkami)

Složitější, ale výkonnější možností je ponechat povolenou mezipaměť zápisu na SSD / pevný disk a spoléhat se na bariéry zápisu jádra fungující s LVM v jádře 2.6.33+ (zkontrolujte to tak, že v protokolech vyhledáte „bariérové“ zprávy).

Měli byste se také ujistit, že nastavení RAID, nastavení hypervizoru virtuálního počítače a souborový systém používají bariéry proti zápisu (tj. vyžaduje, aby disk vyprázdnil čekající zápisy před a po klíčových metadatech/zápisech do deníku). XFS standardně používá bariéry, ale ext3 ne, takže s ext3 byste měli použít barrier=1 v možnostech připojení a stále používejte data=ordered nebo data=journal jako výše.

• Některé pevné disky a SSD bohužel lžou o tom, zda skutečně vyprázdnily mezipaměť na disk (zejména starší disky, ale včetně některých SATA disků a některých podnikových SSD) - více podrobností zde. Existuje skvělé shrnutí od vývojáře XFS.
• Existuje jednoduchý testovací nástroj pro lživé disky (skript Perl), nebo si toto pozadí prohlédněte s jiným nástrojem, který testuje změnu pořadí zápisu v důsledku mezipaměti disku. Tato odpověď zahrnovala podobné testování disků SATA, které odhalilo problém s bariérou zápisu v softwarovém RAID – tyto testy ve skutečnosti procvičují celý zásobník úložiště.
• U novějších disků SATA podporujících Native Command Queuing (NCQ) je méně pravděpodobné, že budou lhát – nebo možná fungují dobře bez ukládání do mezipaměti kvůli NCQ a jen velmi málo disků nedokáže zakázat ukládání do mezipaměti.
• Disky SCSI/SAS jsou obecně v pořádku, protože nepotřebují ukládání do mezipaměti, aby fungovaly dobře (prostřednictvím SCSI Tagged Command Queuing, podobně jako NCQ SATA).
• Pokud vaše pevné disky nebo SSD lžou o vyprázdnění mezipaměti na disk, opravdu se nemůžete spoléhat na bariéry zápisu a musíte ukládání do mezipaměti zakázat. To je problém pro všechny souborové systémy, databáze, správce svazků a softwarový RAID, nejen LVM.

SSD jsou problematické, protože použití mezipaměti pro zápis je rozhodující pro životnost SSD. Nejlepší je použít SSD, který má superkondenzátor (pro umožnění vyprázdnění mezipaměti při výpadku napájení, a tím umožnit zpětný zápis, nikoli zápis).

• Většina podnikových SSD by měla být v pořádku při řízení mezipaměti zápisu a některé obsahují superkondenzátory.
• Některé levnější SSD mají problémy, které nelze vyřešit konfigurací mezipaměti zápisu – dobrými zdroji informací jsou mailing list projektu PostgreSQL a wiki stránka Reliable Writes. SSD pro spotřebitele mohou mít velké problémy s mezipamětí zápisu, které způsobí ztrátu dat, a neobsahují superkondenzátory, takže jsou náchylné k výpadkům napájení, které způsobí poškození.

Pokročilý formát nastavení disku – ukládání do mezipaměti zápisu, zarovnání, RAID, GPT

• U novějších jednotek Advanced Format, které používají fyzické sektory o velikosti 4 kB, může být důležité ponechat mezipaměť zápisu jednotky povolenou, protože většina takových jednotek v současnosti emuluje 512 bajtové logické sektory ("emulace 512") a některé dokonce tvrdí, že mají 512 -byte fyzických sektorů při skutečném použití 4 kB.
• Vypnutí mezipaměti pro zápis na disku s pokročilým formátováním může způsobit velmi velký dopad na výkon, pokud aplikace/jádro provádí 512 bajtové zápisy, protože takové disky spoléhají na to, že mezipaměť nashromáždí 8 x 512 bajtů zápisu před provedením jediného Fyzický zápis 4 kB. Pokud mezipaměť zakážete, doporučujeme provést testování, abyste potvrdili jakýkoli dopad.
• Zarovnání LV na hranici 4 kB je důležité pro výkon, ale mělo by se dít automaticky, pokud jsou základní oddíly pro PV zarovnány, protože LVM Physical Extents (PE) jsou ve výchozím nastavení 4 MiB. Zde je třeba vzít v úvahu RAID – tato stránka nastavení LVM a softwarového RAID doporučuje umístit superblok RAID na konec svazku a (v případě potřeby) použít volbu pvcreate k zarovnání PV. Toto vlákno e-mailového seznamu LVM poukazuje na práci vykonanou v jádrech během roku 2011 a na problém částečných blokových zápisů při míchání disků s 512 bajty a 4 KiB sektory v jednom LV.
• Rozdělení GPT pomocí Advanced Format vyžaduje péči, zejména u boot+root disků, aby bylo zajištěno, že první oddíl LVM (PV) začíná na hranici 4 kB.

Obnovení dat je obtížnější kvůli složitějším strukturám na disku :

• Jakákoli obnova dat LVM vyžadovaná po vážném selhání nebo ztrátě napájení (kvůli nesprávnému ukládání do mezipaměti) je v nejlepším případě ruční proces, protože zjevně neexistují žádné vhodné nástroje. LVM je dobrý v zálohování svých metadat pod /etc/lvm , který může pomoci obnovit základní strukturu LV, VG a PV, ale nepomůže se ztracenými metadaty souborového systému.
• Proto bude pravděpodobně nutné úplné obnovení ze zálohy. To zahrnuje mnohem více prostojů než rychlé fsck založené na žurnálu, když nepoužíváte LVM, a data zapsaná od poslední zálohy budou ztracena.
• TestDisk, ext3grep, ext3undel a další nástroje mohou obnovit oddíly a soubory z disků jiných než LVM, ale přímo nepodporují obnovu dat LVM. TestDisk dokáže zjistit, že ztracený fyzický oddíl obsahuje LVM PV, ale žádný z těchto nástrojů nerozumí logickým svazkům LVM. Nástroje pro vyřezávání souborů, jako je PhotoRec a mnoho dalších, by fungovaly, protože by obcházely souborový systém a znovu sestavovaly soubory z datových bloků, ale toto je poslední možnost, nízkoúrovňový přístup pro cenná data a funguje méně dobře s fragmentovanými soubory.
• Manuální obnova LVM je v některých případech možná, ale je složitá a časově náročná – viz tento příklad a tento, tento a tento, jak obnovit.

Správná změna velikosti souborových systémů je obtížnější - snadná změna velikosti souborového systému je často uváděna jako výhoda LVM, ale pro změnu velikosti FS založeného na LVM je potřeba spustit půl tuctu příkazů shellu - to lze provést, když je celý server stále zapnutý a v některých případech s připojeným FS, ale to druhé bych nikdy neriskoval bez aktuálních záloh a použití příkazů předem otestovaných na ekvivalentním serveru (např. klon obnovy po havárii produkčního serveru).

• Aktualizace: Novější verze lvextend podporují -r (--resizefs ) – pokud je k dispozici, je to bezpečnější a rychlejší způsob změny velikosti LV a souborového systému, zvláště pokud zmenšujete FS a tuto sekci můžete většinou přeskočit.

• Většina návodů na změnu velikosti FS založených na LVM nebere v úvahu skutečnost, že FS musí být o něco menší než velikost LV:podrobné vysvětlení zde. Při zmenšování souborového systému budete muset zadat novou velikost nástroje pro změnu velikosti FS, např. resize2fs pro ext3 a na lvextend nebo lvreduce . Bez velké péče se velikosti mohou mírně lišit kvůli rozdílu mezi 1 GB (10^9) a 1 GiB (2^30) nebo způsobu, jakým různé nástroje zaokrouhlují velikosti nahoru nebo dolů.

• Pokud neprovedete výpočty přesně (nebo použijete nějaké další kroky nad rámec těch nejzřejmějších), můžete skončit s FS, který je pro LV příliš velký. Všechno se bude zdát v pořádku měsíce nebo roky, dokud FS úplně nenaplníte, v tu chvíli dojde k vážnému poškození - a pokud si nejste vědomi tohoto problému, je těžké zjistit proč, protože do té doby můžete mít také skutečné chyby na disku. které zatemňují situaci. (Je možné, že tento problém ovlivní pouze zmenšení velikosti souborových systémů – je však jasné, že změna velikosti souborových systémů v obou směrech zvyšuje riziko ztráty dat, pravděpodobně kvůli chybě uživatele.)

• Zdá se, že velikost LV by měla být větší než velikost FS o 2 x velikost fyzického rozsahu LVM (PE) - ale podrobnosti najdete ve výše uvedeném odkazu, protože zdroj není směrodatný. Často stačí povolit 8 MiB, ale může být lepší povolit více, např. 100 MiB nebo 1 GiB, jen pro jistotu. Chcete-li zkontrolovat velikost PE a váš logický svazek + velikosti FS pomocí bloků 4 KiB =4096 bajtů:

  Zobrazuje velikost PE v kiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Velikost všech LV:
  lvs --units 4096b
  
  Velikost (ext3) FS, předpokládá velikost bloku 4 kB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Naproti tomu nastavení bez LVM dělá změnu velikosti FS velmi spolehlivou a snadnou - spusťte Gparted a změňte velikost požadovaných FS, pak udělá vše za vás. Na serverech můžete použít parted ze skořápky.

• Často je nejlepší použít Gparted Live CD nebo Parted Magic, protože tyto mají nedávné a často bezchybnější jádro Gparted &než distro verze - jednou jsem ztratil celý FS kvůli tomu, že Gparted distribuce neaktualizoval správně oddíly během běhu jádro. Pokud používáte Gparted distribuce, ujistěte se, že restartujete hned po změně oddílů, aby byl pohled jádra správný.

Snímky se obtížně používají, jsou pomalé a chybné - pokud snímek vyčerpá předem přidělené místo, automaticky se zahodí. Každý snímek daného LV je rozdíl oproti tomuto LV (nikoli oproti předchozím snímkům), což může vyžadovat hodně místa při snímkování souborových systémů s významnou aktivitou zápisu (každý snímek je větší než předchozí). Je bezpečné vytvořit snímek LV, který má stejnou velikost jako původní LV, protože na snímku pak nikdy nedojde volné místo.

Snímky mohou být také velmi pomalé (to znamená 3 až 6krát pomalejší než bez LVM pro tyto testy MySQL) – viz tato odpověď týkající se různých problémů se snímky. Pomalost je částečně způsobena tím, že snímky vyžadují mnoho synchronních zápisů.

Snímky mají některé významné chyby, např. v některých případech mohou velmi zpomalit zavádění nebo způsobit úplné selhání zavádění (protože jádru může vypršet časový limit čekání na kořenový FS, když se jedná o snímek LVM [opraveno v Debianu initramfs-tools aktualizace, březen 2015]).

• Do roku 2015 však bylo zjevně opraveno mnoho chyb v závodě snímků.
• LVM bez snímků se obecně zdá být docela dobře odladěný, možná proto, že snímky nejsou využívány tolik jako základní funkce.

Alternativy snímku - souborové systémy a hypervizory VM

Snímky VM/cloud:

• Pokud používáte hypervizor virtuálního počítače nebo poskytovatele cloudu IaaS (např. VMware, VirtualBox nebo Amazon EC2/EBS), jejich snímky jsou často mnohem lepší alternativou ke snímkům LVM. Poměrně snadno můžete pořídit snímek pro účely zálohování (předtím však zvažte zmrazení FS).

Snímky systému souborů:

• Snímky na úrovni souborového systému se ZFS nebo btrfs se snadno používají a obecně jsou lepší než LVM, pokud používáte holý kov (ale ZFS se zdá mnohem vyspělejší, jen obtížnější instalace):

• ZFS:Nyní existuje jádrová implementace ZFS, která se používá několik let, a zdá se, že ZFS získává přijetí. Ubuntu má nyní ZFS jako možnost „z krabice“, včetně experimentálního ZFS na rootu ve verzi 19.10.

• btrfs:stále není připraveno k produkčnímu použití (dokonce i na openSUSE, které jej dodává standardně a má tým věnovaný btrfs), zatímco RHEL jej přestalo podporovat). btrfs nyní obsahuje nástroj fsck (FAQ), ale často kladené otázky doporučují, abyste se, pokud potřebujete fsck rozbitý souborový systém, poradit s vývojářem.

Snímky pro online zálohování a fsck

Snímky lze použít k poskytnutí konzistentního zdroje pro zálohy, pokud budete opatrní s přiděleným místem (ideálně má snímek stejnou velikost jako zálohovaný LV). Vynikající rsnapshot (od 1.3.1) za vás dokonce spravuje vytváření/mazání snímků LVM – viz tento NÁVOD na rsnapshot pomocí LVM. Všimněte si však obecných problémů se snímky a toho, že snímek by neměl být sám o sobě považován za zálohu.

Snímky LVM můžete také použít k online fsck:vyfotografujte LV a fsck snímek, přičemž stále používáte hlavní nesnapshot FS – popsané zde – není to však úplně přímočaré, takže je nejlepší použít e2croncheck, jak popisuje Ted Ts 'o, správce ext3.

Během pořizování snímku byste měli dočasně "zmrazit" souborový systém - některé souborové systémy jako ext3 a XFS to udělají automaticky, když LVM vytvoří snímek.

Závěry

Navzdory tomu všemu na některých systémech stále používám LVM, ale pro nastavení desktopu preferuji nezpracované oddíly. Hlavní výhodou, kterou vidím od LVM, je flexibilita přesouvání a změny velikosti FS když musíte mít na serveru vysokou dobu provozu - pokud to nepotřebujete, gparted je jednodušší a má menší riziko ztráty dat.

LVM vyžaduje velkou péči při nastavení ukládání do mezipaměti kvůli VM hypervizorům, ukládání do mezipaměti pevného disku / SSD atd. - ale totéž platí pro použití Linuxu jako DB serveru. Nedostatek podpory ze strany většiny nástrojů (gparted včetně výpočtů kritické velikosti a testdisk atd.) je použití těžší, než by mělo být.

Pokud používáte LVM, buďte se snímky velmi opatrní:používejte snímky VM/cloud, pokud je to možné, nebo prozkoumejte ZFS/btrfs, abyste se LVM úplně vyhnuli – možná zjistíte, že ZFS nebo btrfs jsou dostatečně vyspělé ve srovnání s LVM se snímky.

Sečteno a podtrženo:Pokud nevíte o výše uvedených problémech a o tom, jak je řešit, je nejlepší LVM nepoužívat.

Řešení 2:

Tento příspěvek jsem [+1] a alespoň si myslím, že většina problémů existuje. Viděl jsem je při provozu několika 100 serverů a několika 100 TB dat. LVM2 v Linuxu mi připadá jako „chytrý nápad“, který někdo měl. Jako někteří z nich se občas ukáže, že nejsou "nechytří". Tj. Nemít striktně oddělené stavy jádra a uživatelského prostoru (lvmtab) by se mohlo zdát opravdu chytré se toho zbavit, protože mohou nastat problémy s korupcí (pokud nepochopíte správný kód)

No, právě, že toto oddělení tam bylo z nějakého důvodu - rozdíly se projevují ve zpracování ztráty PV a online reaktivaci VG s chybějícími PV, aby se vrátily do hry - To, co je hračkou na „původních LVM“ (AIX, HP-UX), se na LVM2 od r. zpracování stavu není dost dobré. A ani mě nechtějte mluvit o detekci ztráty kvora (haha) nebo o zpracování stavu (když odeberu disk, nebude označen jako nedostupný. Dokonce ani mít sloupec zatracený stav)

Re:stabilita pvmove ... proč je

pvmove ztráta dat

takový top hodnocený článek na mém blogu, hmmm? Právě se dívám na disk, kde jsou data fyzického lvm stále zavěšena ve stavu od poloviny pvmove. Myslím, že došlo k určitým memleakům a obecná myšlenka, že je to dobrá věc kopírovat data živých bloků z uživatelského prostoru je prostě smutné. Pěkná citace ze seznamu lvm "vypadá jako vgreduce --missing nezpracovává pvmove" Ve skutečnosti to znamená, že pokud se disk během pvmove odpojí, nástroj pro správu lvm se změní z lvm na vi. Jo a také se vyskytla chyba, kdy pvmove pokračuje po chybě čtení/zápisu bloku a ve skutečnosti již nezapisuje data do cílového zařízení. WTF?

Re:Snímky CoW se provádí nebezpečně, aktualizací NOVÝCH dat do oblasti snapshot lv a následným sloučením, jakmile snap smažete. To znamená, že máte silné IO skoky během konečného začleňování nových dat do původního LV, a co je mnohem důležitější, máte samozřejmě také mnohem vyšší riziko poškození dat, protože po stisknutí tlačítka nebude snímek porušen. zeď, ale původní.

Výhoda je ve výkonu, provedení 1 zápisu místo 3. Výběr rychlého, ale nebezpečnějšího algoritmu je něco, co se zjevně očekává od lidí jako VMware a MS, na „Unixu“ bych raději tipoval, že se věci „udělají správně“. nezaznamenal jsem mnoho problémů s výkonem, pokud mám úložiště pro zálohování snímků na jiném disk než primární data (a samozřejmě zálohování na další)

Re:Bariéry Nejsem si jistý, jestli za to někdo může LVM. Pokud vím, byl to problém s devmapperem. Ale může být nějaká vina za to, že se o tento problém ve skutečnosti nezajímal alespoň od jádra 2.6 do 2.6.33AFAIK Xen je jediný hypervizor, který používá O_DIRECT pro virtuální stroje, používaný problém být, když byl použit "loop", protože jádro by to stále ukládalo do mezipaměti. Virtualbox má alespoň nějaké nastavení pro zakázání takových věcí a zdá se, že Qemu/KVM obecně umožňuje ukládání do mezipaměti. Všechny FUSE FS tam mají také problémy (bez O_DIRECT)

Re:Velikosti Myslím, že LVM dělá "zaokrouhlení" zobrazené velikosti. Nebo používá GiB. Každopádně musíte použít velikost VG Pe a vynásobit ji číslem LE LV. To by mělo poskytnout správnou velikost sítě a tento problém je vždy problém s používáním. Zhoršují ho souborové systémy, které si takové věci během fsck/mount nevšimnou (ahoj, ext3) nebo nemají funkční online "fsck -n" (ahoj, ext3)

Samozřejmě to říká, že nemůžete najít dobré zdroje pro takové informace. "kolik LE pro VRA?" "jaký je fyzický offset pro PVRA, VGDA, ... atd."

Ve srovnání s původním je LVM2 ukázkovým příkladem "Ti, kteří nerozumí UNIXu, jsou odsouzeni k jeho přetvoření, ubohé."

Aktualizace o několik měsíců později:Nyní jsem pro test narazil na scénář „úplného snímku“. Pokud se zaplní, zablokuje se snímek, nikoli původní LV. Tam jsem se mýlil, když jsem to poprvé zveřejnil. Od nějakého doktora jsem načerpal špatné informace, nebo jsem to možná pochopil. V mých nastaveních jsem byl vždy velmi paranoidní, abych je nenechal zaplnit, a tak jsem nikdy neskončil opravený. Je také možné prodloužit/zmenšit snímky, což je lahůdka.

Stále jsem nebyl schopen vyřešit, jak identifikovat stáří snímku. Pokud jde o jejich výkon, na stránce projektu „thinp“ fedora je poznámka, která říká, že technika snímků je revidována, aby se nezpomalovaly. s každým snímkem. Nevím, jak to implementují.

Řešení 3:

Pokud plánujete používat snímky pro zálohování – buďte připraveni na velký zásah do výkonu, když bude snímek přítomen. jinak je vše v pořádku. lvm používám v produkci několik let na desítkách serverů, ačkoli můj hlavní důvod, proč jej používat, je atomický snímek, který neumožňuje snadno rozšiřovat objemy.

BTW, pokud budete používat 1TB disk, pamatujte na zarovnání oddílů – tento disk má s největší pravděpodobností 4kB fyzických sektorů.

Řešení 4:

I když poskytuje zajímavé okno o stavu LVM před 10+ lety, přijatá odpověď je nyní zcela zastaralá. Moderní (tj.:LVM po roce 2012):

• respektuje požadavky na synchronizaci/bariéru
• má rychlý a spolehlivý snímek ve formě lvmthin
• mají stabilní mezipaměť SSD prostřednictvím lvmcache a zásady rychlého zpětného zápisu pro NVMe/NVDIMM/Optane přes dm-writecache
• virtuální optimalizátor dat (vdo ) podpora díky lvmvdo
• integrovaný a na svazek RAID díky lvmraid
• automatické zarovnání na 1 MB nebo 4 MB (v závislosti na verzi), čímž se zcela zabrání jakémukoli problému se zarovnáním 4K (pokud nepoužíváte LVM přes nesprávně zarovnaný oddíl)
• výborná podpora pro rozšíření svazku, zejména při přidávání dalších blokových zařízení (což prostě není možné při použití klasického souborového systému jako ext4/xfs nad prostým oddílem)
• skvělý, přátelský a mimořádně užitečný seznam adresátů na [email protected]

To samozřejmě neznamená, že vždy máte používat LVM - zlaté pravidlo pro ukládání je vyhnout se nepotřebným vrstvám. Například pro jednoduché virtuální stroje můžete určitě pokračovat pouze s klasickým oddílem. Ale pokud si ceníte některé z výše uvedených funkcí, LVM je extrémně užitečný nástroj, který by měl být součástí sady nástrojů každého seriózního správce systému Linux.

Řešení 5:

Adame,

Další výhoda:můžete přidat nový fyzický svazek (PV), přesunout všechna data do tohoto PV a poté odstranit starý PV bez jakéhokoli přerušení služby. Tuto schopnost jsem za posledních pět let použil nejméně čtyřikrát.

Nevýhoda, kterou jsem ještě neviděl jasně zdůrazněnou:U LVM2 je poněkud strmá křivka učení. Většinou v abstrakci, kterou vytváří mezi vašimi soubory a podkladovými médii. Pokud pracujete jen s několika lidmi, kteří sdílejí domácí práce na sadě serverů, může se stát, že pro váš tým jako celek je tato extra složitost ohromující. Větší týmy, které se věnují práci s IT, nebudou mít takový problém.

Například ho široce používáme zde v mé práci a věnovali jsme čas tomu, abychom celý tým naučili základy, jazyk a holé základy o obnově systémů, které se nespouštějí správně.

Je třeba zdůraznit jedno upozornění:pokud zavádíte systém z logického svazku LVM2, znesnadníte operace obnovy, když dojde k havárii serveru. Knoppix a přátelé na to nemají vždy ty správné věci. Takže jsme se rozhodli, že náš adresář /boot bude na vlastním oddílu a bude vždy malý a nativní.

Celkově jsem fanouškem LVM2.