particie (oddiely)

[Miroslav Lachman]

Dan Lukes wrote, On 08/21/2014 13:42:

> Pokud neco neprehlizim, tak
>
> vyhody rozdeleni:
>
> +1:  rozdelene svazky znamenaji rychlejsi fsck, ovsem jen pokud jsou na
> ruznych fyzickych discich
> +2:  zaplneni svazku jednou sluzbou ukladajici data muze ohrozit chod
> jinych sluzeb

Ja k tem vyhodam pridavam jeste to, ze kazdy oddil muze byt (a u me 
vetsinou i je) s trochu jinymi mount option.
/ UFS2 bez SU
/usr je normalni UFS2+SU
/var UFS2+SU nosuid a drive i noexec, ale pred casem zacal byt potreba 
exec kvuli /var/db/pkg (coz asi zase odpadne, az prejdu na pkg(ng))
/tmp  UFS2+SU noexec, nosuid

Parkrat jsem zkousel i gjournal, takze tam bylo jeste async. Dneska se 
nekomu muze chtit pouzit SU+J

V nekterych pripadech ma smysl upravovat i velikosti bloku / fragmentu a 
pripadne dalsi "drobnosti", ale to spis u oddilu pro data a ten bych 
teda mel vzdy oddeleny od rootu.

Zaroven s tim fsck se na to divam i tak, ze kdyz se na root temer 
nezapisuje (pokud je samostatny), tak temer nehrozi jeho poskozeni a 
pujde primountovat "vzdy". Podobne i /usr. Problemy pak mohou nastat s 
/var, kam se zapisuje podstatne vic a tak pri nejakem padu systemu muze 
dojit k problemu v tomhle oddilu, ale neohrozi to dalsi oddily a ja tak 
budu mit k dispozici fungujici / a /usr, takze se bude o neco lepe delat 
recovery bez nutnosti bootovat z jineho disku a treba to pujde delat i 
cele na dalku.

Dalsi vyhodou muze byt optimalizace pro rychlost cteni / zapisu 
(pripadne fragmentace). Kdyz mam vsechno na jednom oddilu, tak se nevi, 
kde ktery soubor je, natoz kde bude nejaka jeho cast, ktera vznikne za 
pul roku (databazove soubory, ktere se casem zvetsuji).
Rychlost cteni / zapisu na zacatku disku (vnejsi strana) je temer 
dvojnasobna, nez u vnitrni strany, takze treba swap a oddil pro databazi 
se vyplati udelat na zacatku disku. Stejne tak pro tu databazi ma smysl 
mit samostatny oddil, aby nedochazelo k fragmentaci databazoveho souboru 
a promichavani s milionem malych souboru webu, nebo e-mailu. Ale to uz 
se bavime o nejake optimalizaci pro konkretni nasazeni serveru.
Zaroven u te mensi partition nemusi hlavicky disku litat pres celou 
plotnu az ke stredu disku, kdyz se musi seekovat v ramci jednoho velkeho 
DB souboru (ktery by jinak mohl byt fragmentovany po cele plose plotny. 
Takze jsem cetl i o pripadech, kdy se prave kvuli rychlosti udela na 
vetsim disku partition na zacatku a zbytek disku se ani nevyuziva na nic 
jineho. Proste se vyuzije zkraceni drahy hlavicek.

> nevyhody rozdeleni:
> -1: je nutne spravne odhadnout velikosti "uz na pocatku" jinak hrozi ze
> casem clovek bude mit spoustu volneho mista - bohuzel ne na svazcich,
> kde by ho nutne potreboval mit vic

Ano, tohle je potreba dobre naplanovat uz predem, ale zase kdyz mam 
takhle oddeleny jen ten "zakladni system" a ne uloziste zivych dat, tak 
se tam nic moc velkeho nevyskytne. Za poslednich 10 let jsem asi dvakrat 
narazil na to, ze se po par letech provozu ukazalo, ze by nejaky oddil 
mel byt vetsi, ale vetsinou se to pak resilo i s vymenou celkove vetsich 
disku.

Nicmene kdyz nekdo nevi, co a jak, pak je pro nej lepsi to nerozdelovat 
a pouzit velky oddil na vsechno. (nebo jak tu padlo, pouzit ZFS, kde 
tyhle starosti odpadaji - a prichazeji jine)

> Prehledl jsem neco netrivialniho ?

Nic jineho uz me nenapada :)

>> Swap uz davno nepouzivam jako dvojnasobek velikosti RAM. Prijde mi to
>> zbytecne.
>
> Chci mit po celou dobu zivotnosti stroje moznost ziskat core-dump. Coz
> vyzaduje swap nejmene velikosti fyzicke pameti. A pocitam s moznosti, ze
> by se behem zivotnosti stroje mohla nejaka pamet pridavat.

Tohle mi bylo ve tvem pripade jasne, proto jsem psal, ze ja ho nikdy 
nepotreboval (ani nikdo ze zakazniku), ale kdyz ho nekdo chce, musi pak 
mit ten swap dostatecne velky.

>> Kdybych mel na stroji, ktery ma 32GB RAM, udelat 64GB swap,
>
> Cena tohoto "zahozeneho" diskoveho prostoru je 100Kc.

Dokud to je cena za bezne HDD, tak mas samozrejme pravdu, se SSD uz jsme 
zase nekde jinde.

[...]

> Kdyz tohle nezmirorujes a nechas swapy dva samostatny, tak system bude
> mezi ne rozkladat jak cteni tak zapisy.
>
> O moznost vymenovat disk neprijdes, protoze swapoff - a disk jde vymenit
> i bez restartu.

No uz jsem parkrat zazil system, ktery si sem tam neco odlozil do swapu 
a protoze uz pak neuvolnil dostatek pameti, tak swapoff udelat nesel 
(jedine po zastaveni MySQL serveru).
Plus se mi nekolikrat stalo, ze disk ze systemu nahodne zmizel. (na 
entry level serverech celkem bezna zalezitost) Takze tam se mi ten 
mirror opravdu vyplatil i pro zachovani chodu systemu.

Jinak mas samozrejme pravdu a swap na mirroru neni vzdy az tak uplne 
nutny. Opet kazdemu dle jeho chuti :)

Mirek