LVM - 1 (úvod, vytvoření oddílu) (diskuse)

[menphis]

musim upozornit, ze neni prilis vhodne davat vice disku do jedne VG, nebot pri rozbiti nektereho disku, jsou necitelna i data na ostatnich discich danne VG.

[Aldagautr]

neresi to pak nahodou -C u lvcreate?

[menphis]

no mel by, ikdyz si tim nejsem uplne jistej.....by to mohl nekdo ve virtualu nebo na souborech vyzkousek ;)

nebo by se obnove lvm/dat, mohl venovat nektery z dalsich dilu serialu.

[Heron]

nebo by se obnove lvm/dat, mohl venovat nektery z dalsich dilu serialu.

Jo, plánuji to zařadit do některého z pozdějších dílů.

[CET]

neresi to pak nahodou -C u lvcreate

no mel by, ikdyz si tim nejsem uplne jistej.....by to mohl nekdo ve virtualu nebo na souborech vyzkousek ;)

No, ten prepinac -C neni tak moc reseni. Jenom proste pomoci -C se da rict, ze se ma LV udelat souvisle na jednom PV (kde je misto), pripadne, jak se urci pri pvcreate na cmdline (posledni parametr).

Kdyz pak chybi disk, tak (pokud si to jeste pamatuju) se pouzije pri vgchange parametr --partial (ikdyz moje man stranka ten parametr nepopisuje, jenom ho uvadi ve syntaxi).

Problem je, kdyz neni dostatek mista na zadnej PV, tak proste takovou LV nevytvoris a taky bude contiguous LV asi o trosku pomalejsi, nez LV distribuovana na ruzny PV.

Rozhodne je spis lepsi mit v zaloze nejakej jinej system na obnovu VG, pripadne na vytazeni aspon nejakych dat, ale je fakt, ze kdyz proste zmizi celej disk, tak se z toho nic kloudnyho nedostane. Spis kdyz se LVM nejak rozhasi, jako napr. FS bez zurnalu pri padu systemu.

[Peter Listiak]

Dovolim si nesuhlasit. U nas to robime celkom bezne a bezpecne. Pripajame vzdialeny storage (SAN) a len vdaka LVM vieme jednoducho, rychlo a bezbolestne uspokojit meniace sa poziadavky zakaznikov. Ak potrebuju vacsiu kapacitu jednoducho na filery vyexportujeme nove zariadenie a pridame do volume groupy. Nesledoval som vyvoj LVM od zaciatku ale predpokladam, ze bolo navrhovane najma pre taketo pripady.

[tomasgn]

to je ale jiny pripad, protoze pravdepodobne nealokujete jednotlive fyzicke disky, ale volumy vytvorene na nejakem RAIDu, kde se selhani fyzickeho disku resi na urovni storage bay a LVM se o nem vubec nedozvi.

na linuxu se da pouzit SW RAID jako pojistka proti ztrate dat pri vypadku fyzickeho disku.

[CET]

protoze pravdepodobne nealokujete jednotlive fyzicke disky, ale volumy vytvorene na nejakem RAIDu,

rozhodne PV na partisnach bych delal jenom pro velky mnozstvi nedulezitych dat (ala RAID0) - spojeni vice disku do jednoho vetsiho (klidne i RAID0 a nad tim jednim diskem LVM). Netusim ted, jestli do RAID0 jdou pridavat dalsi disky tak jednoduse jako do LVM, ale vytvoreni VG je neco na zpusob RAID0, s tim, ze z VG muzu disk zase odebrat.

Na dulezity veci samorezjme nejdriv z disku udelat nejaky bezpecny RAID a na tim pak teprve tvorit PV/VG/PV.

[Heron]

na linuxu se da pouzit SW RAID jako pojistka proti ztrate dat pri vypadku fyzickeho disku.

Opatření proti ztrátě dat je záloha. Mirror pouze pomůže ve chvíli, kdy spadne disk (stačí přidat nový a jede se dál), ale určitě bych nezatracoval více disků ve VG jen proto, že data nejsou chráněna. Nejsou, protože to se řeší jejich zálohou a nikoliv správou diskových oddílů.

[Ash]

Bohužel, i kdybyste zálohoval jak posedlý, ztrátě dat při výpadku disku tím nijak nezabráníte :) Pravda, budete mít k dispozici neaktuální zálohu... :)

[Käyttäjä 11133]

Proč by záloha musela být neaktuální?

[Josef Kufner]

Protože tam nebudou ty data, která se nepovedlo během výpadku zapsat. I když lepší než nic, občas to nestačí.

[Xerces]

A co kdyz je od posledni zalohy z disku jenom cteno?

[MilanK]

Pak jste za vodou, protoze Vam staci ta posledni zaloha na veky veku, a jestlize uzivatelum nevadi rychlost pristupu, tak hdd rovnou nahradte optickymi neprepisovatelnymi disky.

[Jary]

Já nevim. Protože pak by to byl RAID?

(:

[koroptev]

o lvm nic moc nevim - presto; to co pisete, zni logicky a jako jasna vyhoda toho, proc vubec zavadet nejakou dalsi vrstvu, preci jinak (nebylo by li vhodne davat vice fyzickych disku do volume group) by to nic moc neprinaselo

 

[Heron]

Přesně tak, toto bude v dalším dílu - snadné přidání dalšího disku do VG a tím zvětšení dostupného místa (včetně systémů souborů).

Je jasné, že pokud je LV rozprostřený přes více PV a jeden z nich odejde, tak jsou data v tahu. Jenže, důležitá data je nutné zálohovat tak jako tak (a s tím ani super nezhoditelné pole nic neudělá) a na nedůležitá si asi nikdo nebude dělat mirror.

Sám mám /home na LVM stripe setu (taktéž se o tom zmíním, asi ve třetím dílu), a nebojím se o data, protože každou noc se to stejně zálohuje - jak píšu výše, stejně by se to zálohovalo i kdyby to bylo na mirroru.

[koroptev]

mam 5 disku ve volume group, lze udelat "chci vyndat tento 1 disk, misto na zbylych 4 staci, aby se tam vsechna data vesla, premigruj a uvolni" ?

jinak teda to zni nedobre, jestli odchod jednoho disku znamena necitelnost cele vg, daleko prijemnejsi by bylo, kdyby bylo zajisteno, ze proste holt nebudou viditelna data z necitelneho disku (tozn. 1 soubor by vzdy musel byt cely na nejakem 1 konkretnim disku; asi dusledek oddeleni konkretniho fs od lvm, ktery dovnitr nevidi)

 

[Heron]

mam 5 disku ve volume group, lze udelat "chci vyndat tento 1 disk, misto na zbylych 4 staci, aby se tam vsechna data vesla, premigruj a uvolni" ?

Ano jde, nastuduj si příkaz pvmove (nebo si počkej na další díl). pvmove přesune data buď tam kam mu určíš, nebo bez určení kam to přesune na volné místo na ostatních PV.

proste holt nebudou viditelna data z necitelneho disku (tozn. 1 soubor by vzdy musel byt cely na nejakem 1 konkretnim disku

Toto LVM zajišťovat ani nemůže. Na toto jsou systémy souborů typu ZFS a BTRFS, které spojují manager oddílů a systém souborů do jednoho.

[koroptev]

diky za info, problem manualovych stranek je, ze popisuji ideal, ale nehovori i realite

mate tez nejake zkusenosti s realnym (nejlepe osobni a ve firme popr. velke firme) provozem? ja se s linuxem prilis moznosti setkat nemel, z for pak citam informace od "proc cokoli jineho, kdyz lvm+ ..." po dnesni prvni "nedoporucuje se vic disku do volume group"

 

[Heron]

mate tez nejake zkusenosti s realnym (nejlepe osobni a ve firme popr. velke firme) provozem?

Jistě (nepouštěl bych se do psaní o něčem, co sám nepoužívám a čemu nevěřím), LVM doma provozuji již několik let k plné spokojenosti (momentálně 4TB místa). Na firmě používáme na správu diskových polí (po 12TB) software OpenFiler, který též používá LVM a nabízí exporty přes NFS, sambu a iSCSI, atd. LVM rozhodně není žádná unstable novinka, ale dospělý produkt, který se docela běžně používá.

[Jendа]

Kouknul jsem se na Openfiler a vypadá to zajímavě. Nechceš o tom taky něco napsat?

[Heron]

Dal jsem si to do todo

[Michal]

Pokud se ptas na zkusenosti s pvmove, tak ja jsem s tim spokojen. Pouzil jsem jej sice pouze na pracovnim notebooku, ale nekolikrat jsem delal kompletni restrukturalizaci disku tak, ze jsem do VG pripojil externi USB disk (pripadne pres loopback soubor vytvoreny na tomto disku), presunul vsechny LV, puvodni disk odpojil z VG a nasledne vymenil nebo prepartisnoval a pote zpatky. Kdyz jsem dostal novy notebook, tak jsem puvodne chtel za behu pri praci data presunout z jednoho disku na novy, ale nakonec jsem migroval 32bit -> 64 bit, takze jsem to nevyuzil.

Jinak u pvmove neni problem killnout dany proces (presun bezi dal) nebo restartovat system.

Nicmene i pres spolehlivost popsane cesty durazne doporucuji provest zalohu dulezitych dat. I ja jsem ji provedl, i kdyz devmapperu a lvm verim. V techto a podobnych operacich je vzdy potencialni riziko.

 

Michal

[Käyttäjä 11133]

(a s tím ani super nezhoditelné pole nic neudělá

Super nezhoditelné pole se samo mirroruje na více lokací a na každé této lokaci si i samo vytváří snapshoty pro účely ochrany před tupými uživateli.

[Heron]

No to je super. A jak to pozná, jestli jsem ten soubor smazal úmyslně s cílem získat místo a nebo jestli to byl omyl?

[Käyttäjä 11133]

Když to vytváří snapshoty? Já nikdy neřekl, že to ty snapshoty samo maže Prostě máš například v adresáři .snapshots zálohy z určitých dní/hodin/minut

[Heron]

Já také netvrdil, že jsi to řekl.

Prostě máš například v adresáři .snapshots zálohy z určitých dní/hodin/minut

Takže v podstatě to, co mi dělá rsnapshot každou noc, akorát na jiné úrovni. Hodit se to může. Jenže, stále to není záloha. Je to takový koš, by se dalo říct.

[Jiří J.]

Jen pro doplnění - http://www.avc-cvut.cz/avc.php?id=4714

Jinak já osobně čekám spíše na btrfs

[x]

+1

[srigi]

Alebo aj http://www.ibm.com/developerworks/linux/library/l-lvm2/index.html

[Petr]

Jak je to s bezpečností ukládaných dat? V jakém "formátu" jsou na disku fyzicky? Když se např. v polovině operace vypne proud a mám FS se žurnálem, který to nějak rozchodí, rozchodí to stejně i LVM když v LV bude ten samý FS, nebo ta mezivrstva mezi diskem může způsobit problém?

[Heron]

LVM alokuje místo na PV do bloků physical extents - PE, výchozí velikost je 4MB, což je nejmenší alokovatelná jednotka místa. Při vytvoření LV se snaží alokovat souvislé místo - pak jsou data na disku tak, jak je ukládá systém souborů. Pokud se LV nevejde do souvislého bloku, pak se to rozseká podle dostupných PE s důrazem na minimalizaci "fragmentace". LVM tedy data nijak netransformuje, pouze řídí alokaci místa.

[hlína]

Ha, na tu fragmentaci bych se chtěl zeptat, páč vůbec nevim co se s tím děje, když například na jednom disku je jedna pv, pod tím jedna vg a pod tím několik lv (volné místo využité do mrtě) a zmenším jeden oddíl a druhý zase zvětším a za týden zmenším ten druhý a zvětším zase třetí. Fragmentuje se to nějak či má lvm nějaký účinný mechanyzmy aby tomu zabránila?

 

 

[Heron]

Pokusím se to vysvětlit na příkladu, snad se ty zkratky nepopletou. Každý PV má určitý počet bloků, což je nejmenší alokační jednotka jejíž velikost se dá nastavit. V terminologii LVM je to physical extents - PE. Každý PV tedy má určitý počet PE a skupina (VG) má pak k disposici místo (tedy alokační jednotky PE) ze všech fyzických oddílů (PV). Uff. Příklad, disk o velikosti 100PE a tři oddíly:

Máme obsazený celý disk třemi oddíly s uvedenými PE, kde se nacházejí:

Oddíl A se nachází na PE 1 až 25
Oddíl B na PE 26-50
Oddíl C na PE 51-100

Teď A a C zmenším, situace může vypadat takto:

Oddíl A na PE 1-15
Oddíl B na PE 26-50
Oddíl C na 51-80.

Mám tedy k disposici 30PE místa a vytvořím oddíl D, ten bude na PE rozsahu 16-25 a na rozsahu 81-100. Rozložení na VG pak bude vypadat takto:

A na 1-15
D na 16-25
B na 26-50
C na 51-80
D na 81-100

Počet segmentů (i přesné rozsahy PE) lze získat, například příkazem lvdisplay:

  LV Name                /dev/data/dvd
  VG Name                data
  LV UUID                aKAew6-W2ah-kng3-QRN4-ziAN-hL1f-Ncuu1U
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                183.00 GB
  Current LE             46848
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

Takže ano. fragmentuje se to a LVM toto samo o sobě neřeší - samozřejmně se snaží LV umístit do souvislé oblasti, ale ne vždy to jde. Ale LV o více segmentech se nijak automaticky nedefragmentuje (např. po přidání dalšího PV do VG). Jde ale to popřesouvat ručně programem pvmove, ale je to zbytečné - těch segmentů je velmi málo a jsou velké.

[hlína]

Uf, díky za vyčerpávající odpověď. Nějak sem to i tušil, i když díky za tu radu s těma segmentama. Ten příklad tak nějak odpovídá tomu co mám doma na desktopu, a v poslední době jaksi začlo docházet místo na více oddílech, takže sem takovéhle harakiri už několikrát prováděl abych to trochu přeuspořádal a uvolnil místo na kritických oddílech. No nejvyšší čas přikoupit nějakou tu kapacitu navíc. :)

 

[petr_p]

Předcházet (vlastně jen zakázat) fragmentaci lze pomocí správného výběru alokační strategie. Popsáno to je v lvm(8) u parametru --alloc.

[petr_p]

Bylo by dobré ve článku vysvětlit, nejen jak se s LVM pracuje, ale také jak LVM funguje.

To jest vztah mezi device mapperem a nástroji LVM, formáty metadat (a jejich verze), kam se ukládá konfigurace svazků a kam konfigurace LVM, jak se při startu systému LVM svazky hledají, jak se svazky zastavují atd.

Tohle všechno pomůže LVM oddémonizovat, umožní pochopit principy, na kterých funguje, a v důsledku poskytne správci tolik nutný nadhled a porozumění, aby se LVM nebál a uměl řešit neobvyklé situace (kdy se přehazují disky mezi stroji, když jeden disk umře, když se udělá snímek souborového systému, který se připojuje podle UUID).

[Heron]

Můžeš se toho ujmout. Stejně jako u ACL se ani tady nechci pouštěť do teorie, seriál bude spíše seznamem praktických ukázek (podle mě) nejběžnějších operací, které se u LVM dělají tedy vytváření, rušení, zvětšení, zmenšení, přidám i stripe set a mirror a možná i export přes iSCSI.

Myslím si, že to co popisuješ si zkušený admin stejně již dávno našel a domácí uživatel to vědět ani moc nepotřebuje. Proto jsem se zatím ani nepouštěl do physical ext., protože to zatím není nutné znát.

[dik]

hlavne na iscsi nezapomen, to me moc  zajima.

dik dik

[frEon]

Mam jedno prani. Chtelo by to venovat co nejobsahlejsi kapitolu tematu: co stim, kdyz se to rozbije. Vsechno se da vycist z manualu, ale zkusenosti s havariemi, to v manualech neni.

[Heron]

Dobře, zkusím se to mu věnovat a ve vmware to LVM poškádlit (havarijní zkušenosti z provozu nemám).

[Käyttäjä 11133]

Device mapper umí emulovat diskové havárie.

[Heron]

vmware umí "emulovat" daleko horší věci

[Ondar]

+1 Taky LVM používám zatím k plné spokojenosti ve firmě, ale furt mě hryže ta nejistota "kdyby se ti náhodou podařilo tomu nějak ublížit, tak jsi v pr*****". Něco ve smyslu partition table a MBR - pitomejch 512 bajtů, ale když o ně přijdeš, přijdeš o všechno... O.

[Věroš]

Zálohuješ? Tak jsi v pohodě.

[frEon]

Jsou chvíle, kdy je lepší to jednoduše opravit (když víš jak), než půl dne dolovat zálohy.

[frEon]

diky

[q pal]

Vzdy jsem myslel, ze LVM ma kazdy, kdo sifruje.

Pouzivam vic disku, nad kterymi nastavim RAID. Zakladam malicky svazek pro /boot a na zbytku vytvorim sifrovany svazek, ve kterem pomoci LVM rozsekam system dle potreby. Neumim si to bez LVM predstavit. Musel bych zadavat 20+ heslo pro kazdy svazek zvlast, nebo se to da udelat elegantneji?

[petr_p]

Takže máte dvě VG nad sebou nebo už umí LVM šifrovat VG samotnou (i když nikde na systému není VG vidět jako blokové zařízení)?

[Josef Kufner]

Jeden disk a dve partisny: /boot a lvm.

LVM je pomoci dm-crypt sifrovane a v nem jsou pak partisny jako treba / a swap.

[petr_p]

Tak to jste mě zklamal. Já čekal elegantní řešení, kdy mám dva disky, oba ve VG, tam někde je jedním heslem zašifrována VG a nad tím jsou jednotlivé LV.

[Josef Kufner]

Tohle bych řešil souborem s klíči a odemykat jedním heslem tento soubor. Bohužel to asi nebudou distribuce podporovat defaultně.

[menphis]

ne, jstli jsem to dobre pochopil tak takle to jde... ja sifruju az horny vrstvu..tedy jednotlive oddily v lvm. Abych nemusel heslo zadavat opakovane, tak na privni disku mam klice k ostatnim diskum, takze staci zadat pri bootu heslo k tomuto disku.

[Josef Kufner]

Jo, tak jsem to myslel, ale šifrování spodní vrstvy má Debian předpřipravené v instalátoru. Takže pro zprovoznění stačí při instalaci zmáčknout dvakrát šipku dolu a zadat heslo...

[huhu]

Tak takovéhle články jsou velkou vzácností. Jinak je to samý rozhovor, reklama, nové verze, odlehčená témata, shrnutí, tiskové zprávy, zpravodaje, recenze, události, komentáře, hlasování, soutěže atd. Schválně jsem koukal, kdy se tu naposled objevil aspoň trochu hardcore článek.  A hle - 11. 12. 2008 článek o ACL dokonce od stejného autora, čímž ho velmi oceňuji. Těším se na další díly.

Jak to neobsahuje kusy zdojáků ani ukázky výpisů z terminálu, tak je to vata. Ještě uznávám jaderné noviny.

[Heron]

Mnohokrát děkuji, budu se snažit najít další hardcore témata.

[Fluttershy, yay!]

...budu se snažit najít další hardcore témata.

Hlavně ne ta, která někdy v souvislosti s tebou zmiňuje Pinky. ^_^

Jinak fajn článek, těším se na pokračování.

[Heron]

Tak to by Robert neuveřejnil

[Messa]

K tomu zrcadlení - z hlediska funkčnosti, stability a možnosti zotavení z chyb, je jedno, jestli na serveru použiju zrcadlení v LVM nebo softwarový RAID 1? Co používáte vy? (Já Linux Software RAID.)

[Heron]

Dřív jsem používal Raid-5 a nad tím LVM. Jenže časem se ukázalo, že to není vhodné řešení (to, že DB nemají R-5 rády se všeobecně ví, ale to, jak pomalé to dokáže být mě fakt překvapilo). Dalším problémem je, že při výměně 1TB disku se to pole počítá déle než jeden den (a když v tomto stavu 100% vytížení disků odejde libovolný další disk, všechna data jsou v tahu).

Takže nyní to mám "naopak". Všechny disky naházené do LVM, určité oddíly (např. právě s DB) mám jako stipe-set (raid-0) a některé jako mirror (raid-1).

Těžko tedy srovnávat z hlediska funkčnosti atd. Výhody vidím na obou stranách. Pro mě je LVM mnohem flexibilnější - můžu mít třeba 20 oddílů, každý s jinými parametry (počet stripů, zrcadel). Toto by se v případě SW raidu řešilo jen obtížně a o zvětšování a zmenšování oddílů ani nemluvím.

[alblaho]

Díky za tvé zkušenosti.

Nad tímhle jsem vždycky přemýšlel, jak ty technologie na sebe naskládat

[Messa]

Tak jsem si pročetl LVM HOWTO a jeden docela zajímavý materiál od RedHatu. Nějak z toho mirrorování v LVM nemám dobrý pocit; za prvé, zdá se, že mnoho lidí používá LVM nad RAIDem (a asi to nedělají jen ti, co o této featuře LVM nevědí); za druhé, LVM si potřebuje vést nějaký log, který je buď v paměti a po rebootu je nutné pole resychronizovat (jak dlouho to trvá?), nebo může být na disku (a prý drobně snižovat výkon). To se mi nějak nezdá, Linux Software RAID nic takového nemá

[Michal Kašpar]

po rebootu je nutné pole resychronizovat (jak dlouho to trvá?)

Dlouho. Přesný čas neřeknu, ale když jsem s tím experimentoval, tak ta synchronizace byla z mého pohledu bylo nepoužitelně dlouhá. je to škoda, protože jinde (HP-UX) mirror v LVM používám zcela bez problémů.

[Pavel]

Dobrej, clanek. Doufam, ze dalsi dily budou nasledovat co nevidet. Jsem pomerne obeznamen s volume managerem na solarisu, ale LVM na linuxu mi trochu unikalo. Resp. pokud jsem neco delal s LVM, tak pres nejake gui. Konecne srozumitelny serial jak to resit pres cli.

[Jiří J.]

On už tu jeden stručný článek byl, ale předpokládám, že Heron to chce vzít trochu podrobněji

[Heron]

Díky. Termín uveřejnění dalších článků záleží na redakci. Předpokládám, že budou vycházet každý týden, což také záleží na tom, jak rychle stihnu dodávat další díly.

[msk]

Mna by skor zaujimalo, ako je to s pridavanim diskov do raid 5. S raidom mam osobne skusenosti len v mirror-e, 5-ku som zatial v rukach nemal. Preto by som sa chcel opytat, ci je mozne do existujuceho raid-5 postupne pridavat dalsie disky pre zvysenie kapacity pola, alebo nie. Osobne to zatial robim tak, ze mam lvm nad raid-1 a v pripade potreby dalsej volnej kapacity vytvorim dalsi raid-1 a to lvm rozsirim aj na neho ( takze mam lvm nad 2xraid-1 ).

[Heron]

Do Raid5 lze přidat další disk. mdadm --add /dev/md0 /dev/disk a poté reshape toho pole mdadm --grow /dev/md0 --raid-devices 5. Více na mém webu.

[Ondar]

Mno, zajímavý. A to jako kernel hned ten device /dev/md0 vidí jako zvětšený? Když je to SW RAID, tak asi ano - takže není důvod k rebootu. To je super.

Já používám ve firmě HW RAID-5 alá Dell MD-3000 a tuhle jsem ho potřeboval taky zvětšit. Narval jsem tam disk, přepočítal pole, ale ouha, Linux (RHEL-5) viděl zařízení /dev/sde v pořád stejné velikosti. Takže jsem musel rebootovat a až teprve pak pvresize. Toto už by prý mělo být možno udělat v nejnovějších kernelech bez rebootu (tj. detekce změny velikosti kapacity připojeného SCSI zařízení za běhu).

[Max]

Když si toho linuch nevšimne hned, tak mu to jen řekneme, aby si toho všiml :

echo "- - -" > /sys/class/scsi_host/host0/scan

Zdar Max

[svido]

Zajimavy clanek. LVM doma pouzivam na filmy a jsem s nim spokojen az na jednu vec, ktera me docela stve a to je rychlost. Chtel bych se optat, jestli by mi nekdo neporadil, jak to urychlit. Byl bych za to docela vdecny. Slysel jsem, ze pri pouziti disku vetsi nez 2T by mel byt opatchovany kernel, aby LVM fungovalo nejak rozumne.

Kdyz jsem instaloval OS, tak jsem udelal tu hloupost, ze jsem na cely /home/ dal LVM. Ze zacatku se PC choval dobre, system slapal rychle. Pak jsem dokoupil par disku, nafoukl LVM a ted je to v takovem stadiu, ze po prihlasni do KDE musim cekat tak 5-10min nez mam moznost neco delat. Je to opravdu strasne. Na LVM mam z 90% bluray filmy, z 8% mp3 a zbytek jsou nejake dokumenty a weby. Napadlo me koupit disk a udelat z nej ciste jen /home/ a filmy nechat samostatne na LVM, ktere bych jen mountoval.

Budu rad, za kazdou radu.

Rozdeleni disku:
/dev/root             4,7G  263M  4,5G   6% /
/dev/sdb6             9,4G  5,7G  3,7G  61% /var
/dev/sdb7             9,4G  1,3G  8,1G  14% /opt
/dev/sdb9              37G   19G   19G  50% /usr
/dev/sdb8             2,0G   33M  1,9G   2% /tmp
/dev/mapper/vg-home   3,2T  3,0T  286G  92% /home
/dev/sda5             215G   64G  151G  30% /mnt/widle/data

LVM:
  VG Name               vg
  System ID
  Format                lvm2
  Metadata Areas        7
  Metadata Sequence No  18
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                4
  Act PV                4
  VG Size               3,18 TB
  PE Size               4,00 MB
  Total PE              834632
  Alloc PE / Size       834632 / 3,18 TB
  Free  PE / Size       0 / 0
  VG UUID               hbLrpo-Gyr2-iJyR-Peiw-Xs9t-bd4u-lr3Eqe
 

[petr_p]

A není to problém souborového systému?

[svido]

To si nemyslim. Mam tam ReiserFS.

[Jooky (inactive)]

Ako uvod do lvm super clanok, ale jednu vec by bolo mozno lepsie spomenut.
Nazvy VG a LV mozu obsahovat hocico ale je lepsie dodrzovat istu konvenciu aby to bolo prehladnejsie a aj aby dalsi admin sa tam vyznal a netrhal si vlasi ;o)

Bezne sa doporucuje pouzivat format vgXY (XY je cislo) alebo vg_nazov, popripade vgNazov pre volumegrupu a lvolXY (XY je cislo) alebo lv_nazov pre logical volume (ja uprednostnujem lv_nazov). U volumegroupy je vg00 systemova volumegroupa (system s nej bootuje, alebo obsahuje zakladne data) a dalsie su datove.

Ked sa neskorsie hocikto pozrie na system a najde nieco na styl /dev/vg00/lv_usr alebo /dev/vg_data/lv_sql popripade /dev/mapper/vg00-lv_home tak mu musi byt jasne o co ide.

[Adilkhatri]

검증된 파워볼사이트 를 찾으신다면 eos파워볼사이트 가 있는 파워볼사이트추천 에서 파워볼 을 즐기시길 바랍니다. 5년 이상 운영된 메이저업체 이며 지금까지 많은분들께 사랑받은 안전한파워볼사이트 입니다. 안전한파워볼사이트

[Adilkhatri]

Grateful to you for your post, I search for such article along time, today I discover it at last. this post give me heaps of incite it is to an awesome degree steady for me. 토토

[검증사이트]

Reading this post reminds me of my old room mate! He always kept talking about this. I will forward this report to him. Pretty certain he will possess a good read. Thanks for sharing! 검증사이트

[검증사이트]

Your writing style really helps in getting your point across here. I would be interested to know how much work you did to come up with these wonderfully original ideas. 검증사이트

[토토사이트추천]

Thank you very much for this unique information. I am really thankful to you for this concept. Highly recommend reading this post. 토토사이트추천

[메이저안전놀이터]

I was very impressed by this post, this site has always been pleasant news Thank you very much for such an interesting post, and I meet them more often then I visited this site! 메이저안전놀이터