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
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
