Když jsem instaloval server, dal jsem tam ext2. Padat to nebude, tak žurnál není potřeba. ext2 je jednoduchý, stabilní a mnoho let prověřený filesystém. O reiserfs jsem slyšel dvě historky o zničení filesystému (jedna z nich byla email.seznam.cz). JFS a XFS jsou natolik komplikované, že jejich korektnost asi nezkontroluje nikdy nikdo. Ext3 se deadlockuje, což uznávají i sami vývojáři: http://www.ussg.iu.edu/hypermail/linux/kernel/0311.0/0758.html
Ne jednou se to stalo kolegovi, disk nesel namountovat atd. tvaril se fakt jako blby sektor a i DD kolabovalo (ve vypisu dd bylo neco o vadnem bloku ... ktery tam teda nebyl) ... stacilo fsck.ext3 , ten poznal ze zurnal je spatny a pouzil zalozni (3 sekundy) a pak to bezelo OK (ani nevite jak byl ten clovek statstny)
(valstnost DD detekovat vadne bloky tam kde nejsou jsem poznal i u meho USB, kde vzdy kdyz nektere (tak 1%)windows 2000 nebo jeden linux (asy diky upravenemu chipsetu) porusi VFAT tak se to jak pro windows tak pro linux tvarilo jako s vadnym sektorem ... no ve win pomohl wipe disk a v linuxu (tam me to zajima nejvic) pomuze prepsat /dev/zero pomoci dd-rescue)
Jinak kdyz se zurnal "poskodi korekne" udela se fsck zkontroluje zalozni a kdyz i to selze udela fsck.ext3 ... jako u ext2 ... ale to se mi stalo pouze pri spatne pameti.
Az budete mit na petine uzemi republiky rozmistene poruznu routery a budete muset v pripade vypadku/havarie instruovat cloveka,ktery tomu nehovi, po telefonu jak se debuguje ext2fs, tak si rozmyslite jeho nasazeni v provozu. Ja pouzivam XFS i kdyz jsem se setkal s problemy i s timto FS, tak je to porad male zlo oproti ext2. Navic oprava na ext2 muze trvat radove nekoli az nekolik desitek minut a to uz muj hw watchdog na routeru davno odpojuje elektrinu a resetuje :-)).
Clanek je pekny a ctivy, ale oproti prvnim dilum serialu je nadpis "SROVNANI ..." nepatricny. Na uvod neco malo obecne, odstavec o ext2 a pak uz jenom FreeBSD, FreeBSD, prip. FreeBSD 5.
Nejvic mi chybi opravdu to srovnani, nejaky kloudny zaver, shrnuti, v cem jsou silne a v cem slabe stranky obou pristupu.
Z toho si Mikuláši nic nedělej tento jev je normální. Ja ho pozoruju už delší dobu na Ronje. Nejlepší je navzájem protichůdné požadavky davu ignorovat a dělat věci podle sebe.
Jo btw jaký jsou ty velikosti těch konstant - jako ta skupina a tak? Já si to nedokážu dost dobře představit kolik čeho tam je.
Jeste bych pripojil poznamku, ze nekdy muze byt lokalita dat taky zlo - konkretne myslim to, ze se system snazi alokovat i-uzly novych souboru ve stejne nebo blizke BG (nebo CG na UFS) jako je i-uzel adresare. Pak totiz dojde k tomu, ze velke adresare (/home) budou mit sve podadresare blizko u sebe, zatimco na dalsi urovni uz to muze byt roztristene. Coz je pomalejsi, protoze jeden proces obvykle pracuje s daty pouze v jednom podadresari /home/<login>.
Jeste hure se toto projevi na LVM (nebo jinych JBOD resenich) - na ftp.linux.cz se mi treba stalo, ze se ISO image prave vysle distribuce sesly na jednom fyzickem disku v ramci LV a ten disk byl pak pretizeny, zatimco ostatni se protacely naprazdno. Nakonec jsem to vyresil tim, ze jsem puvodni LV zrusil, vytvoril novou o velikosti jednoho extentu, a pak postupne po jednom pridaval extenty z jednotlivych disku (cimz jsem efektivne dosahl RAID-0, ale takto jsem to mohl udelat i nad nestejne velkymi disky se zachovanim prokladu).
Videl jsem nejaky patch na ext[23], ktery umoznoval u nekterych adresaru explicitne rict (pomoci extended atributu), ze se nove soubory/adresare zde nemaji alokovat "blizko", ale naopak co nejvic distribuovane.
-Yenya
Zajimave cteni, diky. Bude pristi dil jeste o FS? Urcite by mohlo byt zajimave si precist neco o dalsich filesystemech (XFS, JFS, ReiserFS).
Dalsi zajimavou veci by mohlo byt, jak si ktery FS resi usporadani polozek v adresarich (linearni | hash | neco jineho?) a jaky to ma vliv na operace na adresari (otevirani souboru, vytvoreni noveho souboru, smazani, prejmenovani, razeni vypisu)
Internet Info Root.cz (www.root.cz)
Informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2021 Internet Info, s.r.o. Všechna práva vyhrazena.