11. Fejezet - Beállítás és finomhangolás

Amikor a bsdlabel(8) vagy a sysinstall(8) segítségével állományrendszereket telepítünk, nem szabad figyelmen kívül hagynunk a tényt, hogy a merevlemezes egységekben a külsõ sávokból gyorsabban lehet hozzáférni az adatokhoz, mint a belsõkbõl. Emiatt a kisebb és gyakrabban elérni kívánt állományrendszereket a meghajtó lemezének külsejéhez közel kell létrehozni, míg például a /usr partícióhoz hasonló nagyobb partíciókat annak belsõ része felé. A partíciókat a következõ sorrendben érdemes kialakítani: gyökér (rendszerindító), lapozóállomány, /var és /usr.

A /var méretének tükröznie kell a számítógép szándékolt használatát. A /var partíción foglalnak helyet a felhasználók postaládái, a naplóállományok és a nyomtatási sorok. A postaládák és a naplóállományok egészen váratlan mértékben is képesek megnövekedni attól függõen, hogy mennyi felhasználónk van a rendszerben és hogy mekkora naplókat tartunk meg. Itt a legtöbb felhasználónak soha nem lesz szüksége egy gigabyte-nál több helyre.

A /usr partíció tartalmaz számos, a rendszer mûködéséhez elengedhetetlenül fontos állományt, többek közt a portok gyûjteményét (ajánlott, lásd ports(7)) és a forráskódot (választható). A portok és az alaprendszer forrásai telepítés során választhatóak, de telepítésük esetén akkor ezen a partíción legalább két gigabyte-nyi hely ajánlott.

Vegyük figyelembe a tárbeli igényeket, amikor megválasztjuk a partíciók méretét. Igen kellemetlen lehet, amikor úgy futunk ki az egyik partíción a szabad helybõl, hogy a másikat alig használjuk.

Általános szabály, hogy a lapozóállományt tároló partíció mérete legyen a rendszer fizikai memóriájának (RAM) kétszerese. Például, ha a számítógépünk 128 megabyte memóriával rendelkezik, akkor a lapozóállomány méretének 256 megabyte-nak kell lennie. Az ennél kevesebb memóriát maguknak tudó rendszerek több lapozóállománnyal jobban teljesítenek. 256 megabyte-nál kevesebb lapozóállományt semmiképpen sem ajánlunk, és inkább a fizikai memóriát érdemes bõvítenünk. A rendszermag virtuális memóriát kezelõ lapozási algoritmusait úgy állították be, hogy abban az esetben teljesítsenek a legjobban, ha a lapozóállomány mérete legalább kétszerese a központi memória mennyiségének. A túl kicsi lapozóállomány beállítása rontja a virtuális memória lapkeresésési rutinjának hatékonyságát és a memória bõvítése esetén még további gondokat is okozhat.

A több SCSI-lemezzel (vagy a különbözõ vezérlõkre csatlakoztatott több IDE-lemezzel) bíró nagyobb rendszerek esetében érdemes minden egyes (de legfeljebb négy) meghajtóra beállítani lapozóállományt. A lapozóállományoknak közel azonos méretûnek kell lenniük. A rendszermag tetszõleges méretûeket képes kezelni, azonban a belsejében alkalmazott adatszerkezetek a legnagyobb lapozóállomány méretének négyszereséig képesek növekedni. Ha a lapozóállományokat nagyjából ugyanazon a méreten tartjuk, akkor a rendszermag képes lesz a lapozáshoz felhasznált területet optimálisan elosztani a lemezek között. A nagyobb lapozóállományok használata még akkor is jól jön, ha nem is használjuk annyira. Segítségével sokkal könnyebben talpra tudunk állni egy elszabadult program tombolásából, és nem kell rögtön újraindítanunk a rendszert.

Egyes felhasználók úgy gondolják, hogy egyetlen nagyobb méretû partíció mindenre megfelel, ám ez a gondolat több okból is helytelennek tekinthetõ. Elõször is, minden egyes partíciónak eltér a mûködési jellemzõje, és különválasztásukkal lehetõvé válik az állományrendszerek megfelelõ behangolása. Például a rendszerindításhoz használt és a /usr partíciókat többségében csak olvasásra használják, és nem sokat írnak rájuk. Eközben a /var és /var/tmp könyvtárakban zajlik az írások és olvasások túlnyomó része.

A rendszer megfelelõ felosztásával a kisebb, intenzívebben írt partíciókon megjelenõ töredezettség nem szivárog át a többségében csak olvasásra használt partíciókra. Ha a sokat írt partíciókat közel tartjuk a lemez széléhez, akkor azokon a partíciókon növekszik az I/O teljesítménye, ahol az a leggyakrabban megjelenik. Mivel mostanság az I/O teljesítményére inkább a nagyobb partíciók esetén van szükség, azzal nem érünk el ebben különösebb mértékû növekedést, ha a /var partíciót a lemez szélére toljuk. Befejezésképpen hozzátesszük, hogy ennek vannak biztonsági megfontolásai is. Egy kisebb és takarosabb rendszerindító partíció, ami többnyire írásvédett, nagyobb eséllyel él túl egy csúfos rendszerösszeomlást.

Sajnos még mindig sok olyan gyártó akad, akik a nyílt forrású közösség számára nem adják ki a meghajtóik mûködésének alapjait, mivel az ilyen adatokat szakmai titoknak tekintik. Ebbõl következik, hogy a FreeBSD és más operációs rendszerek fejlesztõi számára két választás marad: vagy a gyári meghajtók visszafejtésének hosszú és fájdalmas útján haladva fejlesztik ki a saját meghajtójukat, vagy pedig a Microsoft® Windows® platformra kiadott meghajtók binárisait hasznosítják. A legtöbb fejlesztõ, köztük a FreeBSD fejlesztõi is, ez utóbbi megközelítést választották.

Bill Paul (wpaul) jóvoltából a FreeBSD 5.3-RELEASE változatában megjelent a "Network Driver Interface Specification" (NDIS, avagy hálózati meghajtók szabványos felülete) "natív" támogatása. A FreeBSD NDISulator (másnéven Project Evil, a Gonosz terve) nevû komponense fog egy Windows®-os meghajtót és elhiteti vele, hogy a Windows® operációs rendszerrel kommunikál. Mivel az ndis(4) meghajtó Windows® binárisokat használ fel, ezért csak i386 és amd64 rendszerek esetén érhetõ el.

Az NDISulator használatához három tényezõre van szükségünk:

Keressük meg az említett állományokat az adott kártyához. Ezeket általában a mellékelt CD-n vagy a gyártó honlapján találjuk meg. A most következõ példákban a W32DRIVER.SYS és a W32DRIVER.INF neveket fogjuk használni.

A következõ lépés a meghajtó binárisainak betölthetõ modulba fordítása. Ennek eléréséhez használjuk az ndisgen(8) parancsot a root felhasználóval:

Az ndisgen(8) egy interaktív segédprogram, amely mûködése közben még rákérdez néhány szükséges információra. Az aktuális könyvtárban létrehoz egy rendszermagmodult, amelyet az alábbi módon tudunk betölteni:

Az elõállított modul mellé be kell töltenünk még az ndis.ko és az if_ndis.ko modulokat is. Ez általában minden olyan modul esetén megtörténik magától, amely függ az ndis(4) használatától. Kézileg a következõ parancsokkal tudjuk ezeket betölteni:

Itt az elsõ parancs betölti az NDIS miniport meghajtó burkolására szánt kódot, valamint a második a tényleges hálózati csatolófelületet.

Most pedig a dmesg(8) kimenetében ellenõrizzük, hogy történt-e valamilyen hiba a betöltés során. Ha minden jól ment, akkor az alábbiakhoz hasonló kimenetet produkált:

Innentõl kezdve az ndis0 nevû eszközt úgy tudjuk használni, mint bármelyik más hálózati felületet (például dc0).

A többi modulhoz hasonló módon be tudjuk állítani, hogy a rendszer indulásával együtt betöltõdjenek az NDIS modulok. Ehhez elõször másoljuk az imént létrehozott modult, az W32DRIVER_SYS.ko állományt a /boot/modules könyvtárba. Ezután adjuk hozzá a következõ sort a /boot/loader.conf állomány tartalmához:

Az Ethernet kártyák helyes beállításának vizsgálatához két dolgot kell kipróbálnunk. Elõször is pingeljük magát a felületet, majd ezután pingeljünk meg a helyi hálózaton egy másik számítógépet.

Elsõként tehát próbáljuk meg a helyi felületet:

Most pedig pingeljünk meg egy másik számítógépet a helyi hálózaton:

Ha beállítottuk az /etc/hosts állományt, akkor a 192.168.1.2 helyett a gép nevét is megadhatjuk.

A hardverek és szoftverek beállításaiban mindig is valódi kín megtalálni a hibákat, és ezeket a kínokat többnyire úgy tudjuk enyhíteni, ha elõször az egyszerû hibaforrásokat szûrjük ki. Csatlakoztattuk a hálózati kábelt? Tisztességesen beállítottuk a hálózati szolgáltatásokat? Jól állítottuk be a tûzfalat? A FreeBSD képes kezelni a kártyát? A hibajelentések elküldése elõtt mindig bújjuk át a támogatott hardvereszközök listáját. A FreeBSD verziókat frissítsük a legújabb STABLE változatra. Olvassuk át a levelezési listák archívumait vagy legalább keressünk rá a témára az interneten.

Ha a kártya mûködik, de a teljesítménye nem kielégítõ, érdemes ennek utánanézni a tuning(7) man oldalon. Ilyenkor érdemes ellenõrizni a hálózati beállításainkat is, mivel a helytelen beállítások gyakran okoznak teljesítményvesztést.

Bizonyos esetekben láthatunk egy vagy két device timeout típusú hibát is, ami a kártyák egyes fajtáinál elfogadható. Ha azonban folyamatosan megjelennek vagy zavaróvá válnak, érdemes utánanéznünk, hogy az eszköz nem ütközik-e valamelyik másikkal. Mindenképpen gyõzõdjünk meg a kábelek épségérõl és csatlakoztatásáról. Még az is elképzelhetõ, hogy egyszerûen csak egy másik hálózati kártyára van szükségünk.

Néha felbukkanak watchdog timeout jellegû hibák is. Ilyenkor elsõként mindig a hálózati kábelt ellenõrizzük. Egyes kártyáknak olyan PCI foglalatra van szükségük, ami támogatja a Bus Mastering opciót. Néhány régebbi alaplapon csak ilyen PCI bõvítõhely található (ami általában a 0. foglalat). Olvassunk utána a hálózati kártya és az alaplap dokumentációjában, hátha ezek okozzák a problémát.

A No route to host üzenet akkor jelenik meg, ha a rendszer képtelen megállapítani, milyen úton juttassa el a csomagokat a megadott célhoz. Ez többnyire olyankor történik meg, amikor nem adtunk meg alapértelmezett kézbesítési irányt (default route) vagy nem dugtuk be a hálózati kábelt. A netstat -rn kimenetébõl meg tudjuk állapítani, hogy létezik-e érvényes út az elérni kívánt cél felé. Ha nincs, akkor haladjunk tovább a Egyéb haladó hálózati témákre.

A ping: sendto: Permission denied jellegû üzeneteket többségében egy helytelenül beállított tûzfal okozza. Ha az ipfw mûködését engedélyeztük a rendszermagban, de nem adtunk meg hozzá szabályokat, akkor az alapértelmezett házirend szerint minden forgalmat blokkolni fog, tehát még a pingeket is! Ezzel kapcsolatban a Tűzfalak elolvasását ajánljuk.

Elõfordulhat, hogy a kártya teljesítménye igen gyenge vagy az átlagos alatt van. Ilyenkor a fizikai eszköz autoselect (automatikus) típusú kiválasztása helyett érdemes megadnunk a konkrét eszköznek megfelelõ típust. Habár ez a legtöbb hardver esetén beválik, nem mindenki számára jelent megoldást. Ismételten csak annyit tudunk ehhez hozzátenni, hogy ellenõrizzük a hálózati beállításainkat és olvassuk el a tuning(7) man oldalt.

Az /etc/resolv.conf határozza meg, hogy a FreeBSD névfeloldója miként fér hozzá az internet tartománynév rendszeréhez (a DNS-hez).

Az resolv.conf állományban leggyakrabban a következõ bejegyzések fordulnak elõ:

Egy átlagos resolv.conf tartalma:

A DHCP használatakor a dhclient(8) felül szokta írni a resolv.conf tartalmát a DHCP szervertõl kapott információkkal.

Az /etc/hosts az internet kezdeti napjaira emlékeztetõ egyszerû szöveges adatbázis. A nevek és IP-címek közti leképzéseket a DNS és NIS rendszerekkel karöltve oldja fel. Ide a helyi hálózaton csatlakozó számítógépek neveit lehet beírni ahelyett, hogy erre a célra beállítanánk egy külön named(8) szervert. Ezenkívül még az /etc/hosts állományba internetes nevek rekordját is felvehetjük, amivel így csökkenthetjük a gyakran használt nevek feloldására irányuló külsõ kéréseket.

Az /etc/hosts formai felépítése igen egyszerû:

Tehát például:

A részletekért keressük fel a hosts(5) man oldalt.

A syslog.conf állomány a syslogd(8) program beállításait tartalmazza. Segítségével megadhatjuk, hogy a syslog által generált üzenetek egyes típusait milyen naplóállományokba mentsük.

A syslog.conf(5) man oldalának elolvasásával tudhatunk meg többet ezekrõl.

A newsyslog.conf a newsyslog(8) beállításait tároló állomány. Ez egy olyan program, amelyet általában a cron(8) futtat le. A newsyslog(8) dönti el, hogy mikor van szükség a naplók archiválására és átrendezésére. Ennek során a logfile állományból logfile.0 lesz, a logfile.0 állományból pedig logfile.1 és így tovább. Beállíthatjuk úgy is, hogy a naplóállományokat archiválja gzip(1) formátumban, aminek megfelelõen ezek logfile.0.gz, logfile.1.gz és ehhez hasonló névvel jönnek létre.

A newsyslog.conf megadja, hogy melyik naplóállományokat kell felügyelni, mennyi példányt tartsunk meg belõlük és mikor kell velük foglalkozni. A naplóállományok átrendezhetõek és/vagy archiválhatóak egy adott méret elérésekor vagy egy adott idõ eltelte után.

További információkat a newsyslog(8) man oldaláról nyerhetünk.

A vfs.vmiodirenable sysctl változó értéke lehet 0 (ki) vagy 1 (be, és ez az alapértelmezés is). Ez a változó vezérli a könyvtárak gyorsítótárazását a rendszerben. A könyvtárak többsége kis méretû, így az állományrendszerbõl csak egyetlen (általában 1 KB méretû) darabkát használnak és még ennél is kevesebbet (általában 512 byte-ot) a pufferben. A változó kikapcsolt (avagy 0) értéke mellett a puffer csak rögzített számú könyvtárat táraz be még abban az esetben is, amikor temérdek mennyiségû memória áll a rendelkezésére. Ha viszont (az 1 értékkel) engedélyezzük, akkor a rendszer a könyvtárak tárazására felhasználja a virtuális memóriában pufferelt lapokat is, amivel lényegében az összes elérhetõ memóriát a könyvtárak tárazására fordítja. Ilyenkor azonban az egyes könyvtárak tárazására használt legkisebb memóriaterület a fizikai lapmérettel egyezik meg (ami általában 4 KB) és nem 512 byte. Abban az esetben javasoljuk ennek a beállításnak a használatát, ha olyan szolgáltatásokkal dolgozunk, amelyek nagy számú állománnyal dolgoznak egyszerre. Ilyen szolgáltatások többek közt a webes gyorsítótárak, nagyobb levelezõrendszerek és hírrendszerek. Az opció engedélyezése alapvetõen nem veti vissza a rendszer teljesítményét még akkor sem, ha ezzel memóriát pazarlunk el, de ezt igazából érdemes kikísérletezni.

A vfs.write_behind sysctl változó alapértelmezett értéke 1 (bekapcsolt). Ez arra utasítja az állományrendszert, hogy csak akkor küldje ki az adatokat az eszközre, ha belõlük teljes fürtök gyûltek össze. Ez jellemzõ módon nagyobb szekvenciális állományok írása esetén kedvezõ. Arra szolgál, hogy segítségével el lehessen kerülni az I/O túlságosan gyakori módosítások okozta terhelését. Bizonyos körülmények közt ez azonban lassíthatja a futó programok mûködését, ezért ilyenkor érdemes megfontolni a kikapcsolását.

A vfs.hirunningspace sysctl változó értéke azt adja meg, hogy tetszõleges számú példánynál rendszerszinten mekkora mértékû írási mûvelet irányítható át a lemezvezérlõk soraiba. Az alapértelmezés többnyire elegendõ, de olyan gépeken, ahol sok lemez dolgozik egyszerre, ez az érték négy vagy öt megabyte-ra is felszökhet! Hozzátennénk, hogy ha ezt az értéket túlságosan nagyra állítjuk (és így túllépjük a puffer írási küszöbértékét), akkor ezzel hihetetlenül gyenge fürtözési teljesítményt nyerünk. Semmiképp se állítsuk túlzottan nagy értékre! A nagyobb írási értékek a velük párhuzamos olvasások számára késleltetést is jelentenek.

Találhatunk még más egyéb pufferelési és gyorsítótárazási sysctl változókat, azonban ezek megváltoztatását egyáltalán nem javasoljuk, mivel a virtuális memória alrendszer kiválóan tudja önállóan állítani ezeket a paramétereit.

A vm.swap_idle_enabled sysctl változó módosítása olyan nagyobb többfelhasználós rendszerekben bizonyulhat hasznosnak, ahol sok felhasználó lép be és lép ki a rendszerbe és sok az üresjáratban futó program. Az ilyen jellegû rendszerek hajlamosak nagy mennyiségû folyamatos terhelést mérni a tartalékolt szabad memóriára. A beállítás engedélyezésével, valamint a vm.swap_idle_threshold1 és a vm.swap_idle_threshold2 változókon keresztül a kilapozás "reakcióidejének" alkalmas behangolásával a megszokottnál gyorsabban lenyomhatjuk az üresjáratban dolgozó programokhoz tartozó memórialapok prioritását, amivel a kilapozásokat vezérlõ démon kezére játszunk. Azonban tényleg csak akkor engedélyezzük ezt a lehetõséget, ha valóban szükségünk van rá, mivel így a memóriát jóval elõbb lapozzuk ki és ezzel több lapozóállományt és lemezteljesítményt emésztünk fel. Kisebb rendszerekben jól behatárolható a hatása, azonban a nagyobb rendszerekben, ahol már eleve visszafogott mértékû lapozás történik, ez a beállítás lehetõvé teszi a virtuális memóriát kezelõ alrendszer számára, hogy könnyedén ki- és be rakosgasson komplett futó programokat a memóriába.

A FreeBSD 4.3 egyszer már kacérkodott az IDE-lemezek írási pufferének kikapcsolásával. Ez ugyan csökkentette az IDE-lemezek írási sávszélességét, azonban bizonyos merevlemezgyártók gondatlanságából eredõ súlyos adatvesztések miatt szükséges volt a használata. A gond ezzel kapcsolatban ott van, hogy egyes IDE-meghajtók hazudnak az írások teljesítésérõl. A lemezek írási gyorsítótárazásának bekapcsolásával az IDE-meghajtók nem csak az írások sorrendjét rendezik át, hanem nagyobb terhelés esetén egyes blokkokat jóval késõbb is rögzítenek. Ezért a rendszer esetleges összeomlása vagy egy áramkimaradás súlyos károkat okozhat az állományrendszerben. A FreeBSD úgy döntött, hogy a megbízhatóságot választja. Sajnos ez olyan nagyságú teljesítményvesztést okozott, hogy a következõ kiadásban már kénytelenek voltunk alapértelmezés szerint is visszakapcsolni ezt a lehetõséget. A hw.ata.wc nevû sysctl változó vizsgálatával ellenõrizhetjük a rendszerünkön érvényes alapértelmezett beállítást. Amennyiben az IDE írások gyorsítótárazása nem engedélyezett, akkor ezt a változó értékének 1-re állításával állíthatjuk vissza. Ezt a rendszer indításakor a rendszerbetöltõben tehetjük meg. A rendszermag indítása után ennek már nincs hatása.

A részleteket a ata(4) man oldalon tudhatjuk meg.

A rendszermag SCSI_DELAY nevû beállítása a rendszer indulásának idejét hivatott mérsékelni. Az alapértelmezett értéke viszonylag magas, innen származik a rendszer indítása során keletkezõ 15 másodperces csúszás. Általában az is megfelelõ, ha ezt visszavesszük az 5 értékre (fõleg a modernebb meghajtók számára). A FreeBSD újabb (5.0 vagy késõbbi) változataiban ez az érték már a kern.cam.scsi_delay sysctl változó értékével is megadható a rendszer indításakor. Azonban ügyeljünk rá, hogy mind a finomhangoláshoz használt változó, mind pedig rendszermag beállítása ezredmásodpercben és nemmásodpercben értelmezi ezt az értéket.

Két hagyományos megközelítés létezik az állományrendszerek metaadatainak visszaírására. (A metaadatok módosításakor olyan nem adatot tartalmazó blokkok változnak meg, mint például az állományokra vonatkozó információk vagy a könyvtárak.)

Eredetileg alapértelmezés szerint a metaadatok változásait szinkron módon írták ki. Amikor egy könyvtár megváltozott, a rendszer egészen addig várt, amíg ez a változás a lemezre nem íródott. Ugyanekkor az állományok adatait tartalmazó pufferek (az állományok tartalma) átkerültek a pufferelt gyorsítótárba, hogy majd késõbb, aszinkron módon kerüljenek kiírásra. Ennek az implementációnak a biztonságos mûködés volt az elõnye, mivel így a metaadatok még akkor is konzisztens állapotban maradtak, amikor valamilyen hiba következett be. Tehát egy állomány vagy teljesen létrejött vagy egyáltalán nem. Ha az állományhoz tartozó blokkok már nem tudtak kijutni a gyorsítótárból az összeomlás ideje elõtt, akkor az fsck(8) felismerte ezt a helyzetet és az állományrendszer ilyen jellegû hibáját úgy orvosolta, hogy az adott állomány méretét nullára állította. Ezenkívül még az implementációs részletek is tiszták és egyszerûek maradtak. Ennek viszont hátránya, hogy a metaadatok kezelése lassú. Ha például kiadunk egy rm -r parancsot, akkor az a könyvtárban levõ állományokat szekvenciálisan dolgozza fel, de minden egyes változtatást (az állományok törlését) csak szinkron módon rögzíti a lemezre. Ezek a frissítések érintik magát a könyvtárat, az állományokkal kapcsolatos információkat tároló táblázatot (az ún. inode táblát) és minden valószínûség szerint az állományok által lefoglalt blokkokat is közvetve. Hasonló megfontolások élnek a nagyobb könyvtárszerkezetek kibontása esetén is (tar -x).

A második lehetõség a metaadatok aszinkron frissítése. Ez az alapértelmezés a Linux ext2fs és BSD-k mount -o async opcióval csatlakoztatott UFS állományrendszerei esetén. Ilyenkor minden metaadattal kapcsolatos aktualizálás egyszerûen bekerült a pufferelt gyorsítótárba, tehát az állományok adatai és ezek a típusú frissítések keverednek. Ennek a megvalósításnak az az elõnye, hogy nem kell megvárni, amíg a metaadatok is kiíródnak a lemezre, ezért a metaadatok óriási mennyiségû változásával járó mûveletek sokkal gyorsabban hajtódnak végre, mint a szinkron esetben. Sõt, maga az implementáció is tiszta és egyszerû marad, ezért a kódban megjelenõ hibák beszivárgásának kockázata alacsony. A módszer hátránya, hogy egyáltalán semmilyen garanciát nem kapunk az állományrendszer konzisztenciájára. Ha tehát egy rengeteg metaadat megváltozásával együttjáró mûvelet közben történik valamilyen probléma (áramkimaradás, vagy valaki egyszerûen megnyomja a reset gombot), akkor az állományrendszer elõre kiszámíthatatlan állapotba kerül. A rendszer újbóli indításakor ezért nincs lehetõségünk megvizsgálni az állományrendszer állapotát. Elképzelhetõ, hogy az állományokhoz tartozó adatok már kikerültek a lemezre, miközben a rá vonatkozó inode- vagy könyvtári bejegyzések még nem. Így lényegében lehetetlen olyan fsck implementációt készíteni, ami képes lenne eltüntetni ezt a káoszt (hiszen az ehhez szükséges adatok nem állnak rendelkezésre). Ha az állományrendszer helyrehozhatatlanul károsodott, akkor csak a newfs(8) és a biztonsági mentés visszaállítása segíthet rajta.

Ezt általában úgy küszöbölik ki, hogy az egészhez hozzáteszik még a módosított területek feljegyzését, amit gyakran csak naplózásnak (journaling) neveznek, habár ezt az elnevezést nem mindenhol ilyen értelemben használják, ezért a tranzakciók naplózásának más formáira is utalhat. A metaadatok frissítése ebben az esetben is csak szinkron módon történik, de csak a lemez egy kisebb területére. Késõbb ez a megfelelõ helyére kerül. Mivel a lemez naplózásra fordított része egy viszonylag kis méretû, folytonos terület, a lemez fejének még a megterhelõbb mûveletek esetén sem kell sokat mozognia, ezért valójában ez a megoldás gyorsabb, mint a mezei szinkron frissítések. Az implementáció bonyolultsága továbbra is jól behatárolható, a velejáró hibalehetõségek kockázata alacsony. Hátránya, hogy minden metaadat kétszer íródik ki (egyszer a naplózási területre, aztán a megfelelõ helyre), ezért a hétköznapi használat során "visszaesés" tapasztalható a teljesítményben. Másrészrõl azonban egy összeomlás esetén a naplózási terület segítségével minden függõben levõ metaadattal kapcsolatos mûvelet könnyen visszafordítható vagy lezárható a rendszer következõ indításakor, így ezzel egy gyors helyreállítást nyerünk.

Kirk McKusick, a Berkeley FFS fejlesztõje ezt a problémát a Soft Updates segítségével hidalta át: a metaadatokkal kapcsolatos minden függõben levõ frissítést a memóriában tart, majd ezeket rendezett sorrendben írja ki a lemezre ("a metaadatok rendezett frissítése"). Ennek következményeképpen a metaadatok komolyabb frissítése során a késõbb érkezõ módosításoknak lehetõségük van "elkapni" a memóriában levõ korábbi változataikat, ha azok még nem kerültek ki a lemezre. Így az összes, például könyvtárakon végzett, mûvelet a lemezre írás elõtt általában elõször a memóriában játszódik le (az adatblokkok a pozíciójuknak megfelelõen kerülnek rendezésre, ezért a rájuk vonatkozó metaadatok elõtt nem jutnak ki a lemezre). Ha eközben a rendszer összeomlik, akkor így implicit módon a "napló visszalapozását" eredményezi: minden olyan mûvelet, ami már nem tudott kijutni a lemezre, meg nem történtnek számít. Ezen a módon az állományrendszernek egy 30 és 60 másodperc közti korábbi állapota marad fenn. Az algoritmus garantálja, hogy az összes használt erõforrás a nekik megfelelõ bittérképekben helyesen jelölõdik, a blokkokban és az inode-okban. Az összeomlás után az erõforrások kiosztásával kapcsolatban csak egyetlen hiba léphet fel: amikor olyan erõforrások jelölõdnek "használtnak", amelyek igazából "szabadok". Az fsck(8) azonban képes felismerni ezeket a helyzeteket és felszabadítani a nem használt erõforrásokat. A mount -f parancs kiadásával minden további következmény nélkül figyelmen kívül hagyhatjuk az állományrendszer félkész állapotát és csatlakoztathatjuk az állományrendszereket. A használatban már nem levõ erõforrások felszabadításához az fsck(8) parancsot késõbb kell futtatni. Ez az alapötlet húzódik meg a háttérben végzett lemezellenõrzés mögött. A rendszer indításakor az állományrendszernek csupán egy pillanatképét rögzítjük, és az fsck tényleges lefuttatását késõbbre toljuk. Mivel mindegyik állományrendszer csatlakoztatható "félkész" állapotban, ezért a rendszer képes elindulni többfelhasználós módban. Eközben a háttérben az fsck beütemezhetõ minden olyan állományrendszer számára, ahol arra szükség van, hogy szabadítsa fel az esetlegesen már nem használt erõforrásokat. (Így a Soft Updates opciót nem alkalmazó állományrendszerek esetén továbbra is szükség van az elõtérben elvégzett fsck parancsra.)

A módszer elõnye, hogy így a metaadatokkal kapcsolatos mûveletek közel olyan gyorsak, mint az aszinkron módon végzett frissítések (tehát gyorsabb, mintha naplóznánk, ami ugye minden metaadatot kétszer ír ki). A hátránya a bonyolultabb kód (ami miatt növekszik az olyan hibák lehetõsége, amelyek érzékenyen befolyásolhatják a felhasználói adatok elvesztését) és a nagyobb memóriaigény. Ezenkívül még van néhány olyan egyéni jellemzõje, amelyet meg kell szokni. A rendszer összeomlása után az állományrendszer valamivel "régebbi" lesz. Amikor pedig megszokott szinkron megközelítés szerint az fsck lefutása után nulla méretû állományok jönnének létre, ezek az állományok a Soft Updates esetén egyáltalán meg sem jelennek, mivel sem a rájuk vonatkozó metaadatok, sem pedig a tartalmuk nem került ki a lemezre. Egy rm lefuttatása után a lemezterület addig nem kerül felszabadításra, amíg a frissítések teljesen rá nem kerülnek a lemezre. Ez nagyobb mennyiségû adat telepítésekor gondokat okozhat egy olyan állományrendszeren, ahol nincs elegendõ hely az állományok kétszeri tárolására.

A kern.maxfiles értéke a rendszerünk igényeinek megfelelõen növelhetõ vagy csökkenthetõ. Ez a változó adja meg a rendszerünkben levõ állományleírók maximális számát. Amikor az állományleírókat tároló táblázat megtelik, a rendszer üzenetpufferében egy file: table is full üzenet jelenik meg, amit a dmesg paranccsal tudunk megnézni.

Minden megnyitott állomány, csatlakozás vagy FIFO elhasznál egy állományleírót. Egy nagyméretû szerver könnyen felemészthet több ezernyi állományleírót attól függõen, hogy milyen és mennyi szolgáltatást futtat egymás mellett.

A FreeBSD korábbi kiadásaiban a kern.maxfiles a rendszermag beállításait tartalmazó állomány maxusers (a rendszerben egyszerre jelenlevõ felhasználók maximumának) értékébõl származott, tehát a kern.maxfiles a maxusers értékével arányosan növekszik. Amikor készítünk egy saját rendszermagot, mindig érdemes a rendszerünk használatának megfelelõen beállítani ezt az értéket, mivel a rendszermag ebbõl a számból határozza meg a legtöbb elõre meghatározott korlátait. Mivel még egy komoly szerveren sem jelentkeznek be egyszerre 256 felhasználónál többen, nagyjából ugyanannyi erõforrásra van szüksége, mint egy nagyobb webszervernek.

A kern.maxusers értéke a rendelkezésre álló memóriának megfelelõen magától méretezõdik a rendszer indításakor, és amit futás közben csak a kern.maxusers sysctl változó írásvédett értékének lekérdezésébõl tudhatunk meg. Egyes oldalak üzemeltetése a kern.maxusers így megállapított értékétõl nagyobbat vagy éppen kisebbet igényel, ezért a betöltéskor minden gond nélkül át lehet állítani 64, 128 vagy 256 értékûre. Senkinek sem ajánljuk, hogy 256 felé menjen, hacsak tényleg nincs szüksége ekkora mennyiségû állományleíróra. A kern.maxusers függvényében beállított alapértelmezett értékek tetszõleges módon átállíthatóak a rendszer indításakor vagy futás közben a /boot/loader.conf módosításával (az ide kapcsolódó javaslatokról bõvebben lásd a loader.conf(5) man oldalt vagy a /boot/defaults/loader.conf állományt) illetve a leírás más részén megadott módok szerint.

A korábbi kiadásokban úgy lehet önszabályozóra állítani a maxusers beállítást, ha explicit módon 0 értéket adtunk meg neki . A maxusers paraméter beállításakor érdemes legalább 4-et megadni, különösen akkor, ha használjuk az X Window Systemet vagy szoftvereket fordítunk le. Azért van erre szükség, mert a maxusers értéke által szabályozott legfontosabb mennyiség az egyszerre futtatható programok táblázatának maximális mérete, amelyet így számolunk ki: 20 + 16 * maxusers. Tehát ha a maxusers értékét 1-re állítjuk be, akkor az elõbbi képlet értelmében csak 36 programunk futhat egymással párhuzamosan, beleértve mindazt a kb. 18 programot, amelyek a rendszerrel együtt indulnak, illetve még azt a további 15 programot, amelyeket az X Window System használatával indítunk el. Még egy olyan egyszerû dolog is, mint például egy man oldal megnézése, legalább kilenc programot indít el a szûréshez, kitömörítéshez és megnézéshez. Azonban ha a maxusers értékét 64-re állítjuk, akkor egyszerre akár már 1044 programot futtathatunk, ami szinte mindenre elegendõ. Ha persze egy új program indításakor kapunk egy típusú üzenetet vagy nagy számú konkurens felhasználóval futtatunk szervert (ilyen például az ftp.FreeBSD.org), akkor érdemes növelni ezt a számot és újrafordítani a rendszermagot.

Az kern.ipc.somaxconn sysctl változó a beérkezõ TCP kapcsolatokat fogadó sor hosszát határozza meg. Ennek az alapértelmezett értéke 128, ami az új kapcsolatok megbízható kezeléséhez általában kevés egy erõsen leterhelt webszerver számára. Ilyen helyzetekben ezt az értéket javasolt 1024-re vagy még annál is nagyobbra állítani. Az egyes szolgáltatások démonai ugyan szintén korlátozni szokták a fogadósoruk méretét (például a sendmail(8) vagy az Apache), de gyakran találunk a beállításai között olyat, amivel ennek a sornak a mérete növelhetõ. A nagyobb fogadósorok mellesleg jó szolgálatot tesznek a Denial of Service () típusú támadásokkal szemben is.

A net.inet.ip.portrange.* sysctl változók vezérlik a TCP és UDP csatlakozásokhoz automatikusan hozzárendelt portszámok tartományát. Három ilyen tartomány létezik: az alsó, az alapértelmezett és a felsõ tartomány. A legtöbb hálózati program a net.inet.ip.portrange.first és net.inet.ip.portrange.last változók által rendre az 1024-tõl 5000-ig kijelölt alapértelmezett tartományt használja. A kimenõ kapcsolatok is rögzített porttartományokat követnek, és adott körülmények mellett be lehet állítani úgy a rendszerünket, hogy ezen kívül osszon ki portokat. Ez a legtöbbször akkor fordul elõ, amikor egy erõsen leterhelt webproxyt mûködtetünk. A porttartományok nem okoznak gondot olyan szervereknél, ahol általában bejövõ kapcsolatokra lehet számítani, tehát például webszerverek esetén, vagy ahol korlátozott a kimenõ kapcsolatok száma, mint például a levelek továbbításánál. Ha olyan helyzetbe keverednénk, ahol már kifutunk a felhasználható portokból, a net.inet.ip.portrange.last mérsékelt növelésével javasolt kitörni. Ilyenkor a 10000, 20000 vagy 30000 értékek elfogadhatóak. Amikor megváltoztatjuk a porttartományok határait, elõtte mindig gondoljuk át, milyen hatással lehet ez a tûzfalra. Egyes tûzfalak blokkolhatnak bizonyos tartományokat (általában az alacsonyabbakat) és arra számítanak, hogy a rendszerek a kimenõ kapcsolatokhoz a nagyobb számú portokat használják - ebbõl kifolyólag nem ajánlott csökkenteni a net.inet.ip.portrange.first értékét.

A TCP sávszélesség-késleltetés szorzat korlátozása hasonlít a NetBSD-ben megtalálható TCP/Vegas implementációhoz. A net.inet.tcp.inflight.enable sysctl változó 1-re állításával lehet engedélyezni. A rendszer ilyenkor minden egyes kapcsolathoz megpróbálja kiszámítani a sávszélesség-késleltetés szorzatot és az optimális átviteli sebesség fenntartásához illeszkedõen korlátozni a hálózat felé küldött adatok sorának hosszát.

Ez a lehetõség még olyankor bizonyulhat hasznosnak, amikor modemen, Gigabit Etherneten vagy nagysebességû WAN (vagy bármilyen más nagy sávszélesség-késleltetés szorzattal bíró) összeköttetéseken keresztül küldünk át adatokat, különösen abban az esetben, amikor ablakméretezést is használnunk vagy nagy küldési ablakot állítottunk be. Az engedélyezésekor ne felejtsük el net.inet.tcp.infligt.debug változót sem beállítani 0-ra (amivel így kikapcsoljuk a nyomkövetést),éles használat esetén pedig elõnyös lehet a net.inet.cp.inflight.min változót legalább 6144-re állítani. Azonban hozzátesszük, hogy összeköttetéstõl függõen a nagy minimum értékek tulajdonképpen kikapcsolják a sávszélességkorlátozást. Ez a korlátozási lehetõség csökkenti a közbensõ út adatainak és csomagváltásokhoz tartozó soroknak a méretét, miközben csökkenti a helyi számítógép felületén felépülõ sorok méretét is. Ha kevesebb csomagot rakunk be a sorba, akkor az interaktív kapcsolatok, különösen a lassabb modemek esetében, kisebb körbejárási idõvel (Round Trip Time) mûködnek. Továbbá megemlítenénk, hogy ez a lehetõség csak az adatok küldésére (feltöltésére, szerveroldalra) van hatással. Semmilyen befolyása nincs az adatok fogadására (letöltésére).

A net.inet.tcp.inflight.stab állítgatása nem ajánlott. A paraméter értéke alapértelmezés szerint 20, ami legfeljebb 2 csomag hozzáadását jelenti a sávszélesség-késleltetés szorzat ablakának kiszámításakor. Erre a kiegészítõ ablakra azért van szükség, hogy stabilizálni tudjuk vele az algoritmust és javítani tudjuk a változó feltételekre adott reakciót, de lassabb összeköttetések esetében nagyobb ping idõket is eredményezhet (habár ezek még így kisebbek, mint ha nem használnánk az algoritmust). Ilyen esetekben megpróbálhatjuk 15-re, 10-re vagy esetleg 5-re visszavenni a paraméter értékét, de ekkor a kívánt hatás eléréséhez minden bizonnyal a net.inet.tcp.inflight.min értékét is redukálunk kell majd (például 3500-ra). Ezen paraméterek megváltoztatását csak végsõ esetben ajánljuk!

A vnode egy állomány vagy könyvtár belsõ ábrázolása. Ennek megfelelõen a vnode-ok számának növelésével az operációs rendszer spórolni tud a lemezmûveletekkel. Ezt általában maga az operációs rendszer szabályozza, és nincs szükség a finomhangolására. Néhány esetben, amikor a lemezmûveletek jelentik a rendszerben a szûk keresztmetszetet és kezdenek elfogyni a vnode-ok, szükség lehet ennek a számnak a növelésére. Ehhez az inaktív és szabad fizikai memória mennyiségét kell számításba vennünk.

Így kérhetjük le a pillanatnyilag használatban levõ vnode-ok mennyiségét:

Így tudhatjuk meg a vnode-ok maximális számát:

Ha a vnode-ok aktuális kihasználtsága megközelíti a csúcsértéket, nagyjából ezerrel javasolt megnövelni a kern.maxvnodes értékét. Ezután figyeljük továbbra is a vfs.numvnodes változását. Ha ismét felkúszik a maximális értékre, akkor növeljük megint egy keveset a kern.maxvnodes értékén. Eközben a top(1) használatával figyelhetjük a memória kihasználtságának növekedését is, ilyenkor tehát több memóriának kell használatban lennie.

Egyes esetekben felfüggesztett állapotból visszatérve az egerünk nem hajlandó mûködni. Ezt úgy lehet elkerülni, ha /boot/loader.conf állományba beírjuk a hint.psm.0.flags="0x3000" sort. Ha ez nem segít, akkor a fentieknek megfelelõen küldjünk be egy hibajelentést.

Az ACPI három (STR) állapotban képes a fizikai memória segítségével készenléti módba váltani, ezek az S1-S3, és egy állapotban használja a lemezt (STD), amelyet S4-nek hívnak. Az S5 neve a "szoftveres kikapcsolás", ami egy olyan állapotot takar, amikor a rendszerünk áram alatt van, de még nem üzemel. Az S4BIOS állapot a BIOS segítségével a lemezre menti a rendszert, az S4OS állapotot pedig teljes egészében az operációs rendszer valósítja meg.

A rendszerünk által ismert készenléti módokat a sysctl hw.acpi paranccsal ellenõrizhetjük. Íme mindez egy Thinkpad esetén:

Ez azt jelenti, hogy az acpiconf -s parancs kiadásával kipróbálhatjuk az S3, S4OS, és S5 állapotokat. Ha az s4bios értéke egy (1), akkor az S4BIOS támogatása helyett az S4OS állapotot kapjuk.

A felfüggesztés és folytatás kipróbálása során kezdjük az S1 állapottal, már amennyiben az támogatott a rendszerünkön. Ez az állapot többnyire használható, mivel nem igényel túlságosan sok támogatást a meghajtó részérõl. Eddig még senki sem implementálta az S2 állapotot, de ha ezt is tudja a rendszerünk, akkor az S1-hez hasonlót nyerünk vele. A következõ próba az S3 állapoté. Ez a legmélyebb STR állapot, és a hardver megfelelõ újraélesztéséhez rengeteg támogatás szükségeltetik a meghajtó részérõl. Ha gondjaink lennének a rendszerünk felébresztésével, nyugodtan írjunk egy levelet a FreeBSD ACPI levelezési lista listára, ám a probléma gyors megoldódásában ne reménykedjünk, hiszen ehhez még temérdek meghajtón és hardveren kell tesztelni és kell dolgozni.

Felfüggesztés és folytatás esetén gyakori probléma, hogy sok eszközmeghajtó nem menti el, nem állítja vissza vagy éppen nem hozza újra rendesen mûködésbe az adott eszközön található firmware-t, a regisztereket vagy memóriát. Az okok felderítéséhez elõször érdemes a következõket kipróbálni:

Ezzel a módszerrel tesztelni tudjuk az összes meghajtó felfüggesztési és folytatási rutinjait anélkül, hogy ténylegesen S3 állapotba helyeznénk az eszközt. Bizonyos esetekben ezzel könnyen elcsíphetõ a hiba (például a firmware állapotának elvesztése, watchdog time out, megállás nélküli újrapróbálkozások). A rendszer ilyenkor nem vált S3 állapotra, vagyis az eszköz nem kerül energiatakarékos állapotba, és eltérõen a valós S3 állapottól továbbra is mûködik még abban az esetben is, amikor a szükséges felfüggesztési és folytatási rutinok teljesen hiányoznak.

Komolyabb esetben további segédeszközökre lesz szükségünk, vagyis soros portra és kábelre a soros vonali nyomkövetéshez, vagy Firewire portra és kábelre a dcons(4) használatához, valamint némi tapasztalatra a rendszermagon belüli hibakeresésben.

A problémát nagy mértékben segíti különválasztani, ha igyekszünk minél több meghajtót kivenni a rendszermagból. Ha így javul a helyzet, akkor már könnyen le lehet szûkíteni arra a meghajtóra a kört, aminek betöltésével esetleg gondok akadhatnak. Általában ilyenek a bináris meghajtók, mint például az nvidia.ko, az X11 megjelenítésért felelõs és az USB eszközök meghajtói, miközben az Ethernet eszközök remekül szoktak mûködni. Ha különösebb gond nélkül képesek vagyunk betölteni és eltávolítani ezeket a meghajtókat, akkor ezt a folyamatot önállósítani is tudjuk úgy, hogy az /etc/rc.suspend és /etc/rc.resume szkriptekbe beillesztjük az ehhez szükséges parancsokat. Ezekben egyébként találunk is egy megjegyzésbe rakott példát a meghajtók betöltésérõl és eltávolításáról. Ha az ébresztés után elszemetelõdik a képernyõ tartalma, akkor állítsuk át a hw.acpi.reset_video változó értékét nullára (0). Sokat segíthet meg az is, ha a hw.acpi.sleep_delay értékét csökkentjük vagy növeljük.

Megpróbálhatjuk azt is, hogy elindítunk egy frissebb Linux disztribúciót ACPI támogatással és ugyanazon a hardveren kipróbáljuk az általa felkínált felfüggesztési és folytatási lehetõséget. Ha Linux alatt ez megbízhatóan mûködik, akkor nagy a valószínûsége, hogy ez FreeBSD alatt az egyik meghajtó hibájából fakadóan nem használható. Így fokozatosan le is tudjuk szûkíteni, hogy pontosan melyikkel lehet a gond, és ezzel a fejlesztõk munkáját segítjük. Megjegyeznénk, hogy az ACPI-t karbantartó fejlesztõk általában nem foglalkoznak más meghajtókkal (például hangkártya vagy ATA stb.), ezért az adott meghajtóval kapcsolatos hibáról javasolt értesíteni a FreeBSD-CURRENT levelezési lista listát és a meghajtóért felelõs fejlesztõt is. Ha van egy kis kedvünk és idõnk, mi magunk is belebiggyeszthetünk a meghajtóba néhány printf(3) függvényt annak kiderítésére, pontosan hol is fagy le a folytatási funkció.

Végül megpróbálkozhatunk az ACPI kikapcsolásával is, és áttérhetünk helyette az APM használatára. Ha az APM-mel mûködnek a készenléti állapotok, akkor érdemes inkább azzal dolgozni, különösen a régebbi (2000 elõtti) hardverek esetében. A gyártóknak eltartott egy ideig, amíg rendes ACPI támogatást voltak képesek adni, ezért a régebbi hardvereknél inkább a BIOS-nak akadnak gondjai az ACPI-val.

A legtöbb rendszer olyankor akad meg, amikor sok megszakítás elveszik, vagy amikor éppen sok megszakítás érkezik egyszerre. A chipkészleteknek számos baja származik abból, hogy a BIOS milyen módon állítja be a rendszer indítása elõtt a megszakításokat, mennyire helyes az APIC (MADT) táblázata és hogyan vezérli a Rendszervezérlõ megszakítást (System Control Interrupt, SCI).

A megszakítás-viharok a vmstat -i parancs kimenetében szereplõ elveszett megszakításokból azonosíthatók be, ahol keressünk rá az acpi0 sorra. Ha ez a számláló másodpercenként kettõnél többel növekszik, akkor a megszakításaink viharba keveredtek. Ha a rendszer látszólag lefagyott, próbáljuk meg elõhívni a DDB-t (konzolban a CTRL+ALT+ESC) és gépeljük be, hogy show interrupts.

A megszakítási problémákkal kapcsolatban egyetlen reményünk az APIC támogatás kikapcsolása lehet a loader.conf állományban a hint.apic.0.disabled="1" sor hozzáadásával.

Az ACPI-vel kapcsolatos végzetes hibák viszonylag ritkák, és javításuk a legfontosabb. Ilyenkor az elsõ teendõnk elkülöníteni a hiba reprodukálásának egyes lépéseit és (ha lehetséges) lekérni a hívási láncot. Kövessük az options DDB és a soros vonali konzol beállításához adott tanácsokat (lásd A DDB elérése a soros vonalról) vagy hozzunk létre egy dump(8) partíciót. A DDB-ben a hívási láncot a tr parancs segítségével kérhetjük le. Ha kézzel írjuk le láncot, akkor legalább az alsó öt (5) és a felsõ öt (5) sorát mindenképpen jegyezzük fel!

Ezután próbáljuk meg úgy szûkíteni a probléma lehetõségét, hogy az ACPI használata nélkül indítjuk a rendszert. Ha ezzel nincs semmi gond, akkor a debug.acpi.disable változó értékének megfelelõ beállításával egyenként meg tudjuk figyelni az ACPI alrendszer egyes részeit. Ehhez példákat az acpi(4) man oldalon találunk.

Elõször is próbáljuk meg a hw.acpi.disable_on_poweroff változó értékét 0-ra állítani a loader.conf(5) állományban. Ezzel távoltartjuk az ACPI alrendszert a rendszer leállítási folyamatától. Egyes rendszereknek valamilyen okból kifolyólag szükségük van itt az 1 (az alapértelmezett) értékre. Ez többnyire megoldja a problémát, amikor a rendszer váratlanul elindul a készenléti mód aktiválásákor vagy kikapcsoláskor.

Ha más gondjaink lennének az ACPI-val (dokkoló állomásunk van, egyes eszközöket nem vesz észre stb.), akkor természetesen errõl is küldjünk egy leírást a levelezési listára. Azonban vegyük figyelembe, hogy egyes problémák a ACPI alrendszer eddig még nem implementált, befejezetlen részeihez kötõdnek, ezért azok megoldása még várat magára. Kérünk mindenkit, hogy legyen türelemmel és álljon készen a kiküldött javítások tesztelésére!

Néhány AML úgy gondolja, hogy a világ csak a különbözõ Windows® verziókból áll. A FreeBSD-nek megadható, hogy másik operációs rendszernek adja ki magát, és ezzel talán meg is szüntethetõ pár hiba. Ezt a legegyszerûbb úgy tudjuk megtenni, ha a /boot/loader.conf állományhoz hozzáfûzzük a hw.acpi.osname="Windows 2001" sort, vagy itt egy olyan karakterláncot adunk meg, amit az ASL forrásban láttunk.

Bizonyos módszerek a szabvány szerint elvártaktól eltérõen nem adnak vissza explicit módon értéket. Mivel az ACPI-CA ezt nem kezeli le, ezért a FreeBSD részérõl tartalmaz egy olyan módosítást, amivel implicit módon is vissza lehet adni értéket. Ha biztosak akarunk lenni a visszaadni kívánt értékben, akkor helyezzünk el a megfelelõ helyekre explicit Return utasításokat. Az iasl a -f paraméterrel kényszeríthetõ az ilyen ASL források lefordítására.

Miután módosítottuk a saját.asl állományunkat, így tudjuk lefordítani:

Az -f kapcsoló megadásával kikényszeríthetjük az AML létrehozását még abban az esetben is, amikor hibákat tartalmaz. Ügyeljünk rá, hogy bizonyos hibákat (például a hiányzó visszatérési értékeket) a fordító magától kikerül.

Az iasl alapértelmezett kimenete a DSDT.aml állomány. A /boot/loader.conf átírásával így tudjuk ezzel helyettesíteni a BIOS-unk hibás változatát (ami még mindig megtalálható a flash memóriában):

Ehhez ne felejtsük el a saját DSDT.aml állományunkat bemásolni a /boot könyvtárba.