Dotaz: Je používání LVM bezpečné?

[toi]

Chtěl bych na samba serveru vytvořit virtuální svazek, ale nejsem si jist pár vecmi: sice už jsem si to vyzkoušel na dvou menších discích a funguje to skvěle, ale je používání lvm bezproblémové? Nerad bych, abysme přišli o data! A taky by mě zajímalo jestli když dokoupím další disk, tak jestli půjdou jednoduše připojit k již stávajícímu virtuálnímu svazku. Jinak by to totiž postrádalo smysl Díky za info;)

Odpovědi

[Josef Kufner]

Ja osobne s lvm zadny problem nemam a vypada celkem odolne.

[toi]

A jak je to s přidáním dalšího disku do virtuálního svazku? Jde to jen přidat a zvětší se kapacita svazku nebo se musí nějak složitě formátovat a přijdu o data?

[hrochoun]

pridat disk do lvm pole jde bez problemu. "roztahnuti" filesystemu zavisi od toho jaky pouzivate - vsechny bezne jdou bez problemu zvetsit aniz by clovek prisel o data. kazdopadne ale plati ze zalohovani je matka moudrosti :)

[Ondřej Kubečka]

Taky mi to bezi na serveru (tedy LVM2), zatim asi 9 mesicu a zda se, ze celkem spolehlive. Pouze se nemohu zbavit dojmu, ze rychlost cteni z disku dostala na frak, coz jsem ovsem zatim nijak experimentalne neoveroval. Mate nekdo podobny dojem?

Co se tyce spolehlivosti:

1. Rikal jsem si, ze me to alespon bude motivovat vytvorit system castejsich zaloh.

2. Pri me paranoie bych se asi hodne bal to pouzit na samostatny disk (sam jsem podlozil to zrcadlem v Soft-RAIDu) kvuli pripadne havarii zeleza (coz mi dnes u disku nejprijde jako vec pravdepodobna, ale temer jista). Teorie rika, ze z beznych FS na disku bych asi dostal kde co. Ale je-li mezi tim jeste LVM (zejmena pokud by to byla nesouvisla oblast), tak by se ta data, hadam, dolovala asi dost tezko a par bedaru mi muze zpusobit velkou bolest hlavy (coz nekdy mohou i tak). Na druhou stranu plati-li bod 1., tak to asi tolik nevadi.

[toi]

Používám reiser, ale nikdy jsem filesystem "neroztahoval" pole se bude skládat z dvou disků 80G + 1*160G a záloha bude problém, protože to nejsou zas tak citlivá data a je jich hodně, ale jestli by mělo dojít při havárii jednoho disku ke ztrátě dat na všech discích tak bych do to ho raději nešel. Jak to teda je?

[Ondřej Kubečka]

Ne. nedojde ke ztrátě dat na všech discích a fyzicky dost dobře ani nemůže, pokud disk zrovna disk nezahyne v ohnivé kouli nebo něco podobného, aby vzal i další. Akorát pokud různé fs budou po různých discích a jeden se vysype, tak by to asi bylo mnohem pracnější dat dohromady. Výsledek by záležel na okolnostech (jak jsou rozloženy logické svazky, jak moc disk odešel...), ale já jsem prostě pesimista.

Na druhou stranu: pružnost a pohodlí LVM (a spol.) jsou značné a mě osobně to za to stálo. Zvažte sám.

Výběr fs může být možná o to důležitější. Ale nechci vyvolat flame, takže to moc načínat nebudu. Prostě jsem volil jinak. :)

[toi]

OK, ptal jsem se, protože u Raidu tomu tak je pokud nejde o zrcadlení nebo o jiné ošetření. Myslím, že to flame určitě nevyvolá když mě poradíte jaký fs je nejvhodnější. Byla by to situace, že všechny disky budou tvořit jeden prostor s jedním filesystemem - prostě 320G oddíl:D který naformátuju na reiser pokud mi neporadíte jinak:)

[Ondřej Kubečka]

Obávám se, že o flame to je, protože podobně jako skoro každý má tu svou nej(lepší/)oblíbenější distribuci, tak také má svůj fs. Jeden a týž systém jedni vychvalují do nebes a druzí zatracují do pekel, všichni jisti si svou pravdou.

Přesto, na vaše výslovné přání: :)

Vzhledem k jeho stáří, rozšířenosti a známosti/jednoduchosti bych pro případ havárie jako nejjednodušší na vysekání dat viděl z linuxových fs ext2 a tedy teoreticky i ext3. Jenomže na takhle velký svazek by to bylo hodně moc nešikovné a pomalé (což je také značná nectnost ext3 obecně).

Reiserfs je podle všeho rychlý, velmi rychlý. Zdá se však, že nepanuje všeobecná shoda stran jeho kvality/stability. Případně stability jeho nástrojů (což už dnes může být dávno neplatný kus historie). Tohle je na ten flame, prostě mu moc nevěřím ani já, ani někteří z kolegů, byť znám i také, co jsou jeho skalními příznivci a letitými uživateli.

No a pak jsou tady další. Osobně jsem si zvolil XFS v práci na servery i doma na stanici. Ale spíše doufám, že disk neklekne (doma) nebo to raději ještě podkládám zrcadlením (v práci), protože bych z něj nic vysekávat nechtěl. FS sám o sobě se zdá chovat slušně a zůstává konzistentní. Od doby, co jsem na něj přešel jsem o nic nepřišel ani při nepěkném chování k počítači a výpadcích. Reiser jsem bohužel jednou před lety vysypal - prostě traumata z dětství.

Jednu dobu jsem ještě zvažoval také JFS, protože jako jeden z nemnoha se casní podporou schopností fs také zmenšovat, což se u LVM může hodit stejně jako jeho zvětšování. Jenomže: a) narazil jsem na pochybnosti o kvalitě linuxové implementace (obavy mohly být liché), b)Shrink fs je asi obecně špatná myšlenka, protože je to asi obvykle o ústa. Ale třeba je riziko jenom teoretické a v praxi to stojí za to?

Soft-RAIDu bych se v kombinaci s LVM asi tolik nebál. Je to pravda rozumný přístup: "více věcí, více potenciálních průšvihů" a "v jednoduchosti je síla". Ale nakonec jsem se do toho pustil a zatím se nezdá, že by si to nesedlo. Možná s takovou možností i někdo počítal při vývoji. :)

[Martin Lebeda]

Jenomže na takhle velký svazek by to bylo hodně moc nešikovné a pomalé (což je také značná nectnost ext3 obecně).

Když jsem před cca 1/2 rokem instalovat nový disk (80GB), řešil jsem, který FS na něj dám. Vybral jsem cca 20GB 500KB-2MB souborů v rozsáhlém stromu (fotografie) a zkoušel jsem je nakopírovat, prohledávat, vypsat, selectivně i hromadně mazat, seek v rámci 50MB souboru, odpojit FS, znovu připojit, rebootovat – to několikrát opakovat… Netvrdím, že to bylo objektivní. Zhruba to odpovídalo, tomu, co s tím diskem budu provádět později v praxi. Postupně jsem to zkoušel na ReiserFS, Ext3, JFS, XFS.

Co mne překvapilo, byl fakt, že ext3 byl ve všech testech cca o 10% rychlejší než všechny ostatní. Pokud jde o vlastnosti, pak nejpromakanější žurnálování má ext3, nejpromakanější EA/ACL má xfs, který má také nejmenší omezení na rozsahy a počty souborů.

[Ondřej Kubečka]

Samozřejmě, já hlava děravá, plánované použití je podstatné při výběru. Tuším, že s ext3 by to dopadlo o poznání hůře, kdyby šlo o velké kvantum dost malých souborů. Ale možná jsem obětí pověry. :) Pokud však vyhovuje zadání, tak zpětnou kompatibilitu s Ext2 bych viděl jako značnou výhodu.

[Heron]

Ext3 ma docela vazne problemy s mnoha soubory. Zkousel jsem jednou vytvorit 100 000 souboru v adresari (zrovna jsem cetl clanek o RaiserFS, ktery to udajne bez problemu zvlada -- nemuzu to overit). Mno vytvorilo se to docela rychle, problem (a dost vazny) byl to smazat. Nevim jestli to bylo tim, ze neustale musel zapisovat do zurnalu nebo prerovnaval nejaky B-strom. Disk vrcel asi tak 10 minut.

[unchallenger]

Hm, mám reiserfs (sazmořejmě ;-) tak jsem to zkusil. Vytvoření

sync; time { seq 100000 | xargs touch; sync; }
real    0m4.371s
user    0m0.253s
sys     0m3.736s

Vypsání + zrušení

sync; time { ls | xargs rm; sync; }
real    0m6.841s
user    0m0.842s
sys     0m5.949s

[Heron]

Hmm tak nevim, tenhle postup je nejakej rychlejsi :))

Moje Ext3:

$ sync; time { seq 100000 | xargs touch; sync; }
real    0m4.194s
user    0m0.220s
sys     0m2.933s

$ sync; time { ls | xargs rm; sync; }
real    0m4.292s
user    0m1.221s
sys     0m2.131s

Mozna je to zpusobeno volanim sync po kazdym zapisu na disk, zkusim:

$ sync; time { seq 100000 | xargs touch;}
real    0m3.982s
user    0m0.209s
sys     0m2.991s

Tak jak jsem to predtim zkousel??? Bylo to fakt dost pomale...

[Heron]

Uff, co jsem to napsal za blbost v tom druhym odstavci? Jsem debil, ten sync se samozrejme v cyklu nevola...

Dneska uz radsi koncim :((

[podlesh]

> prerovnaval nejaky B-strom

Jo, prave ze zadny B-strom, pekne linearni seznam!! Alespon tak to byvavalo. Novejsi verze uz si dokazi obsah adresare alespon rozumne cachovat (indexovat), takze vypis uz je celkem v pohode.

[Jan Kundrát (jkt)]

Tady bych tipoval, ze bude reiserfs celkem rychly, protoze umi ukladat maly soubory primo do adresarovyho stromu (viz notail option pri mountu). Ale ja bych tam reiserfs uz z presvedceni necpal

[jm]

Tak pouzij RAID-5 a LVM hod nad nej...

[toi]

Sice se v raidech moc nevyznám, ale radši bych to do toho nemíchal už takhle budu trnout jestli to bude spolehlivě fungovat-myslím moje nastavení

[anon123]

No a prave raid je to dulezite, kdyz se neco nepovede. Mas naprostou zalohu. Teoreticky a mozna i prakticky je to nejlevnejsi zaloha dat, navic bezobslusna. Jeden disk se vymlatim tak to mas porad na jinem. Urcite bych volil raid, jestli si muzes dovolit koupit vice HDD. Bez zalohy ani ranu. Take jsem to mel podobne jako ty, ale porad jsem trnul, kdy se mi disky ***. Ted je to v pohode, protoze jedu na raidu. Bohuzel paskove uloziste je na me porad dost drahe. Ale byla by to parada.

[Ondřej Kubečka]

RAID je prima a snizuje riziko ztraty dat v dusledku havarie disku. Taky se za nej primlouvam a fandim mu, ale za zalohu bych to nepovazoval. Kdyz se vam totiz poradne vysype filesystem, tak vam az tak moc nepomuze a jako zaloha to neposlouzi. Ale jinak je to prostredek, ktery bych nevynechal.

[Martin Lebeda]

Přesně to jsem chtěl napsat, proti rm -rf / je naprosto neúčiný .

[podlesh]

Jasne, RAID neni zaloha a nelze jim zalohu nahradit. Nicmene je to zakladni priprava na chvili, kdy se disk rozbije (a bohuzel to v dnesni dobe neni otazka ZDA, ale KDY).