Jak jednoduše ohrozit data v RAIDu na Ubuntu (diskuse)

[Michal Kubeček]

U takhle komplikovaného rozdělení by už asi bylo jednodušší udělat si jen jeden RAID z celých disků a nad ním udělat rozdělení pomocí LVM. Případně udělat jednu mirrorovou volume group a jednu normální.

[Sinuhet]

Pri tolika oddilech, nebylo by jednodussi pouzit lvm? Jenom si nejsem jist jak mdadm zkousne vytvareni raidu nad lvm oddily.

[Michal Kubeček]

Obvyklejší je dělat to obráceně, tj. LVM nad RAIDem. Jinak budete mít velmi malou kontrolu nad tím, co s čím v tom poli kombinujete.

[Michal Kubeček]

mdadm by to bylo jedno, jemu stačí, že je to blokové zařízení. Ale bylo by asi potřeba zasáhnout do inicializačních skriptů, protože v distribucích se obvykle nejdřív inicializuje SW RAID a potom LVM.

[Tom.š Ze.le.in]

Neměl by s tím být problém. A neumí lvm stripping a mirroring samo od sebe? Autor stejně podle minulého zápisku používal jen RAID1.

[Michal Kubeček]

Striping ano, mirror AFAIK ne.

[Tom.š Ze.le.in]

V manu lvcreate to je, ale nezkoušel jsem:

-

m, --mirrors Mirrors

Creates a mirrored logical volume with "Mirrors" copies. For example, specifying "-m 1" would result in a mirror with two-sides; that is, a linear volume plus one copy. Specifying the optional argument "--nosync" will cause the creation of the mirror to skip the initial resynchronization. Any data written afterwards will be mirrored, but the original contents will not be copied. This is useful for skipping a potentially long and resource intensive initial sync.

Specifying the optional argument "--corelog" will create a mirror with an in-memory log verses a disk-based (persistent) log. While this removes the need for an extra log device and *may* be slightly faster, it requires that the entire mirror be resynchronized upon each instantiation (e.g. a reboot).

[Michal Kubeček]

Ale není z toho moc jasné, jak (a jestli vůbec) bude zajištěno, že jednotlivé kopie budou na různých fyzických zařízeních. Jednak může být volume group složena jen z jednoho disku, jednak i když ne, bude-li obsahovat např. sda1, sda3, sdb1 a sdb3, striktně vzato by neměla poznat, které dvojice smí použít pro mirror a které ne.

[Tom.š Ze.le.in]

Kopie budou na zařízeních, která se tomu podstrčí, to je pravda. Trochu jsem si s tím kdysi hrál - pokud je disků méně než potřebných zařízení, řvalo to myslím. (bez --corelog minimálně tři zařízení pro -m1). A pokud je jich víc na jednom fyzickém disku, tak to zjištěno není - jiné nástroje to nějak kontrolují?

[Michal Kubeček]

Těžko, obecně asi neexistuje způsob, jak zjistit, jestli jsou dvě bloková zařízení na stejném fyzickém médiu. U SW RAIDu je to jednodušší, tam musíte výslovně říct, z čeho se má ten mirror sestavit.

[Tom.š Ze.le.in]

Mimochodem, je nějaký rozumný důvod (kromě toho, že disk už je rozdělený a nemůžu/nechce se mi to znova dělit) proč dávat do jedné volume group dva oddíly z jednoho disku?

[Michal Kubeček]

Když to dělám na čistém disku a mám čas si to rozmyslet, tak asi ne. Spíš to vzniká tak, že ten druhý byl původně použit pro jiné účely a uvolnil se (třeba když člověk zruší Windows :-) ).

[Michal Kubeček]

P.S.: striping, je to odvozeno od stripe, ne strip

[Tom.š Ze.le.in]

ano, samozřejmě :)

[David Jaša]

Nahlásil jsi to?

[Georgius]

Zatím jsem byl rád, že jsem rozchodil mašinu. Nejsem si ale tak úplně jistý, čí je to bug ... jede v tom udev i mdadm .. Anebo je to fičůra saty, že neumí víc než 15 oddílů ... zatím jsem takový zvěrstva jako 25 oddílů dělal jenom PATě, která ani necekla ...

[Shadow]

IMO všechny SCSI disky (sd*), tedy i SATA disky, mají omezení na 15 oddílů. IDE zařízení (hd*) podobná omezení nemají (maximum je kolem 60 oddílů).

[Ritchie]

Úplně přesně, sd mají omezení na 15 oddílů, hd na 63. Více v seznamu Linux Device List.

[Ritchie]

Co a komu měl nahlásit? Že nečetl dokumentaci? Tohle je vlastnost jádra, nikoliv chyba.

[Michal Kubeček]

No, pokud mu opravdu udev bez nějakého přesvědčování vytvořil /dev/sda16 s major 8 a minor 16, tak to bych za bug bez váhání označil.

[Mortal]

RAID stihnul přepsat MBR

ja myslel, MBR neni soucasti raidu, nebo se mylim?

a dotaz ciste ze zvedavosti:
Jakou ma vyhodu rozdelit disk na tolik oddilu?
Uz pred casem jsem dospel k nazoru, ze nejlepsi ohradky pro data jsou obycejne adresare

[Dalibor Smolík]

ja myslel, MBR neni soucasti raidu, nebo se mylim?
Hm, to by mě také zajímalo. rozdělil jsem oba disky na příslušné oddíly a a přiřadil jsem k sobě v rámci RAID1 jednotlivé oddíly o stejné velikosti a typu - využil jsem tímto celou kapacitu disků.
Myslím, že MBR je v tomto případě součástí raidu.

[Michal Kubeček]

V tomto případě ne. Jeho součástí by byl, kdybyste sestavil pole z celých disků, tj. např.

  mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb

[Michal Kubeček]

Záleží na tom, z čeho máte to pole sestavené. V tomto případě ale došlo k tomu, že program, který měl v úmyslu přepisovat /dev/sda16, přepsal ve skutečnosti /dev/sdb, takže přepsal MBR v místě, kde očekával obyčejný BR oddílu.

Jakou ma vyhodu rozdelit disk na tolik oddilu?

Proč na tolik, to nevím, ale obecně tím můžete zajistit, že můžete používat pro různé účely různé typy filesystému, různé parametry mountu (nosuid, nodev apod.) a že zaplněním jednoho filesystému (třeba /var/log) nepřivedete systém do tak zoufalého stavu, jako kdybyste měl všechno na jednom. Ale při větším počtu filesystémů je vhodnější použít LVM, protože máte téměř jistotu, že u některého z nich neodhadnete správně předem potřebnou velikost.

[Tom.š Ze.le.in]

Lidi jsou různí.

Někdo má rád root partition r/o.

Někdo chce některá data šifrovat na úrovni filesystému.

Někdo chce různé filesystémy pro různé části systému.

Někdo má pocit, že image DVDčka nemusí být soubor, ale může být rovnou samostatný oddíl, když to stejně je k mountování. (a pak to roste rychle).

Někdo nechce aby mu věci přetékaly mezi přihrádkami.

Někdo chce mít odděleny /home a /usr/local kvůli zálohování a/nebo upgradům.

[Georgius]

ja myslel, MBR neni soucasti raidu, nebo se mylim?

Neměl by být. V tom je právě pointa celého příspěvku - že mdadm špatně pobral zařízení a místo sda16-sdb16 mirroroval sdb-sdc. Pak už součástí RAIDu je

Jakou ma vyhodu rozdelit disk na tolik oddilu?
Uz pred casem jsem dospel k nazoru, ze nejlepsi ohradky pro data jsou obycejne adresare

Nejsou všechna vajíčka ve stejném košíku. Příklad: vypnou proud/přepětí/zásah blesku/HW havárie disku+vrcholná smůla: odejdou data na partišně, na kterou se zrovna zapisovalo (já vím, že to není moc pravděpodobné, ale není to dlouho, co jsem řešil TOTÁLNĚ LEHLOU ext3 kdy se mi nepodařilo zrekonstruovat (pořádně) ani z jedné ze záloh FATky). Pokud bude víc partišn tak budu řekněme pracovat s databází a přijdu o databázi (no dobrá, mám RAID1, takže o ni asi nepřijdu, taky už nemám EXT3, ale riziko stále existuje i když je řádově nižší) ale o výsledky statistického hodnocení v jiném adresáři ne. Čili zhruba toto je moje motivace.

[Shadow]

TOTÁLNĚ LEHLOU ext3

Znepokojující. Používám ext3 právě z důvodu spolehlivosti.

takže o ni asi nepřijdu, taky už nemám EXT3

Co tedy používáte? Existuje něco spolehlivějšího než ext3?

[Dalibor Smolík]

Znepokojující. Používám ext3 právě z důvodu spolehlivosti.
Přesně tak, ext3 mám na serveru také. Je nějaký pádný důvod, používat jiný filesystém pro tyto účely? (poučení pro příště)

[Dan Ohnesorg]

Myslim ze o jinych filesystemech se ma smysl bavit, kdyz je potreba vysoky vykon. Stran spolehlivosti nelze dneska ext3 snad nic vytykat.

Nicmene pokus opravit FAT na ext3 musel nutne skoncit tragickym neuspechem

P.S. Preteceni major/minor timto zpusobem povazuji za bug oznacitelny nejvyssi prioritou.

[Michal Kubeček]

Nebo když je ten filesystém využíván nějakým velmi specifickým způsobem, např. velmi vysoký počet velmi krátkých souborů nebo naopak velmi dlouhé soubory.