Date: Sat, 5 Apr 2008 01:45:26 GMT From: Gabor Pali <pgj@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 139392 for review Message-ID: <200804050145.m351jQs5050890@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 @@ <author> <firstname>Greg</firstname> <surname>Lehey</surname> - <contrib>Eredetileg írta:</contrib> + <contrib>Az eredeti változatot írta:</contrib> </author> </authorgroup> </chapterinfo> @@ -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 <emphasis>Vinum</emphasis> egy olyan ún. <emphasis>kötetkezelõ</emphasis>, vagyis virtuális lemezkezelõ, ami az említett @@ -70,14 +70,13 @@ is.</para> <para>Ebben a fejezetben összefoglaljuk a hagyományos - lemezes tárolás jellegzetes - hátulütõit és bemutatjuk a Vinum - kötetkezelõt.</para> + lemezes tárolás jellegzetes problémáit + és bemutatjuk a Vinum kötetkezelõt.</para> <note> <para>A &os; 5-ös verziójától kezdve a - Vinumot újraírták a GEOM-nak megfelelõen - (<xref linkend="GEOM">), megtartva az eredeti + Vinumot újraírták a GEOM-nak + megfelelõen (<xref linkend="GEOM">), 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.</para> </note> + </sect1> <sect1 id="vinum-intro"> @@ -112,23 +112,24 @@ </indexterm> <para>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.</para> + </sect1> <sect1 id="vinum-access-bottlenecks"> - <title>Szûk keresztmetszetek a - lemezhozzáférésben</title> + <title>A hozzáférési idõk szûk + keresztmetszetei</title> <para>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.</para> @@ -157,13 +158,13 @@ feldolgozással.</para> <para>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.</para> + értelme nincs megszakítani ezeket.</para> <para><anchor id="vinum-latency">Tekintsünk egy átlagosnak mondható, nagyjából @@ -185,15 +186,16 @@ mennyiségétõl.</para> <para>A hagyományos és kézenfekvõ - megoldása ennek a problémának <quote>még - több cséve</quote> 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.</para> + megoldása ennek a problémának + <quote>még több cséve</quote> + 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.</para> <para>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.</para> - <indexterm> - <primary>lemezek összefûzése</primary> - </indexterm> + <indexterm><primary>lemezek + összefûzése</primary></indexterm> <indexterm> <primary>Vinum</primary> <secondary>összefûzés</secondary> </indexterm> <para>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 @@ </figure> </para> - <indexterm> - <primary>lemezcsíkozás</primary> - </indexterm> + <indexterm><primary>lemezcsíkozás</primary></indexterm> <indexterm> <primary>Vinum</primary> <secondary>csíkozás</secondary> </indexterm> - <indexterm> - <primary>RAID</primary> - </indexterm> + <indexterm><primary>RAID</primary></indexterm> <para>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 - <emphasis>csíkozás</emphasis>nak vagy - <acronym>RAID-0</acronym>-nak nevezzük. - - <footnote> - <para>A <acronym>RAID</acronym> 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.</para> - </footnote> - + <emphasis>csíkozás</emphasis>nak + (<quote>striping</quote>) vagy <acronym>RAID-0</acronym>-nak + nevezzük. + <footnote> + <para>A <acronym>RAID</acronym> 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.</para> + </footnote> 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 @@ <para>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.</para> + <indexterm><primary>lemeztükrözés</primary></indexterm> <indexterm> - <primary>lemeztükrözés</primary> - </indexterm> - <indexterm> <primary>Vinum</primary> <secondary>tükrözés</secondary> </indexterm> - <indexterm> - <primary>RAID-1</primary> - </indexterm> + <indexterm><primary>RAID-1</primary></indexterm> <para>Ennek a problémának a hagyományos megközelítése lenne a - <emphasis>tükrözés</emphasis>, vagyis amikor - ugyanarról az adatról tartunk két - példányt két eltérõ fizikai - hardveren. A <acronym>RAID</acronym>-szintek - beköszöntével ezt a technikát - <acronym>RAID level 1</acronym>-nak vagy + <emphasis>tükrözés</emphasis> + (<quote>mirroring</quote>), vagyis amikor ugyanarról az + adatról tartunk két példányt + két eltérõ fizikai hardveren. A + <acronym>RAID</acronym>-szintek beköszöntével ezt + a technikát <acronym>RAID level 1</acronym>-nak vagy <acronym>RAID-1</acronym>-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 @@ <itemizedlist> <listitem> <para>Ár. Legalább kétszer annyiba - kerül, mint a nem redundánsan tároló - megoldások.</para> + kerül, mint a nem redundánsan + tároló megoldások.</para> </listitem> <listitem> @@ -359,16 +351,12 @@ </listitem> </itemizedlist> + <indexterm><primary>lemezparitás</primary></indexterm> <indexterm> - <primary>lemezparitás</primary> - </indexterm> - <indexterm> <primary>Vinum</primary> <secondary>paritás</secondary> </indexterm> - <indexterm> - <primary>RAID-5</primary> - </indexterm> + <indexterm><primary>RAID-5</primary></indexterm> <para>Az adatintegritás megõrzésére egy másik megoldás a <emphasis>paritás</emphasis> @@ -399,11 +387,11 @@ </para> <para>A <acronym>RAID-5</acronym>-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.</para> + </sect1> <sect1 id="vinum-objects"> @@ -435,11 +424,11 @@ <listitem> <para>A kötetek <emphasis>erek</emphasis>bõ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.</para> </listitem> @@ -479,19 +468,21 @@ </itemizedlist> <para>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.</para> <sect2> <title>A kötetek mérete</title> + <para>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.</para> + </sect2> <sect2> @@ -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õ.</para> + 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õ.</para> + </sect2> <sect2> @@ -539,19 +532,21 @@ összefûzött értõl.</para> </listitem> </itemizedlist> + </sect2> <sect2> <title>Hogyan szervezzük az ereket?</title> + <para>A &os; &rel.current; verziójában két fajta erezési megoldást találhatunk:</para> <itemizedlist> <listitem> <para>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 @@ </tbody> </tgroup> </table> + </sect2> </sect1> @@ -655,6 +651,7 @@ <sect2> <title>A konfigurációs állomány</title> + <para>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 @@ <itemizedlist> <listitem> - <para>A <emphasis>drive</emphasis> kezdetû sor adja meg - az lemez partícióját + <para>A <emphasis>drive</emphasis> kezdetû sor adja meg a + lemez partícióját (<emphasis>meghajtó</emphasis>ját) és a hardveren levõ elhelyezkedését. Az <emphasis>a</emphasis> szimbolikus nevet kapta. A @@ -757,8 +754,8 @@ </para> <para>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.</para> @@ -772,6 +769,7 @@ következõ szakaszokban sokkal érdekesebb konfigurációs módszereket is illusztrálunk.</para> + </sect2> <sect2> @@ -779,12 +777,12 @@ tükrözés</title> <para>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:</para> @@ -798,12 +796,12 @@ sd length 512m drive b</programlisting> <para>Ebben a példában már nem kellett - újra megadnunk az <emphasis>a</emphasis> 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:</para> + újra megadnunk az <emphasis>a</emphasis> + 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:</para> <programlisting width="97"> 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.</para> + </sect2> <sect2> @@ -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 @@ </figure> </para> - <para>Ez a kötet a <xref linkend="vinum-striped-vol"> + <para>Ez a kötet a <xref linkend="vinum-striped-vol">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.</para> + </sect2> <sect2> @@ -966,6 +966,7 @@ <graphic fileref="vinum/vinum-raid10-vol"> </figure> </para> + </sect2> </sect1> @@ -974,7 +975,7 @@ <para>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.</para> + akár 64 karakteresek is lehetnek, a meghajtók nevei + pedig 32 karakteresek.</para> <para>A Vinum objektumai a <filename>/dev/gvinum</filename> - 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 @@ <itemizedlist> <listitem> - <note><para>Ez csak a Vinum elavult - implementációjára vonatkozik.</para></note> + <note> + <para>Ez a rész csak a Vinum korábbi, elavult + implementációjára vonatkozik.</para> + </note> <para>A <filename>/dev/vinum/control</filename> és <filename>/dev/vinum/controld</filename> nevû vezérlõeszközök, melyeket a - &man.gvinum.8; és a Vinum daemon használ.</para> + &man.gvinum.8; és a Vinum démon + használ.</para> </listitem> <listitem> - <para>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 + <para>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 <filename>/dev/gvinum/myvol</filename>, <filename>/dev/gvinum/mirror</filename>, <filename>/dev/gvinum/striped</filename>, @@ -1024,19 +1027,21 @@ </listitem> <listitem> - <note><para>Ez csak a Vinum elavult - implementációjára vonatkozik.</para></note> + <note> + <para>Ez a rész csak a Vinum korábbi, elavult + implementációjára vonatkozik.</para> + </note> - <para>Leírók a - <filename>/dev/vinum/drive</filename> könyvtárban az - egyes meghajtókhoz. Ezek valójában - szimbolikus linkek a megfelelõ lemezes - eszközökre.</para> + <para>Az egyes meghajtókhoz tartozó + leírók a <filename>/dev/vinum/drive</filename> + könyvtárban találhatóak. Ezek + valójában szimbolikus linkek a megfelelõ + lemezes eszközökre.</para> </listitem> <listitem> - <para>Közvetlen leírók minden kötethez a - <filename>/dev/gvinum/</filename> + <para>Minden kötethez közvetlen leírók + tartoznak <filename>/dev/gvinum/</filename> könyvtárban.</para> </listitem> @@ -1044,8 +1049,8 @@ <para>Az egyes erek és allemezek eszközleírói a <filename>/dev/gvinum/plex</filename> és - <filename>/dev/gvinum/sd</filename> - könyvtárakban.</para> + <filename>/dev/gvinum/sd</filename> könyvtárakban + jelennek meg.</para> </listitem> </itemizedlist> @@ -1065,9 +1070,9 @@ sd length 100m drive drive4</programlisting> <para>Az állomány feldolgozása után az - eszközleírókat a &man.gvinum.8; az alábbi - módon szervezi a <filename>/dev/gvinum</filename> - könyvtárban:</para> + eszközleírókat a &man.gvinum.8; az + alábbi módon szervezi a + <filename>/dev/gvinum</filename> könyvtárban:</para> <programlisting> 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.</para> <sect2> @@ -1122,8 +1127,8 @@ partíció nevével.</para> <para>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:</para> <screen>&prompt.root; <userinput>newfs /dev/gvinum/concat</userinput> @@ -1135,12 +1140,15 @@ <screen>&prompt.root; <userinput>newfs /dev/gvinum/concat</userinput></screen> - <note><para>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:</para></note> + <note> + <para>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:</para> + </note> <screen>&prompt.root; <userinput>newfs -v /dev/vinum/concat</userinput></screen> + </sect2> </sect1> @@ -1209,11 +1217,13 @@ <sect3 id="vinum-rc-startup"> <title>Automatikus indítás</title> - <note><para>Ez a rész csak a Vinum elavult - implementációjára vonatkozik. A - <emphasis>Gvinum</emphasis> mindig automatikusan elindul a - hozzátartozó modul - betöltésével együtt.</para></note> + <note> + <para>Ez a rész csak a Vinum elavult + implementációjára vonatkozik. A + <emphasis>Gvinum</emphasis> mindig automatikusan elindul a + hozzátartozó modul + betöltésével együtt.</para> + </note> <para>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.</para> + csatlakoztatja ezeket.</para> <para>Amikor a Vinumot a <command>vinum start</command> paranccsal indítjuk el, a Vinum beolvassa a @@ -1256,6 +1266,7 @@ található adatbázispéldányokat szinkronizálja ehhez a változathoz.</para> + </sect3> </sect2> </sect1> @@ -1302,9 +1313,9 @@ használt állományrendszert tartalmazó Vinum-kötetre. Ennek megfelelõen valószínûleg jó ötlet a - <literal>"root"</literal>-nak nevezni ezt a kötetet, - habár technikai szempontból ezt semmi nem - követeli meg. Az itt felsorakozó + <literal>"root"</literal> 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.</para> @@ -1316,9 +1327,9 @@ <itemizedlist> <listitem> - <para>A rendszermagnak már el tudnia érnie a - Vinumot a rendszerindítás során. Emiatt - a <xref linkend="vinum-rc-startup">ban leírt + <para>A rendszermagnak már el kell érnie a + Vinumot a rendszerindítás során. + Emiatt a <xref linkend="vinum-rc-startup">ban leírt automatikus indítási módszer nem alkalmazható erre a feladatra, és a <literal>start_vinum</literal> paramétert @@ -1339,19 +1350,21 @@ </listitem> <listitem> - <note><para>A <emphasis>Gvinum</emphasis> 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.</para></note> + <note> + <para>A <emphasis>Gvinum</emphasis> 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.</para> + </note> - <para>A Vinumot nagyon korán éltre kell + <para>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 <command>vinum start</command> parancsot.</para> - <note><para>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 <xref linkend="vinum-root-4x"> mutat be.</para></note> + <note> + <para>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 <xref + linkend="vinum-root-4x"> mutat be.</para> + </note> <para>A</para> @@ -1398,6 +1414,7 @@ leképzéséhez.</para> </listitem> </itemizedlist> + </sect2> <sect2> @@ -1408,17 +1425,17 @@ <para>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 - <filename>/boot/loader</filename>t), teljesen lehetetlen + állományokat beolvasni (mint például + a <filename>/boot/loader</filename>t), 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 <literal>"a"</literal> partíció képzetét keltsük.</para> @@ -1473,8 +1490,8 @@ <step> <para>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:</para> @@ -1482,11 +1499,11 @@ <screen>&prompt.root; <userinput>gvinum l -rv root</userinput></screen> <para>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 <command>bsdlabel</command> használatához - szükséges blokkszámokat, ha elosztjuk - õket 512-vel.</para> + szükséges blokkszámokat, ha ezeket + elosztjuk 512-vel.</para> </step> <step> @@ -1499,13 +1516,14 @@ kialakításában. Az <replaceable>eszköznév</replaceable> legyen a slice (fdisk)-táblát nem tartalmazó - lemezek esetén a lemez neve (mint mondjuk - <devicename>da0</devicename>), vagy ellenkezõ esetben a - slice neve (pl. <devicename>ad0s1</devicename>).</para> + lemezek esetén a lemez neve (mint + például <devicename>da0</devicename>), vagy + ellenkezõ esetben a slice neve (pl. + <devicename>ad0s1</devicename>).</para> <para>Ha már lenne egy <literal>"a"</literal> 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 @@ <literal>4.2BSD</literal>. Az <literal>"fsize"</literal>, <literal>"bsize"</literal> és <literal>"cpg"</literal> é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.</para> @@ -1585,19 +1603,19 @@ ellenõriznünk.</para> <para>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:</para> <screen>Mounting root from ufs:/dev/gvinum/root</screen> + </sect2> <sect2> @@ -1605,9 +1623,9 @@ állományrendszer példája</title> <para>Miután sikeresen konfiguráltuk a - rendszerindító Vinum-kötetet, a <command>gvinum - l -rv root</command> kimenete nagyjából így - fog kinézni:</para> + rendszerindító Vinum-kötetet, a + <command>gvinum l -rv root</command> kimenete + nagyjából így fog kinézni:</para> <screen> ... @@ -1629,9 +1647,10 @@ <literal>135680</literal>-as eltoltás értékekre kell figyelnünk. Ez képzõdik le a <command>bsdlabel</command> 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ó <filename>/dev/da1h</filename> ugyanilyen @@ -1650,9 +1669,9 @@ </screen> <para>Megfigyelhetõ, hogy a hamis <literal>"a"</literal> - partíció <literal>"size"</literal> paraméter - értéke megegyezik a fentebb becsült - értékkel, miközben az >>> TRUNCATED FOR MAIL (1000 lines) <<<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804050145.m351jQs5050890>