PERFORCE change 139392 for review
Gabor Pali
pgj at FreeBSD.org
Sat Apr 5 01:45:27 UTC 2008
http://perforce.freebsd.org/chv.cgi?CH=139392
Change 139392 by pgj at 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) <<<
More information about the p4-projects
mailing list