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

Odpovedet emailem