Sdílení diskových oddílů mezi distribucemi

28. 4. 2006 | Jirka Novák | Systém | 6802×

Sdílení diskových oddílů připadá v úvahu v případě, že máte na počítači nainstalováno několik operačních systémů - např. BSD a Linux nebo třeba Windows 9x a Windows XP. My se ale podíváme na zoubek situaci, v níž máte několik různých distribucí Linuxu.

Proč dělit disk na oddíly?

Na takto položenou otázku lze sice jednoduše odpovědět, ale pokud se má administrátor správně rozhodnout, musí si uvědomit pro a proti, která to přináší:

Pro	Proti
Obrana proti DoS útokům (např. zaplněním kořenového adresáře).	Se zvyšujícím se počtem disk. oddílů se zvyšuje poměr nevyužitého volného místa k diskové kapacitě.
Možnost optimalizace přístupu k jednotlivým diskovým oddílům.
Snazší správa - zejména zálohování.
Pohodlí při práci - máme k dispozici všechna svá data.
Úspora diskového prostoru.

Z tabulky je vidět, že existuje několik důvodů Pro. Jsem zastáncem dělení disku na oddíly, tak je možné, že mě nějaké zápory nenapadly. Laskaví čtenáři je mohou doplnit v diskusi pod článkem. Rozhodnutí je v každém případě na konkrétním administrátorovi.

Které oddíly sdílet?

swap

Odkládací oddíl je nepochybně přirozeným kandidátem. Současně není spuštěno více distribucí, takže v tomto směru není důvod swap nesdílet.

Samozřejmě existují případy, kdy takové sdílení možné není. Jedním z nich je situace, která je naznačena v předchozím odstavci - totiž ta, kdy běží více distribucí současně, tj. v případě virtuálních strojů. Dalším případem je situace, kdy používáme swap partition na hibernaci.

Pokud tedy můžeme sdílet odkládací oddíl, zapíšeme do souboru /etc/fstab následující řádek:

/dev/hda5   none   swap

Použití zajistíme příkazem swapon nebo restartem stroje.

/tmp

Dalším oddílem, který můžeme celkem bez problémů sdílet, je adresář /tmp.

Zabránit nám v tom může jediná věc - pokud je adresář používán pro ukládání uživatelských dat, tj. dokumentů, zdrojových souborů, atd. V takovém případě je třeba zvážit, zda je to vhodné.

Vlastní sdílení pak není nic složitého, stačí přidat stejný řádek do souboru /etc/fstab ve všech distribucích. Osobně ještě při spouštění systému adresář /tmp vymažu.

/boot

Sdílení předchozích dvou oddílů bylo víceméně přirozené. Sdílení adresáře /boot již vyžaduje trošku plánování. Přinese nám ale mnohem snazší správu bootování - budeme mít pouze jednu instalaci zavaděče a jednu konfiguraci.

V Linuxu se používá většinou buď LILO, nebo GRUB. Pokud chceme mít pouze jeden konfigurační soubor, musíme jej uložit na sdílenou partition - přirozené umístění bude v adresáři /boot (sdílet adresář /etc nedoporučuji). V případě LILO je tento proces poněkud násilný, proto doporučuji zaměřit se na GRUB - ten budu popisovat v následujícím textu.

Myšlenka je prostá - potřebujeme partition, na které budou všechny soubory potřebné pro zavedení všech systémů a konfigurační soubor pro boot loader.

GRUB čte konfiguraci z /boot/grub/menu.lst. Takže už zbývá jen sdílet partition s adresářem /boot. Ale když si např. v ArchLinuxu aktualizujete kernel, zapíše se do /boot/vmlinuz26. V případě, že byste v tomto adresáři již měli takto pojmenovaný soubor určený navíc pro jinou distribuci, přidělali byste si zbytečné problémy.

Proto je vhodné ukládat soubory specifické pro jednotlivé distribuce do samostatných adresářů. Vlastní mapování adresáře /boot pro konkrétní distribuci pak bude bohužel o něco složitější, ale není to nic hrozného.

Do adresáře /mnt/boot_partition si připojíme diskový oddíl - do /etc/fstab přidáme:

/dev/hda1     /mnt/boot_partition     ext2   defaults     0   0

V tomto oddílu vytvoříme samostatné adresáře pro každou distribuci:

/mnt/boot
|-- arch
|-- gentoo
|-- grub
|-- initrd-tree
|   |-- bin
|   |-- dev
|   |-- etc
|   |-- lib
|   |   `-- modules
|   |       `-- 2.6.12.1
|   |-- mnt
|   `-- proc
|-- lost+found
`-- slack

Obsah původního adresáře /boot nakopírujeme do příslušného adresáře v /mnt/boot_partition:

# cp -R /boot/* /mnt/boot_partition/arch

Adresář /boot nalinkujeme na konkrétní adresář v /mnt/boot_partition příkazem (např.)

# rm -rf /boot
# ln -s /mnt/boot_partition /boot
# ls -l /boot
lrwxrwxrwx  1 root root 15 2006-04-24 23:27 /boot -> /mnt/boot_partition/arch/

Nakonec upravíme konfiguraci GRUBu v souboru /mnt/boot_partition/grub/menu.lst:

title ArchLinux 0.7.1 Noodle
root (hd0,8)
kernel (hd0,0)/arch/vmlinuz26 root=/dev/hda9 ro vga=normal
initrd (hd0,0)/arch/initrd26.img

Které adresáře NEsdílet?

Na tomto místě se spokojíme pouze s výčtem adresářů a se stručným zdůvodněním.

/etc

V adresáři /etc je uložena konfigurace, která může být specifická pro konkrétní distribuci.

/home

V domovském adresáři uživatelů jsou uložena nastavení používaných aplikací.

/usr

Každá distribuce může používat jiné verze jiných programů.

/var

Hrozí poškození databázových souborů, nekonzistence logu, atd.

ostatní

Umísťovat ostatní adresáře na samostatný oddíl nemá smysl. Až na výjimky - jednu jsem si nechal na závěr.

Uživatelská data

Uvedený postup je možná zajímavou ukázkou možností úspory místa, ale zase tolik toho nepřináší. V tabulce v úvodu byl jako důvod "Pro" uveden jeden zásadní: máme k dispozici všechna svá data.

Ale my je zatím k dispozici nemáme! Adresář /home přece nesdílíme!

Ano, to je pravda. Existují speciální případy adresářů, které je příjemné sdílet, ačkoli se běžně neumísťují na samostatné oddíly. Pro takové adresáře doporučuji vytvoření jednoho oddílu, říkejme mu třeba datový, který bude připojen do /mnt, a jednotlivé adresáře budou nalinkovány do adresářové struktury.

Obvykle se jedná o adresáře s webovými stránkami, adresáře s CVS repository, adresáře s multimediálními soubory a samozřejmě zejména o adresáře s uživatelskými daty.

Popisovat posledně jmenovaný případ by bylo nošením dříví do lesa. Princip je stejný jako v případě adresáře /boot - do /mnt/data_partition připojíme zmíněný datový oddíl...

mount -t auto /dev/sda5 /mnt/data_partition

... a uživatelé si pak ve svých domovských adresářích mohou vytvořit link na svůj adresář v tomto oddíle:

link -s /mnt/data_partition/users/camlost ~/data

Je zřejmé, že by bylo nutné nastavit připojení oddílu v souboru /etc/fstab, aby byl připojen při každém spuštění systému.

Umístění jmenovaných souborů na jeden společný datový oddíl má také zajímavé vedlejší efekty - při reinstalaci Linuxu nepřijdete o data a je snadné jej zálohovat.

Závěr

V tomto článku jsme si ukázali, co je nutné pro sdílení diskových oddílů mezi distribucemi Linuxu. Nyní vám již nic nebrání zkoušet nové verze vaší oblíbené distribuce nebo distribuce úplně nové.

Jedná se o můj první článek pro ABCLinuxu. Doufám, že vám přinesl něco nového. Pokud budete mít dotazy nebo připomínky, napište je do diskuse k článku, pokusím se alespoň na několik z nich reagovat.

       

Komentáře

[xkesh]

ja sdilim /boot /tmp a /home, krome jeste extra spolecneho oddilu jako skladu pro data.

U /home asi staci dbat na to, aby nebyli ve vsech distribucich stejni uzivatele a nemuze se nic moc stat.

Stejne... tezko nekdo bude pouzivat vsechny distribuce na jednom disku rovnocenne, zpravidla je jedna hlavni a ostatni vicemene experimentalni - proto taky zridkakdy stojim o to, abych mel ve vsech distribucich uplne stejne nastaveni. Rozstristene /home pro 4-5 distribuci pak zbytecne blokuje prazdne misto.

[Josef Kufner]

Zdá se mi to, nebo ta tabulka na začátku je nějaká pomatená? Teda konkrétně poslední dva řádky.

Pohodlí při práci - máme k dispozici všechna svá data. – tohle s dělením disků nijak nesouvisí.

Úspora diskového prostoru. &ndash a tohle si tak trochu úplně odporuje s tím jediným důvodem proti.

[camlost]

mozna ty dva uvedene duvody vypadaji, ze si protireci, zkusim upresnit ideu:

uspora mista = nemam N partition s /tmp, nybrz jednu sdilenou plytvani mistem = delime disk na partitions, tzn. na kazde vznika jakysi nevyuzitelny prostor

i kdyz je pravda, ze pri pouhem rozdeleni bez sdileni k uspore mista nedojde. v tomto smyslu to mam nespravne.

[JaR]

My 2 cents: Doporucuji vynechat uplne /tmp a pouzit pro nej tmpfs. Napr radkou do /etc/fstab :

none /tmp tmpfs defaults ,size=1500m 0 0


nebo date link do /dev/shm, ale ja mam lepsi zkusenosti s timhle. Defaultni velikost tmpfs je pulka fyzicke pameti, coz casto staci pro normalni provoz, ale pro napr. kompilace na gentoo ne .

Dokud mate aspon nejakou volnou pamet, tak ctete a ukladate primo z ni, jinak se to, co se zrovna neuziva dava do swapu a ani to neni o moc pomalejsi, nez normalni disk. Ze zkusenosti na gentoo mohu potvrdit, ze prumerne velke preklady uz jen preklad uvnitr tmpfs docela dost urychli. Pak uz vam staci sdilet jen swap odpovidajici velikosti, nebo muzete mit jen zakladni maly swap a tmpfs a pokud potrebujete vetsi tmpfs, tak si ho na tu chvili rozsirite (dejme tomu, ze mate dost mista na /data a jen zakladni velikost tmpfs, napr 256MB, chcete pridat tolik, abyste meli pres 1GB v /tmp).

root> dd if=/dev/zero of=/data/swapfile001.swp bs=1024 count=524288
root> dd if=/dev/zero of=/data/swapfile002.swp bs=1024 count=524288
root> mkswap -L swap001 /data/swapfile001.swp && swapon /data/swapfile001.swp
root> mkswap -L swap002 /data/swapfile002.swp && swapon /data/swapfile002.swp
root> mount -o remount,size=1024m /tmp


Pochopitelne je lepsi to udelat skriptem a spojovani vice mensich swapsouboru mam ve zvyku kvuli kratsi dobe jejich znovuvytvareni, kdyz jeden z nich smazu a lepsimu chovani, krom toho nemusim mazat vsechno, pokud zrovna na /data potrebuji o pul GB vic mista na neco, co pozdeji zase zrusim. Vytvorit swapsoubory potrebujete pochopitelne jen jednou a slouzit mohou, dokud je nesmazete. Za beznych okolnosti si system dal vesele swapuje na partition, jen pokud se rozsoupnete v /tmp, tak pouzije i soubory. A pokud se rozsupujete stale, tak uz je stejne lepsi mit radeji vetsi tu swap partition a hratky s pridavnymi soubory vam odpadnou. Obecne ale na vasem desktopu staci tohle, a na serveru na swapu setrit vlastne nemusite a nechcete .

Jako dodatecny benefit pak pouziti tmpfs pro /tmp je to, ze po rebootu je v /tmp vzdycky cisto . Vlaste je to ucinne proti uzivatelum a programum, kteri ignoruji rozdily v urceni mezi /tmp, /var/tmp a dlouhodobym datovym ulozistem.

[Hynek (Pichi) Vychodil]

Ach bóže. Jak mi tmpfs může cokoli urychlit, když zápis kamkoli (dokud neudělám sync) je vlatně zápis do paměti (buffer, cache)? Tím, že budu vlastně obcházet mechanizmus jádra přidělující paměť pro buffer a cache a budu ho nutit to ukládat do swapu (a tedy na disk) si fakt moc pomůžu. Vlastně si tak ukrajuju množství paměti obsazené neodswapovanými aplikacemi. Co kdybych radši používal věci k tomu, k čemu jsou určené?

[JaR]

Tmpfs je jen v pameti. Takze nikdy zadne disky, nikdy zadne cekani na hlavicky, nikdy zadne zapisy do logu metadat, nikdy nic takoveho. BTW, sync se dela tusim kazdych 30 sekund. Vytvareni a opetovne ruseni tisicu malych souboru poruznu ve filesystemu je skutecne radikalne rychlejsi v tmpfs. Jak spravne rikate, veci se maji uzivat k tomu, k cemu jsou. Vsimnete si, ze nenavrhuju si tam zridit ftp uloziste nebo tam umistit databazi .

Proc to prosim nezkusite, nez me smetete ze stolu kategorickym tvrzenim zalozenym na predpokladu, ze "se to preci takhle ma chovat" a na predpokladu, ze snad mam na mysli uziti /tmp k necemu jinemu, nez je, to jest k docasnym souborum, ktere vetsinou byvaji kratkodobe a znacne male, za to jich ale byva mraky. Zkusil jste treba u sendmailu (na hodne zatizenem stroji, samozrejme) dat nekdy xf subfrontu do tmpfs a porovnat to se stavem, kdy je xf na disku? Ja fakt nemohu za to, ze temporary filesystem je vytecna vec prave pro temporary filesystemy . Hadat se nebudu a nechci, neni to zapotrebi. Kdo chce, zkusi nebo aspon zagoogli a uvidi sam. Kdo nechce, toho nepresvedci nic. Hezky den.

[JaR]

Jeste male upresneni, mozna to vyznelo jinak, nez jsem chtel: tmpfs NENI ramdisk. Tedy melo byt nikoli pouze "je jen v pameti", ale "je jen ve virtualni pameti". Procesum misto nijak zvlast neubira, a pokud skutecne pocitate kazdy byte fyzicke pameti pro procesy, tak opravdu neni pro vas nic, co pameti jakkoli plytva, ale o extremech se snad nebavime (a i tehdy vam tmpfs pomuze, jen v nem asi nebudete nic prekladat . Pokud nekdo chce odkazy na zkusenosti, at zagoogli a hlavne zkusi.

Namatkou treba http://www-128.ibm.com/developerworks/linux/library/l-fs3.html, nebo gentoo wiki nebo... (Vlastni zkusenost je nejlepsi, doporucuje sest z peti psychiatru :o).

[Adrin]

Myslíte že, ale je to jen takový nápad, by mohlo urychlit běh systému, kdyby swap byl umístěn v ramdisku? Měl bych k dispozici třeba 2BG ram a jeden GB (který skoro stále zahálí) bych si vyhradil na ramdisk.

[Michal Vyskočil]

Nebude lepší ten swap potom úplně vypnout ? Pokud máš 2GB RAM, z toho zaplněnou jenom polovinu, tak stejně neswapuješ.

[Robert Krátký]

Možná ne. Viz "How to Use RAM as Swap":

http://kerneltrap.org/node/3660

(a mrkni i do diskuze pod článkem)

[Michal Vyskočil]

Ani ten článek mě nepřesvědčil . Navíc tam v diskusi byla spousta argumentů o swapovacích algoritmech jádra. Ale pokud se swap vypne, tak ty vůbec nepřijdou ke slovu.

Swap má za úkol levně rozšířit dostupné množství paměti tak, že se část dat odloží na disk, který je levnější, než paměť. Pokud udělám swap v RAM, tak tím nezískám žádnou paměť navíc a tím i padá hlavní důvod, proč swap dělat. Navíc, pokud se příliš nepletu, při odswapování stránek se data vždy kopírují. Přestože v našem případě jen v rámci paměti, je to zbytečné. Navíc se data ve swapu nedají přímo adresovat, musí se řešit výpadek stránky a přemapování (sice tu nejvíce práce "odře" MMU v procesoru, ale i tak). Pokud by ta data byla v klasické RAM, nic z toho se dělat nemusí.

Takže pokud mám 256MB RAM a udělám 512MB swap, získám 256+512MB virtuální paměti. Pokud mám 2GB a z jednoho GB udělám swap, dostanu rovněž 2GB paměti + zvýšenou režii při zbytečném swapování.

[Robert Krátký]

Nesnažil jsem se tě přesvědčit. Spíš ukázat, že kolega v této diskuzi nebyl první, koho něco takového napadlo - a že to dokonce někdo i realizoval.

[Michal Vyskočil]

Aha, tak to potom jo Já teď řeším jiný problém, potřebuji si přikoupit RAMku, nějak mě začíná docházet.

[Adrin]

A nedělá swapování ještě navíc to, že pomáhá při defragmentaci paměti?

[Hynek (Pichi) Vychodil]

BTW, sync se dela tusim kazdych 30 sekund.

Pán je na první pohled odborník No zbytek nemá asi ani cenu číst. Ta doba je mnohem delší. Doporučuji si ji zjistit. To vaše řešení může některé operaci zrychlit jen a pouze při splnění několika podmínek. 1) Ty soubory musí být uloženy déle než je sync interval jádra, protože jen tehdy se skutečně fyzicky uloží na disk. Pokud je totiž smažete dřív, tak se na disk nezapíšou ani nesmažou. Prostě se to celé odehraje v paměti. A ta doba je rozhodně víc než 30s. 2) Jejich objem musí být menší než velikost dostupné RAM pro tmpfs, protože jinak by se musely stejně uložit na disk tak jako tak. Prostě by se odswapovaly. Akorát si tak domršíte memmory management jak už jsem popsal v předchozím přízpěvku.

OK. Takže pokud máte hodně nevyužité RAM při běžném provozu a potřebujete do /tmp uložit data, která jsou menší než tato nevyužitá RAM (aby se neodswapovaly) na dobu delší než je sync interval (jinak by se to stejně nezapsalo), tak si skutečně pomůžete. Pak jste šťastný muž. Z toho my vyplývá, že jste hodně bohatý, nebo provádíte nějakou hodně časově náročnou operaci s relativně malým objemem dat.

[Zdeněk Štěpánek]

Sdileni /home (presneji dat, ne nutne oddilu) je vetsinou duvodem proc se cela takova saskarna provadi.

Muze to ale byt problem. Stava se mi ze dokonce i na 2 Slackware-current kde jsou nainstalovane ruzne programy (na tom druhem je jich mene) mi to pokazi spodni listu s ikonama.

Osobne bych to asi resil nesdilenim /home a pak vytvorenim symlinku /mnt/datadisk/uzivatel -> /home/uzivatel/data.

Zdenek

[funny]

Nebyl tu zmíněn problém s kódováním. Nechceme-li přepínat z preferovaného locale v různých distribucích, máme s kódováním v ext2/3 neřešitelný problém. VFAT to umí, do ext2/3 říct info o kódování nelze.

Nechci vyhrožovat, ale až se jednou naš***, napíšu si do jádra patch.

[David Jaša]

To by se hodilo - kdyby to umělo UTF-16, pak by to jelo správně i ve widlích.

[funny]

Mluvil jsem tu o možnosti přepočítávání kódování v ovladačí souborového systému (nebo v nějaké obecné mezivrstvě, kódování většinou filesystémy, resp. specifikace jejich formátu, neřeší).

U CDROM to máme v zrovna pohodě. Za prvé tu máme nějaké standardy (joilet není standard, ale pochází z Vidlí, které tam používají vždy UTF16, rock ridge by asi měl používat UTF-8, ale pokud ne, tak máme možnost si nastavit při mountování nějaké to latin2 ručně).

Já jsem měl na mysli hlavně tu možnost specifikovat si kódování pro ext oddíl. A je to nutné, na disku by mělo být něco z rodiny UNICODE a prostředí by na dané kódování vázané být nemělo.

[David Jaša]

Já jsem měl na mysli hlavně tu možnost specifikovat si kódování pro ext oddíl.

To já taky, s joliet sice sem-tam problémy jsou, ale pokud používám ext3 jako datovou partišnu pro W i L, tak prostě diakritiku použít nesmím. Sám sebe ohlídám, ale to přejmenovávání všeho, co mi dojde, mě nebaví.

[Luboš Doležel (Doli)]

Widle nepoužívají UTF-16, ale UCS-2.

[funny]

Pravda, trochu jsem poplet kódování. Díky za opravu.

U UTF-16 může mít znak více jak dva bajty, takže se doň vejde celý Unicode. Do UCS-2 ne.

[Jiří Daněk]

Je možné nastavit kvótu pro adresář?

Díky

[Honza Houštěk]

Obvykle ne a obecně není mnoho unixových systémů/filesystémů, které by to podporovaly. Jednou z mála výjimek je XFS (je potřeba dost nová verze, pravděpodobně ještě není součástí hlavního stromu).

[Grumpa]

Kvoty se obecne nastavuji pro uzvatele, nebo skupiny. Kvota pro adresar by tedy sla, kdyby se adresar pridelil nejake skupine a te skupine pak kvota. Jinak viz treba tady.

[Václav Pávek]

Jak mam nastavit aby pri startu distra byl vymazan adresar /tmp.

Pouzivam suse, ubuntu, slackware

moc dik

[nardew]

v suse sa mi zda ze to je /etc/init.d/boot.local a tam mozes zapisat, co sa ma pustit po starte

v red-hat like distrach to je /etc/rc.d/rc.local

v slackwari neviem(jedine ak to ma ako gentoo, tak to zapis do /etc/conf.d/local.start)

[Michal Vyskočil]

Slack má něco ve stylu /etc/rc.d/rc.local (pokud se moc nepletu).

[David Jaša]

Ať už mají ty distribuce cokoliv, tak bych to natvrdo nacpal do /etc/rcS.d (v SysV initu) hned za mount věcí z fstabu - potom tam už mohou být soubory běžících programů a ty není záhodno mazat...

[camlost]

to je pravda, ale tam uz muze byt pozde. kdyz se mrknete do /etc/rc.d/rc.M (nejsem si jist), najdete tam mazani vseho mozneho. je to okomentovane. tak me napada, ze se podivam na nejaky slack, to bude momentik.

takze v tom souboru je komentar:

# Remove stale locks and junk files

tak tam staci doplnit adresare, ktere chcete vymazat