From owner-p4-projects@FreeBSD.ORG Sat Apr 5 01:45:26 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id B84B01065672; Sat, 5 Apr 2008 01:45:26 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A07C106566B for ; Sat, 5 Apr 2008 01:45:26 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 64BDC8FC16 for ; Sat, 5 Apr 2008 01:45:26 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id m351jQ3u050892 for ; Sat, 5 Apr 2008 01:45:26 GMT (envelope-from pgj@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.1/8.14.1/Submit) id m351jQs5050890 for perforce@freebsd.org; Sat, 5 Apr 2008 01:45:26 GMT (envelope-from pgj@FreeBSD.org) Date: Sat, 5 Apr 2008 01:45:26 GMT Message-Id: <200804050145.m351jQs5050890@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to pgj@FreeBSD.org using -f From: Gabor Pali To: Perforce Change Reviews Cc: Subject: PERFORCE change 139392 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2008 01:45:27 -0000 http://perforce.freebsd.org/chv.cgi?CH=139392 Change 139392 by pgj@disznohal on 2008/04/05 01:45:10 Fix typos, translation, format. Submitted by: gabor (mentor) Affected files ... .. //depot/projects/docproj_hu/books/handbook/vinum/chapter.sgml#3 edit Differences ... ==== //depot/projects/docproj_hu/books/handbook/vinum/chapter.sgml#3 (text+ko) ==== @@ -18,7 +18,7 @@ Greg Lehey - Eredetileg írta: + Az eredeti változatot írta: @@ -56,7 +56,7 @@ alaprendszerében megtalálható egy blokkos eszközmeghajtóként a Vinum kötetkezelõ is, amellyel virtuális - lemezmeghajtókat lehet képezni. A tehát + lemezmeghajtókat lehet létrehozni. Tehát a Vinum egy olyan ún. kötetkezelõ, vagyis virtuális lemezkezelõ, ami az említett @@ -70,14 +70,13 @@ is. Ebben a fejezetben összefoglaljuk a hagyományos - lemezes tárolás jellegzetes - hátulütõit és bemutatjuk a Vinum - kötetkezelõt. + lemezes tárolás jellegzetes problémáit + és bemutatjuk a Vinum kötetkezelõt. A &os; 5-ös verziójától kezdve a - Vinumot újraírták a GEOM-nak megfelelõen - (), megtartva az eredeti + Vinumot újraírták a GEOM-nak + megfelelõen (), megtartva az eredeti elgondolásokat, elnevezéseket és a lemezen tárolt metaadatok formátumát. Ezt az újraírt változatot nevezik @@ -100,6 +99,7 @@ implementáció többé már nem is része az alaprendszernek. + @@ -112,23 +112,24 @@ A lemezek kapacitása ugyan növekszik, de - velük együtt a tárigények is. Gyakran - érezzük emiatt úgy, hogy a + velük együtt a tárigények is. + Ezért gyakran érezzük úgy, hogy a rendelkezésünkre álló lemezek tárkapacitását meghaladó állományrendszerre lenne szükségünk. Kétségtelen, hogy ez a probléma messze nem akkora jelentõségû, - mint mondjuk tíz évvel ezelõtt, de még - mindig fennáll. Egyes rendszerek ezt úgy - hidalták át, hogy létrehoztak egy olyan - absztrakt eszközt, amely az adatokat több lemezen + mint például tíz évvel ezelõtt, + de még mindig fennáll. Egyes rendszerek ezt + úgy hidalták át, hogy létrehoztak egy + olyan absztrakt eszközt, amely az adatokat több lemezen tárolja el. + - Szûk keresztmetszetek a - lemezhozzáférésben + A hozzáférési idõk szûk + keresztmetszetei Napjaink rendszerei szinte állandóan egyszerre több adathoz is hozzá akarnak férni. @@ -136,7 +137,7 @@ szerver több 100 Mbit/s sebességû kapcsolattal is csatlakozhat a világhálóhoz, amelyeken keresztül párhuzamosan többezernyi - adatforgalmat is folytathat, ami jelentõsen meghaladja a + tranzakciót is folytathat, ami jelentõsen meghaladja a legtöbb lemez átlagos átviteli sebességét. @@ -157,13 +158,13 @@ feldolgozással. Bármelyik kérést is vesszük, a - kiszolgáláshoz a meghajtónak elõször - a megfelelõ helyre kell tájolnia az + kiszolgáláshoz a meghajtónak + elõször a megfelelõ helyre kell mozgatnia az író/olvasó fejeket, meg kell várni a fej alatt elhaladó elsõ szektort, majd végrehajtani a megfelelõ mûveletet. Ezek a mûveletek szétválaszthatatlanok: semmi - értelme nincs megszakítani õket. + értelme nincs megszakítani ezeket. Tekintsünk egy átlagosnak mondható, nagyjából @@ -185,15 +186,16 @@ mennyiségétõl. A hagyományos és kézenfekvõ - megoldása ennek a problémának még - több cséve használata: egyetlen nagy - lemez helyett alkalmazzunk több kisebb, de azonos - tárkapacitású lemezt. Mindegyik lemez - képes egymástól függetlenül - mozgatni a fejeiket és az adatokat, aminek - köszönhetõen a tényleges adatátvitel - mértéke nagyjából a lemezek - számával arányosan növekszik. + megoldása ennek a problémának + még több cséve + használata: egyetlen nagy lemez helyett alkalmazzunk + több kisebb, de azonos tárkapacitású + lemezt. Mindegyik lemez képes egymástól + függetlenül mozgatni a fejeiket és az adatokat, + aminek köszönhetõen a tényleges + adatátvitel mértéke nagyjából a + lemezek számával arányosan + növekszik. Az adatátvitelben bekövetkezõ javulás pontos aránya természetesen kisebb, mint a lemezek @@ -204,23 +206,22 @@ elkerülhetetlen, hogy az egyik meghajtót nagyobb terhelés érje, mint a másikat. - - lemezek összefûzése - + lemezek + összefûzése Vinum összefûzés A lemezekre esõ terhelés egyenletessége - erõsen függ attól, hogyan osztjuk el az adatokat a - meghajtók között. Az itt használt - tárgyalásmódban a lemezen tárolt - adatokat egy könyv oldalaiként érdemes - elképzelni, vagyis rengeteg szám szerint - címezhetõ adatszektorként. A virtuális - lemezt ennek megfelelõen a legegyszerûbben úgy - tudjuk felosztani az egymás után következõ + erõsen függ attól, hogyan osztjuk el az adatokat + a meghajtók között. Az itt használt + példában a lemezen tárolt adatokat egy + könyv oldalaiként érdemes elképzelni, + vagyis rengeteg szám szerint címezhetõ + adatszektorként. A virtuális lemezt ennek + megfelelõen a legegyszerûbben úgy tudjuk + felosztani az egymás után következõ független fizikai lemezek mérete szerint és így használni, mintha egy nagy könyvet kisebb részekre téptünk volna. Ezt a módszert @@ -244,16 +245,12 @@ - - lemezcsíkozás - + lemezcsíkozás Vinum csíkozás - - RAID - + RAID Feloszthatjuk a virtuális lemezünket kisebb azonos méretû darabokra is, melyeket @@ -265,19 +262,18 @@ után az egész folyamat ismétlõdik, egészen az összes lemez megtöltéséig. Ezt a leképezést - csíkozásnak vagy - RAID-0-nak nevezzük. - - - A RAID jelentése: Olcsó - lemezek hibatûrõ tömbje (Redundant Array of - Inexpensive Disks). Különféle - típusú hibatûrési megoldásokat - vonultat fel, habár az eredeti elnevezés - félrevezetõ lehet, mivel redundanciát nem - tartalmaz. - - + csíkozásnak + (striping) vagy RAID-0-nak + nevezzük. + + A RAID jelentése: Olcsó + lemezek hibatûrõ tömbje (Redundant Array of + Inexpensive Disks). Különféle + típusú hibatûrési megoldásokat + vonultat fel, habár az eredeti elnevezés + félrevezetõ lehet, mivel redundanciát nem + tartalmaz. + A csíkozás használata során valamivel bonyolultabbá válik az adatok megtalálása és többletmunkát is @@ -301,35 +297,31 @@ A modern lemezhajtók utolsó fontos problémája, hogy nem eléggé megbízhatóak. Annak ellenére, hogy a lemezek - ezen a téren rettenetesen sokat fejlõdtek az + ezen a téren meglehetõsen sokat fejlõdtek az utóbbi pár évben, egy szervernek még - mindig azon központi részei, melyek a leginkább - hajlamosak a meghibásodásra. Amikor ez - bekövetkezik, a hatása akár egy + mindig ezek azok a központi részei, amelyek a + leginkább hajlamosak a meghibásodásra. + Amikor ez bekövetkezik, a hatása akár egy katasztrófával is felérhet: a sérült lemezmeghajtók cseréje és az adatok visszaállítása napokat is igénybe vehet. + lemeztükrözés - lemeztükrözés - - Vinum tükrözés - - RAID-1 - + RAID-1 Ennek a problémának a hagyományos megközelítése lenne a - tükrözés, vagyis amikor - ugyanarról az adatról tartunk két - példányt két eltérõ fizikai - hardveren. A RAID-szintek - beköszöntével ezt a technikát - RAID level 1-nak vagy + tükrözés + (mirroring), vagyis amikor ugyanarról az + adatról tartunk két példányt + két eltérõ fizikai hardveren. A + RAID-szintek beköszöntével ezt + a technikát RAID level 1-nak vagy RAID-1-nek is nevezik. Amikor írunk a kötetre, mindenhova írunk, az olvasás pedig bármelyik eszközrõl elvégezhetõ. @@ -343,8 +335,8 @@ Ár. Legalább kétszer annyiba - kerül, mint a nem redundánsan tároló - megoldások. + kerül, mint a nem redundánsan + tároló megoldások. @@ -359,16 +351,12 @@ + lemezparitás - lemezparitás - - Vinum paritás - - RAID-5 - + RAID-5 Az adatintegritás megõrzésére egy másik megoldás a paritás @@ -399,11 +387,11 @@ A RAID-5-nek a tükrözéshez - képest megvan az elõnye, hogy jelentõsen kevesebb - tárhelyet igényel. Az olvasás hasonló - a csíkozott szervezésekéhez, azonban az - írás jóval lassabb, közel 25%-a az - olvasás sebességének. Az egyik + képest megvan az az elõnye, hogy jelentõsen + kevesebb tárhelyet igényel. Az olvasás + hasonló a csíkozott szervezésekéhez, + azonban az írás jóval lassabb, közel + 25%-a az olvasás sebességének. Az egyik meghajtó meghibásodása esetén a tömb csökkentett módban még képes folytatni a mûködést: a fennmaradó @@ -412,6 +400,7 @@ meghajtóról olvasott adatokat folyamatosan javítani kell a többirõl származó segédinformációk szerint. + @@ -435,11 +424,11 @@ A kötetek erekbõl (plex) - állnak, melyek a kötet teljes területét - képviselik. Ennélfogva a hierarchia ezen - szintje nyújtja a redundanciát. Az ereket - legegyszerûbben a tükrözött tömbben - helyet foglaló lemezekként tudjuk + állnak, melyek a kötet teljes + területét képviselik. Ennélfogva a + hierarchia ezen szintje nyújtja a redundanciát. + Az ereket legegyszerûbben a tükrözött + tömbben helyet foglaló lemezekként tudjuk elképzelni, melyek ugyanazt az adatot tartalmazzák. @@ -479,19 +468,21 @@ A most következõ szakaszokban ismertetjük, hogy - ezek az objektumok milyen módon szolgáltatják a - Vinum részérõl elvárt + ezek az objektumok milyen módon szolgáltatják + a Vinum részérõl elvárt funkciókat. A kötetek mérete + Az erek képesek a Vinum konfigurációjában található több különbözõ meghajtón - elhelyezkedõ allemezt is nyalábolni. Ennek - következményeképpen az egyes meghajtók - mérete nem korlátozza az erek + elhelyezkedõ allemezeket is nyalábba kötni. + Ennek következményeképpen az egyes + meghajtók mérete nem korlátozza az erek méretét, emiatt a kötetét sem. + @@ -508,12 +499,14 @@ adatát ábrázolja, elõfordulhat olyan eset, hogy bizonyos részei hiányoznak fizikai, kialakítási (nem társítottunk - allemezeket hozzájuk) okokból adódoan vagy - véletlenül (a hozzátartozó - lemezterületek sérültek). Amíg - legalább egy ér képes a kötet teljes - tartalmát szolgáltatni, addig a kötet - teljesen épnek tekinthetõ. + allemezeket hozzájuk) okokból + adódóan vagy véletlenül (a + hozzátartozó lemezterületek + sérültek). Amíg legalább egy + ér képes a kötet teljes tartalmát + szolgáltatni, addig a kötet teljesen épnek + tekinthetõ. + @@ -539,19 +532,21 @@ összefûzött értõl. + Hogyan szervezzük az ereket? + A &os; &rel.current; verziójában két fajta erezési megoldást találhatunk: Az összefûzött erek a legrugalmasabbak: - tetszõleges számú allemezt tartalmazhatnak, - az allemezek mérete pedig eltérhet. Az - ér újabb allemezek + tetszõleges számú allemezt + tartalmazhatnak, az allemezek mérete pedig + eltérhet. Az ér újabb allemezek hozzáadásával tovább bõvíthetõ. Kevesebb processzoridõt igényel, mint egy csíkozott ér, @@ -578,7 +573,7 @@ egyezniük a méretüknek, illetve az érhez annyira bonyolult újabb allemezeket kapcsolni, hogy a Vinum jelenleg nem is képes - rá. Ezeken felül a Vinum még + rá. Ezeken kívü a Vinum még támaszt egy triviális igényt is: a csíkozott érben legalább két allemeznek lennie kell, mivel másképp nem @@ -628,6 +623,7 @@ + @@ -655,6 +651,7 @@ A konfigurációs állomány + A konfigurációs állomány írja le az egyes objektumokat. Egy egyszerûbb kötet definíciója így nézhet @@ -671,8 +668,8 @@ - A drive kezdetû sor adja meg - az lemez partícióját + A drive kezdetû sor adja meg a + lemez partícióját (meghajtóját) és a hardveren levõ elhelyezkedését. Az a szimbolikus nevet kapta. A @@ -757,8 +754,8 @@ Ezen és az ezt követõ ábrán - egy kötetet láthatunk, amely ereket tartalmaz, amelyek - pedig allemezeket. Ebben a pofonegyszerû + egy kötetet láthatunk, amely ereket tartalmaz, + amelyek pedig allemezeket. Ebben az alapvetõ példában a kötet egyetlen eret tartalmaz, amiben pedig egyetlen allemez van. @@ -772,6 +769,7 @@ következõ szakaszokban sokkal érdekesebb konfigurációs módszereket is illusztrálunk. + @@ -779,12 +777,12 @@ tükrözés A kötetek rugalmassága - tükrözéssel növelhetõ. Egy - tükrözött kötet kiosztása során - feltétlenül gondoskodnunk kell arról, hogy az - egyes erekhez tartozó allemezek eltérõ - meghajtókon találhatóak, így az - esetleges meghibásodások nem + tükrözéssel növelhetõ. Egy + tükrözött kötet kiosztása + során feltétlenül gondoskodnunk kell + arról, hogy az egyes erekhez tartozó allemezek + eltérõ meghajtókon találhatóak, + így az esetleges meghibásodások nem károsítják mind a két eret. Az alábbi konfigurációban egy kötetet tükrözünk: @@ -798,12 +796,12 @@ sd length 512m drive b Ebben a példában már nem kellett - újra megadnunk az a meghajtót, - mivel a Vinum figyelemmel kíséri az összes - objektumot a saját konfigurációs - adatbázisában. A definíció - feldolgozása után a konfiguráció - így fog kinézni: + újra megadnunk az a + meghajtót, mivel a Vinum figyelemmel kíséri + az összes objektumot a saját + konfigurációs adatbázisában. A + definíció feldolgozása után a + konfiguráció így fog kinézni: Drives: 2 (4 configured) @@ -839,6 +837,7 @@ a teljes 512 MB-os területet. Ahogy a korábbi példa esetén, itt is mindegyik ér csak egyetlen allemezt tartalmaz. + @@ -884,21 +883,21 @@ Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) - + D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) - + V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB - + P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB - + S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB @@ -914,11 +913,12 @@ - Ez a kötet a + Ez a kötet a ban látható. A csíkok sötétedése jelzi a helyüket az ér területében: a világosabbak elöl, a sötétebbek hátul szerepelnek. + @@ -966,6 +966,7 @@ + @@ -974,7 +975,7 @@ Korábban már megismerhettük, hogy a Vinum alapértelmezett neveket társít az erekhez - és allemezekhez, habár ezek a nevek + és az allemezekhez, habár ezek a nevek felülbírálhatóak. Ez viszont egyáltalán nem ajánlott, mivel már a VERITAS kötetkezelõ, ahol tetszõleges neveket @@ -987,11 +988,11 @@ karaktert, azonban érdemes inkább csak betûket, számjegyeket és az aláhúzást használni. A kötetek, erek és allemezek nevei - egészen 64 karakteresek lehetnek, míg a - meghajtók nevei pedig 32 karakteresek. + akár 64 karakteresek is lehetnek, a meghajtók nevei + pedig 32 karakteresek. A Vinum objektumai a /dev/gvinum - könyvtáron belül levõ hierarchiában + könyvtáron belüli hierarchiában helyezkednek el eszközleírókként. Az imént említett példakonfiguráció hatására a @@ -1000,21 +1001,23 @@ - Ez csak a Vinum elavult - implementációjára vonatkozik. + + Ez a rész csak a Vinum korábbi, elavult + implementációjára vonatkozik. + A /dev/vinum/control és /dev/vinum/controld nevû vezérlõeszközök, melyeket a - &man.gvinum.8; és a Vinum daemon használ. + &man.gvinum.8; és a Vinum démon + használ. - Mindegyik kötethez egy - eszközleíró. Ezek a Vinum - számára a központi eszközök. - Ezért az elõbbi konfiguráció - révén megjelennek a + Mindegyik kötethez egy eszközleíró + tartozik. Ezek a Vinum számára a központi + eszközök, ezért az elõbbi + konfiguráció révén megjelennek a /dev/gvinum/myvol, /dev/gvinum/mirror, /dev/gvinum/striped, @@ -1024,19 +1027,21 @@ - Ez csak a Vinum elavult - implementációjára vonatkozik. + + Ez a rész csak a Vinum korábbi, elavult + implementációjára vonatkozik. + - Leírók a - /dev/vinum/drive könyvtárban az - egyes meghajtókhoz. Ezek valójában - szimbolikus linkek a megfelelõ lemezes - eszközökre. + Az egyes meghajtókhoz tartozó + leírók a /dev/vinum/drive + könyvtárban találhatóak. Ezek + valójában szimbolikus linkek a megfelelõ + lemezes eszközökre. - Közvetlen leírók minden kötethez a - /dev/gvinum/ + Minden kötethez közvetlen leírók + tartoznak /dev/gvinum/ könyvtárban. @@ -1044,8 +1049,8 @@ Az egyes erek és allemezek eszközleírói a /dev/gvinum/plex és - /dev/gvinum/sd - könyvtárakban. + /dev/gvinum/sd könyvtárakban + jelennek meg. @@ -1065,9 +1070,9 @@ sd length 100m drive drive4 Az állomány feldolgozása után az - eszközleírókat a &man.gvinum.8; az alábbi - módon szervezi a /dev/gvinum - könyvtárban: + eszközleírókat a &man.gvinum.8; az + alábbi módon szervezi a + /dev/gvinum könyvtárban: drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex @@ -1091,7 +1096,7 @@ megoldhatóvá válik, hogy az egyes meghajtók automatikusan felismerhetõek legyenek abban az esetben is, amikor fizikailag áthelyezzük - õket. A meghajtók nevei legfeljebb 32 karakteresek + ezeket. A meghajtók nevei legfeljebb 32 karakteresek lehetnek. @@ -1122,8 +1127,8 @@ partíció nevével. Hétköznapi esetben a &man.newfs.8; - megpróbálja a lemez nevét értelmezni, - és panaszkodik, ha nem sikerül. + megpróbálja a lemez nevét + értelmezni, és panaszkodik, ha nem sikerül. Például: &prompt.root; newfs /dev/gvinum/concat @@ -1135,12 +1140,15 @@ &prompt.root; newfs /dev/gvinum/concat - A &os; 5.0 elõtt verzióiban a - &man.newfs.8; parancsnak a régi elnevezési - séma használata mellett még át kell - adni egy -v kapcsolót is: + + A &os; 5.0 elõtt verzióiban a &man.newfs.8; + parancsnak a régi elnevezési séma + használata mellett még át kell adni egy + -v kapcsolót is: + &prompt.root; newfs -v /dev/vinum/concat + @@ -1209,11 +1217,13 @@ Automatikus indítás - Ez a rész csak a Vinum elavult - implementációjára vonatkozik. A - Gvinum mindig automatikusan elindul a - hozzátartozó modul - betöltésével együtt. + + Ez a rész csak a Vinum elavult + implementációjára vonatkozik. A + Gvinum mindig automatikusan elindul a + hozzátartozó modul + betöltésével együtt. + A Vinum rendszerindítás során történõ automatikus @@ -1237,7 +1247,7 @@ található állományrendszereket a rendszer automatikusan át tudja vizsgálni az &man.fsck.8; segítségével, majd - csatlakoztatni õket. + csatlakoztatja ezeket. Amikor a Vinumot a vinum start paranccsal indítjuk el, a Vinum beolvassa a @@ -1256,6 +1266,7 @@ található adatbázispéldányokat szinkronizálja ehhez a változathoz. + @@ -1302,9 +1313,9 @@ használt állományrendszert tartalmazó Vinum-kötetre. Ennek megfelelõen valószínûleg jó ötlet a - "root"-nak nevezni ezt a kötetet, - habár technikai szempontból ezt semmi nem - követeli meg. Az itt felsorakozó + "root" névvel azonosítani ezt a + kötetet, habár technikai szempontból ezt semmi + nem követeli meg. Az itt felsorakozó példákban azonban ezt a nevet fogjuk használni. @@ -1316,9 +1327,9 @@ - A rendszermagnak már el tudnia érnie a - Vinumot a rendszerindítás során. Emiatt - a ban leírt + A rendszermagnak már el kell érnie a + Vinumot a rendszerindítás során. + Emiatt a ban leírt automatikus indítási módszer nem alkalmazható erre a feladatra, és a start_vinum paramétert @@ -1339,19 +1350,21 @@ - A Gvinum használata - során az összes többi - beállítás automatikusan - végrehajtódik, amint a modul - betöltõdik, ezért ilyenkor csak a fentebb - leírt eljárásra van - szükség. Az itt felsoroltak csak az elavult - Vinum implementációra vonatkoznak, - csupán a régebbi típusú - rendszerek kedvéért említjük - meg. + + A Gvinum használata + során az összes többi + beállítás automatikusan + végrehajtódik, amint a modul + betöltõdik, ezért ilyenkor csak a fentebb + leírt eljárásra van + szükség. Az itt felsoroltak csak az elavult + Vinum implementációra vonatkoznak, + csupán a régebbi típusú + rendszerek kedvéért említjük + meg. + - A Vinumot nagyon korán éltre kell + A Vinumot nagyon korán életre kell keltenünk, hiszen a rendszerindításhoz használt állományrendszert tartalmazó kötetet kell @@ -1363,12 +1376,15 @@ valamelyik rendszerindító szkript) ki nem adja a vinum start parancsot. - A most következõ bekezdés a &os; - 5.X és az azutáni rendszerek esetén - mutatja be a szükséges lépéseket. - A &os; 4.X verziója esetén máshogy kell - elvégezni a beállításokat, amit - a mutat be. + + A most következõ bekezdés a &os; 5.X + és az azutáni rendszerek esetén + mutatja be a szükséges + lépéseket. A &os; 4.X verziója + esetén máshogy kell elvégezni a + beállításokat, amit a mutat be. + A @@ -1398,6 +1414,7 @@ leképzéséhez. + @@ -1408,17 +1425,17 @@ Mivel a jelenlegi &os; rendszertöltõ csak 7,5 KB méretû és egyébként is csak az UFS állományrendszerrõl tud - állományokat beolvasni (mint mondjuk a - /boot/loadert), teljesen lehetetlen + állományokat beolvasni (mint például + a /boot/loadert), teljesen lehetetlen még a Vinum belsõ szerkezetére is megtanítani, tehát a Vinum-konfigurációk értelmezésére és magának a rendszerindító kötet elemeinek - kimazsolázására. Ezért be kell - vetnünk néhány trükköt ahhoz, hogy - a rendszerindító kód számára - a rendszerindításhoz használható + kielemzésére. Ezért be kell vetnünk + néhány trükköt ahhoz, hogy a + rendszerindító kód számára a + rendszerindításhoz használható szabványos "a" partíció képzetét keltsük. @@ -1473,8 +1490,8 @@ A rendszerindító kötet részeként megjelenõ eszközön - található allemez helyét (az eszköz - elejétõl számított + található allemez helyét (az + eszköz elejétõl számított eltolását) és méretét ellenõrizni kell az alábbi parancs segítségével: @@ -1482,11 +1499,11 @@ &prompt.root; gvinum l -rv root Ne felejtsük el, hogy a Vinum az eltolásokat - és méreteket byte-okban méri. + és méreteket bájtokban méri. Ezekbõl tehát úgy nyerünk a bsdlabel használatához - szükséges blokkszámokat, ha elosztjuk - õket 512-vel. + szükséges blokkszámokat, ha ezeket + elosztjuk 512-vel. @@ -1499,13 +1516,14 @@ kialakításában. Az eszköznév legyen a slice (fdisk)-táblát nem tartalmazó - lemezek esetén a lemez neve (mint mondjuk - da0), vagy ellenkezõ esetben a - slice neve (pl. ad0s1). + lemezek esetén a lemez neve (mint + például da0), vagy + ellenkezõ esetben a slice neve (pl. + ad0s1). Ha már lenne egy "a" partíció az eszközön - (gyaníthatóan egy Vinum elõtti + (valószínûleg egy Vinum elõtti rendszeríndító állományrendszert tartalmaz), nevezzük át valami másra és így @@ -1514,8 +1532,8 @@ rendszer számára alapértelmezett rendszerindító eszköz. Azonban vegyük észre, hogy az aktív - partíciók (mint mondjuk az éppen - csatlakoztatott rendszerindító + partíciók (mint például az + éppen csatlakoztatott rendszerindító állományrendszer) nem nevezhetõek át, ezért ezt a lépést csak akkor tudjuk megtenni, ha a rendszerünket egy @@ -1540,8 +1558,8 @@ 4.2BSD. Az "fsize", "bsize" és "cpg" értékeket a jelenlegi - állományrendszerhez mértéken - illendõ megválasztani, azonban itt most + állományrendszerhez mérten + ajánlott megválasztani, azonban itt most egyáltalán nem bírnak jelentõséggel. @@ -1585,19 +1603,19 @@ ellenõriznünk. A következõ indítás során a - rendszertöltõ már az új Vinum-alapú - rendszerindító + rendszertöltõ már az új + Vinum-alapú rendszerindító állományrendszerrõl fogja összeszedni a mûködéséhez szükséges adatokat és ezeknek megfelelõen cselekedni. - Végül, a rendszermag - inicializálódásának - végén, mikor az összes eszközt - felismerte, egy ehhez hasonló feltûnõ - üzenet fogja jelezni a beállítás + Végül, a rendszermag inicializálója + után, mikor az összes eszközt felismerte, egy + ehhez hasonló feltûnõ üzenet fogja jelezni + a beállítás sikerességét: Mounting root from ufs:/dev/gvinum/root + @@ -1605,9 +1623,9 @@ állományrendszer példája Miután sikeresen konfiguráltuk a - rendszerindító Vinum-kötetet, a gvinum - l -rv root kimenete nagyjából így - fog kinézni: + rendszerindító Vinum-kötetet, a + gvinum l -rv root kimenete + nagyjából így fog kinézni: ... @@ -1629,9 +1647,10 @@ 135680-as eltoltás értékekre kell figyelnünk. Ez képzõdik le a bsdlabel fogalmi - rendszerében aztán 265 darab 512 byte-os blokkra a - lemezen. Ehhez hasonlóan a rendszerindító - kötet mérete 245760 darab 512 byte-os blokk lesz. A + rendszerében aztán 265 darab 512 bájtos + blokkra a lemezen. Ehhez hasonlóan a + rendszerindító kötet mérete 245760 + darab 512 bájtos blokk lesz. A rendszerindító kötet másodpéldányát tartalmazó /dev/da1h ugyanilyen @@ -1650,9 +1669,9 @@ Megfigyelhetõ, hogy a hamis "a" - partíció "size" paraméter - értéke megegyezik a fentebb becsült - értékkel, miközben az >>> TRUNCATED FOR MAIL (1000 lines) <<<