FreeBSD softupdates

Fórumok

FreeBSD softupdates

Hozzászólások

Most kezdek ismerkedni a FreeBSD-vel, és partícionálásnál lehet olyat választani, hogy softupdates. Elmondaná valaki, hogy ez mit is jelent?

Ez valami olyasmi, mint a naplózó fájlrendszer, csak nem vesztesz sebességet. Legalábbis, ha nem tévedek nagyot. Egy hardcore bsd-s kijavíthatna

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html

Ha FreeBSD-t szeretnél használni, akkor a legjobb, ha a Handbookkal kezded

Softupdates: egy memory cache-t használ a meta-data update-ekre, amit aztán
adott idő után ír ki a diszkre, "csoportosítva". Az fs mindig konzisztens állapotban van.
Tehát olyasmi, mint a naplózó fs, csak gyorsabb ofkoz, mivel a metaadatot csak
egyszer írja ki.

[Vili]

A fajlrendszerben tarolt nem ´tenyleges adat´ az un. meta-data. Inode infok, konyvtarak, etc, etc. Tehat az az adat, ami az fs felepiteset, szerkezetet irja le. Annak idejen ugye volt 2fele hozzallas. Sync, es async frissites. A sync mindent rogton irt vasra, igy ha elszallt a gep, akkor egy file tartalma vagy teljesen kiirodott, vagy 0 lett a vege. Persze mondhatni, hogy a lenyeg esetleg igyis elveszett, de a ´meta-data´ nem serult, az fs ep maradt. Viszont mivel igy mindig meg kell varni, hogy fizikailag kiirja a lenyeget, igy egy nagyobb lemezmuvelet (pl rm -rf kernelforrasra) igencsak megfogja a gepet. Aztan jottek az async megoldasok, mint pl az ext2 alapertelmezesben. Az fs modositasai elobb memoriaban tarolodnak, es csak kesobb kerulnek vasra, igy ha beficcen egy aramszunet, akkor vagy sikerul utana rendberaknia az fsck-nak, vagy nem, es akkor marad az ujraformazas. Persze gyorsnak gyors, csak nem tul egeszseges, mert semmi se garantalja, hogy miutan felallt a rendszer, az fs hasznalhato maradt. A fenti problemara, miszerint sebesseg is kene, es garancia is az fs serules ellen, alapvetoen 2 megoldast agyaltak ki az okosok. Az egyik a naplozas, ami lenyegeben olyan, mintha sima sync lenne az fs, csak ezt egy meghatarozott kis teruleten vegzi, ugy nem kell osszevissza ugralnia a fejnek (es persze csak a meta-data-ra vonatkozik, kedvenc mp3-aid nem fogja naplozni ;). Hatranya, hogy minden modositast 2x ir ki, viszont, ha az elektromos muveknel kirugjak a dugot a falbol, akkor reboot utan csak siman kiirja, amit a ´logban´-ban talal, es minden szep, es jo. Elonye, hogy tul sok cifrazast nem igenyel kod szinten, igy elvileg keves buglehetoseg van. Es vegul itt a kis kedvenc, a soft-updates :). Itt a fuggosegeken van a hangsuly. Itt is minden bufferbe irodik eloszor, akarcsak egy mezei async fs-nel, de a kod megfelelo sorrendben vegzi a kiirast, igy ha esetleg valami lemarad (pl egy file mar ki van irva vasra, csak a konyvtar nem tud rola, hogy az hozza tartozik), akkor azt a kov fsck siman felszabaditja, mivel nem talal ra utalast. Crash utan igy az fsck-nak 1 dolga van: felszabaditani az olyan teruleteket, amik ´hasznalt´-nak vannak jelezve, pedig senki se tud roluk. Sebessegben papiron igy gyorsabb, mint 1 naplozo fs, viszont bonyibb a kod a sok ´fuggosegvizsgalat´ miatt, s igy tobb a hibalehetoseg. 5.0-as fbsd-ben mar van ´background fsck´, tehat crash utan mar nem kell megvarni azt a par masodpercet, amig kitakarit. Mivel maga az fs szerkezete nem serult, igy a tevesen lefoglalt teruletek felszabaditasa raer kicsit kesobb is, max annyi fordulhat elo, hogy boot utan kevesebb hely latszik, mint par perc mulva :). Nah, kb ennyi.

Korrekt. +1 info: ha softupdates-et hasznalsz,
a _fizikailag_ szabad terulet a diszken erdekesen
viselkedhet: pl hely kell, letorolsz egy bohom nagy filet,
viszont azt latod, hogy nem lett tobb hely...
mivel a metadata meg a memory cache-ben van!
Akar 1/2-1 perc is lehet, mire a "valos" allapotot
latod viszont... )

[Vili]

Én már jártam így. Kerestem hol a hely, df -h hely alszik 0% szabad. Á, mondom ez nem lehet, kis idő múlva megnéztem, és mindjárt ott volt 3GB szabad hely . De akkor nem tudtam, hogy ez ettől van. Köszi, így már világos