Řešení 1:
Nechcete se podívat do sekce snímků v LVM-HOWTO?
Snímky LVM jsou základním řešením snímků „kopie při zápisu“. Snímek ve skutečnosti není nic jiného než žádost LVM, aby vám poskytl „ukazatel“ na aktuální stav souborového systému a zapsal změny provedené po snímku do určené oblasti.
Snímky LVM „žijí“ uvnitř skupiny svazků hostující svazek, který je předmětem snímku – nikoli jiný svazek. Vaše prohlášení "...spousta a spousta nepřiděleného volného místa, ne to oddíl" zní, jako by si myslel, že snímky "žijí" mimo skupinu svazků podléhající snímku, a to není přesné. Vaše skupina svazků je umístěna v oddílu pevného disku a svazek je předmětem snímku a případných snímků, které jste v této skupině svazků pořídili.
Normální způsob, jakým se snímky LVM používají, není pro dlouhodobé ukládání, ale spíše pro získání konzistentního „obrazu“ souborového systému, aby bylo možné provést zálohu. Jakmile je záloha hotová, snímek se zahodí.
Když vytváříte snímek LVM, určíte prostor pro uložení všech změn provedených, když je snímek aktivní. Pokud provedete více změn, než jste určili místo pro snímek, stane se nepoužitelným a musí být zahozen. Snímky nechcete nechat ležet, protože (a) se zaplní a stanou se nepoužitelnými a (b) výkon systému je ovlivněn, když je snímek aktivní – věci se zpomalují.
Upravit:
To, co Microsoft Volume Shadow Copy Services a snímky LVM dělají, se příliš neliší. Řešení Microsoftu je o něco obsáhlejší (jak je tomu u Microsoftu obvykle – v dobrém i ve zlém se jejich nástroje a produkty často snaží řešit docela velké problémy oproti zaměření na jednu věc).
VSS je komplexnější řešení, které sjednocuje podporu pro hardwarová zařízení, která podporují snímky a snímky založené na softwaru, do jediného rozhraní API. Kromě toho má VSS API, která umožňují uvedení aplikací do klidového stavu pomocí snapshot API, zatímco snímky LVM se zabývají pouze snímky – jakékoli uvedení aplikací do klidového stavu je váš problém (uvedení databází do „zálohovacích“ stavů atd.).
Řešení 2:
Snímky LVM jsou příkladem řešení snímků kopírování při zápisu, jak řekl Evan. Jak to funguje, se trochu liší od toho, co naznačoval Evan, ale ne o moc.
Když máte svazek LVM bez snímků, zápisy na svazek probíhají tak, jak byste očekávali. Blok se změní a je to.
Jakmile vytvoříte snímek, LVM vytvoří fond bloků. Tento fond také obsahuje úplnou kopii metadat LVM svazku. Když dojde k zápisu na hlavní svazek, jako je aktualizace inodu, přepisovaný blok se zkopíruje do tohoto nového fondu a nový blok se zapíše do hlavního svazku. Toto je 'copy-on-write'. Z tohoto důvodu platí, že čím více dat se změní mezi pořízením snímku a aktuálním stavem hlavního svazku, tím více místa zabere tento fond snímků.
Když připojíte snímek, metadata zapsaná při pořízení snímku umožní mapování bloků fondu snímků na změněné bloky ve svazku (nebo snímek vyšší úrovně). Tímto způsobem, když přijde přístup pro konkrétní blok, LVM ví, který přístup blokuje. Pokud jde o souborový systém na tomto svazku, neexistují žádné snímky.
James poukázal na jednu z chyb tohoto systému. Máte-li více snímků stejného svazku, pokaždé, když zapisujete do bloku na hlavním svazku, potenciálně spustíte zápisy v každém jednotlivém snímku. Je to proto, že každý snímek si udržuje svůj vlastní fond změněných bloků. U stromů s dlouhými snímky může přístup ke snímku způsobit na serveru poměrně dost výpočtů, aby bylo možné zjistit, který přesný blok je třeba obsloužit pro přístup.
Když zlikvidujete snímek, LVM jednoduše zruší fond snímků a aktualizuje strom snímků podle potřeby. Pokud je zahozený snímek součástí stromu snímků, některé bloky budou zkopírovány do snímku nižší úrovně. Pokud je to nejnižší snímek (nebo jediný), fond se prostě zahodí a operace je velmi rychlá.
Některé souborové systémy nabízejí snímky uvnitř souborového systému, ZFS a BTRFS jsou jen dva z těch známějších. Fungují podobně, ačkoli souborový systém sám spravuje změněné/nezměněné mapování. Toto je pravděpodobně lepší způsob, jak to udělat, protože můžete fsckovat celou rodinu snímků pro konzistenci, což je něco, co nemůžete udělat s přímým LVM.
Řešení 3:
Snímky LVM jsou neefektivní, čím více snímků je, tím pomaleji systém půjde.
Podporuji pouze xfs jako to, co používáme, a xfs_freeze lze použít k zastavení nového přístupu k systému souborů a vytvoření stabilního obrazu na disku.
Funkce Copy on Write se používá k efektivnímu využití místa na disku.
Vytvořili jste souborový systém v logickém svazku, který má v sobě volné místo pro snímky.
Toto je příklad z FAQ
Řešení 4:
Neuvádíte, zda používáte Linux nebo HP-UX. V HP-UX vytvoříte logický svazek a připojíte jej jako snímek jiného logického svazku. V Linuxu vytvoříte logický svazek jako svazek snímku.
Odebrání snímku v HP-UX se provádí odpojením svazku; v Linuxu se to provádí pomocí lvremove k odstranění logického svazku.
V každém případě jsou změny to jediné, co je na vašem snímku uloženo. Čím déle snímek zůstane k dispozici, tím více změn má na skladě – a existuje šance, že se zaplní, pokud nebude mít správnou velikost nebo nebude uvolněn.
Rychlost přístupu k disku na svazku snímků je nižší než u normálního svazku; musíte to vzít v úvahu.