Sdílení diskových oddílů mezi distribucemi (diskuse)

[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