Disk do maleho servriku

[Dan Lukes]

On 11/06/13 08:39, Miroslav Prýmek:
> treba jenom nacteni kernelu trva asi minutu, coz mi prijde podezrele
> moc. Pritom po nabootovani uz pomoci dd dosahnu ocekavatelne rychlosti
> cteni (neco kolem 12MB/s).

Odhaduju to na otazku velikosti cteneho bloku. Pokud ma flashla 
netrivialni "per request" transakcni naklady je rozdil, jestli si data 
zadas sektor po sektoru, nebo jestli tataz data zadas po 
osmisektorovejch blocich. Osmkrat mene zadosti znamena usetrenych sedm 
transakcnich cekani.

Totez samozrejme plati i pro klasicke disky a chtelo by se rict, ze tam 
by to melo byt jeste horsi protoze se musi cekat prumerne pul otazky 
media nez se sektor dostane k hlave, ale v praxi to diky cache, kterou 
na sobe uz dneska vsechny standardni disky maji bude spis naopak a 
soucet transakcnich zpozdeni pri cteni osmi po sobe jdoucich sektoru 
bude bliz cten osmisektoroveho bloku nez osmi ctenim jednoho sektoru.

USB flash ale v sobe typicky zadnou cache nema, pokud vim.

Netusim jestli je tohle spravny vysvetleni, ale vychazi z toho jakou 
jsou ta zarizenu delana a vysvetluje pozorovany jev, Takze je to 
prinejmensim vysvetleni mozne.

> :) Predpokladam, ze nacitani kernelu je proste sekvencni cteni, takze
> mi prijde divne, ze by to mfsbsd mohlo nejak urychlit. Ledaze by
> proste v loaderu nejak driv preplo USB porty na vetsi rychlost, ale to

No, a to je dalsi moznost. Kernel se nahrava jeste v rezii loaderu, 
kdezto MFS rootimage uz nahrava kernel po handoveru USB z legacy modu. 
Nejsem si sice jistej jestli pri prechodu z legacy modu se taky meni 
rychlost, ja bych skoro byl nachylnej predpokladat, ze ne, ale ruzne 
parametry se pri tom meni a ty na ruzna zpozdeni vliv mit mohou.

> No ale dulezitejsi je jina vec - nevite o nejakych best practices pro
> vytvareni tech ro-root systemu?

Nejjednodussi ? Nebo majici nejake konkretni specialni vlastnosti ?

Pokud to prvni, tak to uz tu padlo. Staci ve fstab oznacit root jako RO 
a zbytek uz system zaridi za tebe - sam vyrobi pametove /var  a /tmp a 
takto nastartovany system uz funguje "normalne".

Pokud chces aby to melo nejake specialni vlastnosti, napriklad abys 
neprisel pri restartu o LOGy, no tak to uz samozrejme chce neco jineho, 
ale co, to se meni v zavislosti na tom jaky specialni vlastnosti od toho 
chces.

> 1. jak nejlip nastavit syslog? Asi by bylo dobry rotovani logu omezit
> jenom na: 1 aktualni + jeden stary gzipovany, zbytek smazat

Zalezi jak mas ty logy velky. Ja se tim obvykle nezabyvam, protoze na 
mem typickem stroji je i v defaltnim nastaveni vseho je celkova velikost 
LOGu dostatecne mala.

Pokud si prejes logy uchovat i pres restart tak ej ovsem nejlepsi proste 
logovat na vzdaleny stroj. Samozrejme s vedomim, ze UDP/syslog je 
nespolehlivy protokol a tu a tam se nejaka ta zprava muze ztratit. Taky 
muzes logovat lokalne i vzdalene a doufat, ze alespon na jednom miste 
vzdycky informaci najdes.

> 2. kdyz na tom stroji bezi vic demonu, kteri si ukladaji nejaka data
> do ruznych mist ve /var, jak to nejlip resit?

Neresit. Nechat MFS cely /var tak jak ti ho pripravi system. Pro vetsinu 
beznejch situaci to staci. Nepredpokladam, ze premejslis o provozu MySQL 
serveru v tomhle prostredi.

Jedinou vyhradou je skutecne udrzba, to jest instalace balickua jejich 
upgrade. No, ja to delam tak, ze tyhle operace delam nad tou flashkou. 
To jest remountuju root na RW, odmountuju MFS /var a pak teprve pridavam 
balicky nebo upgraduju. Skutecny obsah /var/db/pkg/ je tak perzistentni, 
byt' za normalniho provozu neviditelny (protoze prekryty MFS) coz ale 
nicemu nevadi.

Pridavani balicku a upgrade neni bezna provozni operace, takze ten 
trochu slozitejsi postup tolik nevadi.

Samozrejme, zalezi co na tom provozujes a jak to neco ten /var pouziva a 
jak moc tomu vadi, kdyz o jeho obsah prijde.

Na druhou stranu, programy, kterejm by vadilo, ze prijdou o obsah /var 
asi stejne na tento typ stroje nepatri (protoze s MFS muzou o obsah /var 
prijit kdykoliv tak jako tak).

> 3. nevite o nejakem seznamu, ktery soft se snazi zapisovat do rootu a
> je potreba si na to dat pozor? (jako napr. /etc/dumpdates,
> /etc/resolv.conf pri zapnutem DHCP apod.)

K tomu co jsi zminil me napada uz jen /etc/rc/motd

Ale pro vsechny tyhle veci plati, ze kdyz je zihgnorujes, to nejhorsi co 
te podka budou tu a tam nejake varovne hlasky, ze kdosi nemuze psat 
kamsi. Ty sice obtezuji, takze asi nakonec udelas neco aby zmizely, ale 
provoz stroje nenarusuji, takze se nestane nic hroznyho, kdyz na neco 
zapomenes.

> 4. na jake dalsi veci si dat pozor?

Nic me nenapada. Snad jen - mame radu stroju, kde je nad flashkou z 
nejakeho duvodu straslive pomale prepnuti z RW do RO. Kdyz rikam 
straslive pomale, myslim tim radove minuty. A behem nich stoji cely 
diskovy subsystem a tudiz vsechny procesy, ktere se pokusi pracovat s 
soubory.

Za normalniho proozu to problem neni (nedavas root RW tudiz ho ani 
neprepinas zpet do RO), problem to muze byt prave po update balicku - at 
uz se rozhodnes pro restart (i pri nem se provadi RW->RO prechod) nebo 
to do provozniho stavu vracis rucne.

Nestava se to na vsech strojich, je to zrejme otazka konkretni kombinace 
radice a typu flashky, ale tam kde se to stava to cloveka muze zmast, 
kdyz to nezna. Ten stroj proste dve minuty vypada jak kdyz se uplne zadrel.

Dan