[FreeBSD] Nehany hir
Miklos Niedermayer
mico at bsd.hu
2001. Már. 14., Sze, 20:34:11 CET
Hello!
On Mon, Mar 12, 2001 at 05:02:40PM +0100, Adam Szilveszter wrote:
[...]
> Asszem a fejlesztok ismet megmutattak, a konkurrencia jegyzetelhet. De az
> 5.0 meg nagyon soka lesz kesz, mert borzasztoan instabil idonkent.
>
> Erdemes ra varni!
Ami viszont nagyon hamarosan itt lesz, az a 4.3-RELEASE. Koveted
a 4.3-BETA esemenyeket?
Kezdjuk.
Az ATA33/66/100 diszkek teljesitmenye hihetetlenul visszaesett, miutan
most mar defaultbol le van tiltva ezeknek az eszkozoknek a hardveres irasi
gyorstara. (Engedelyezni az ATA_ENABLE_WC opcioval lehet.) Ez azert van,
mert adatveszteshez vezethet aramkimaradaskor, sokkal komolyabb adatveszteshez,
mint ha async modon mountolnank a filerendszert, vagy akarmi. Igazabol
ugy kellene mukodnie, mint SCSI-nel, hogy ha a filerendszer azt mondja, hogy
'sync', akkor a diszkek is kiuritik a gyorstaraikat. ATA-nal is van erre
egy parancs, de sajnos ket oka is van, ami miatt ezt a fenti szomoru lepest
meg kellett tenni:
1) Soren hasznalta a driverben ezt a kiuritesi parancsot, de komplikaciok
miatt nem tokeletes. Azaz, az oprendszer igazabol nem mondja meg a
drivernek, hogy mikor kell ezt a parancsot hasznalni. Ezzel vegul is
nem volt gond, mert ki lehetett trukkozni, viszont softupdates-nel mar
abszolut nem tudta ...
2) ...ugyanis a softupdates azt varja el, hogy minden iras, ami tole kijon,
az diszkre is kerul. Erre epul az egesz softupdates. Ha utana meg
bejatszik egy cache, az elveszi az egesz ertelmet.
3) Igen, igen, de a vinyo sajat cache memoriaja az hardveres, kicsi es
megbizhato, nem? Nem. Vannak mindenfele almok, pl. aramszunetkor
kiirja egy specialis utolso savba a cache tartalmat; vagy a diszk
leporgesekor a motorban keletkezo indukalt aramot hasznalja fel, hogy
a fejek kiirjak a cache-t; stb., de a guruk inkabb arrol szamolnak be,
hogy az IDE vinyok 95%-anak az irasi gyorsitotara "broken design".
Tobben mondtak, hogy olyat tapasztaltak, hogy irassal leterhelt
diszken meg 10 perc mulva sem hajtott vegre valamilyen parancsot.
**Ez ertelmetlenne teszi a softupdatest, ami most mar a GENERIC
kernelben jon, sot, nemcsak hogy ertelmetlenne, de nagyon veszelyesse
is**. Mint mondtam, a softupdates azzal sakkozik, hogy egyfajta
'majdnem-async' modban futtatja a filerendszert, ahol azokat az adatokat
irja ki, de azokat feltetlenul, amelyekre szukseg van a konzisztencia
fenntartasahoz. Es arra epit, hogy azok ki is irodnak. Ha ez teljesul,
akkor egy nagyon biztonsagos, es jo teljesitmenyu filerendszert ad.
Ha viszont azt a nehany muveletet nem irja ki a hardver, akkor eleg
nagy baj lehet. Bizony voltak anyazasok, hogy az embernek meg akar
async opcioval mountolt opcioval is, fogta es kikapcsolta a gepet
es nem lett semmi baja, mig a biztonsagosnak kikialtott softupdates-t
ha hasznalta, es ugy kapcsolta ki a gepet, az fsck nagyon csunya
hibakkal jott elo... igen, a diszkje nem irta ki a cache tartalmat.
Ilyet en is tapasztaltam, ezek utan udvozlom ezt a lepest a megbizhatosag
jegyeben, kar, hogy tenyleg a teljesitmeny rovasara megy.
Tovabblepve:
- DUMMYNET hihetetlen erdekes panic-okat okozott, szerencsere kijavitottak.
- Most epp a vn driverrel megy a szivas: rebootol.
- Ami mar nem 4.3-, hanem 4.x-specifikus, de mostanaban latom egyre tobb
embernel elojonni: a 4.x-ben mar nincs tamogatas arra, hogy kimappeljuk
egy bad sectoros vinyo hibas reszeit. A hozzaallas az, hogy a mai diszkek
ezt maguknak csinaljak meg, es amelyik diszk mar annyira szar, hogy nem tud
lefoglalni tobb szabadon jaro szektort, az mar annyira szar, hogy ugyis
tonkre fog menni.
- megjelent a KERNCONF parameter (illetve valtozott, vagy miszosz, na)
Tehat az upgrade most igy nez ki:
# (cvsup)
# make world
# make kernel KERNCONF=valami
# mergemaster
# reboot
- az is erdekes volt, amikor Jordan mar megint a sajat gepere nem tudta
telepiteni / elinditani a FreeBSD-t. Most kb. ilyen szinten vannak bugok...
Valahogy a jail kornyeken is mintha eleg sok baj lenne.
Na csa, nagyjabol ennyi.
Udv
Mico
További információk a(z) BSD levelezőlistáról