path: root/hu_HU.ISO8859-2/books/handbook/vinum/chapter.sgml

<?xml version="1.0" encoding="iso-8859-2" standalone="no"?>
<!--
     The Vinum Volume Manager
     By Greg Lehey (grog at lemis dot com)

     Added to the Handbook by Hiten Pandya <hmp@FreeBSD.org>
     and Tom Rhodes <trhodes@FreeBSD.org>

     For the FreeBSD Documentation Project
     $FreeBSD$
-->
<!-- The FreeBSD Hungarian Documentation Project
     Translated by: PALI, Gabor <pgj@FreeBSD.org>
     %SOURCE%	en_US.ISO8859-1/books/handbook/vinum/chapter.sgml
     %SRCID%	1.47
-->

<chapter id="vinum-vinum" lang="hu">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Greg</firstname>
	<surname>Lehey</surname>
	<contrib>Az eredeti változatot írta:</contrib>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>A Vinum kötetkezelõ</title>

  <sect1 id="vinum-synopsis">
    <title>Áttekintés</title>

    <para>Nem számít, milyen lemezeink is vannak, ugyanis
      mindig adódnak velük kapcsolatban gondjaink:</para>

    <itemizedlist>
      <listitem>
	<para>Kicsik.</para>
      </listitem>

      <listitem>
	<para>Lassúk.</para>
      </listitem>

      <listitem>
	<para>Nem elég megbízhatóak.</para>
      </listitem>
    </itemizedlist>

    <para>Ezekre a problémákra javasoltak és meg is
      valósítottak számos megoldást.  A
      felhasználók egy része
      általában úgy védekezik ellenük,
      hogy több, gyakran redundánsan tároló
      lemezt használ.  A különféle
      kártyák és hardveres
      RAID-vezérlõk támogatása mellett a &os;
      alaprendszerében megtalálható egy blokkos
      eszközmeghajtóként a Vinum
      kötetkezelõ is, amellyel virtuális
      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
      három problémára próbál
      megoldást adni.  A Vinum a hagyományos lemezes
      tárolásnál jóval nagyobb
      rugalmasságot, teljesítményt és
      megbízhatóságot biztosít, valamint
      ismeri a RAID-0, RAID-1 és RAID-5 modelleket
      külön-külön és kombinálva
      is.</para>

    <para>Ebben a fejezetben összefoglaljuk a hagyományos
      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
	elgondolásokat, elnevezéseket és a lemezen
	tárolt metaadatok formátumát.  Ezt az
	újraírt változatot nevezik
	<emphasis>gvinum</emphasis>nak (<emphasis>GEOM
	vinum</emphasis>).  A szövegben a
	<emphasis>Vinum</emphasis>ra kizárólag csak
	általánosságban hivatkozunk,
	függetlenül az
	implementációjától.  Most már
	az összes parancsot a <command>gvinum</command>
	használatával kell kiadni, illetve a
	hozzá tartozó modul neve
	<filename>vinum.ko</filename>-ról
	<filename>geom_vinum.ko</filename>-ra változott és
	a megfelelõ eszközleírók a
	<filename class="directory">/dev/vinum</filename>
	könyvtár helyett a <filename
	  class="directory">/dev/gvinum</filename>
	könyvtárban találhatóak.  A &os; 6.
	verziójától pedig a régi Vinum
	implementáció többé már nem is
	része az alaprendszernek.</para>
    </note>

  </sect1>

  <sect1 id="vinum-intro">
    <title>Kicsik a lemezeink</title>

    <indexterm><primary>Vinum</primary></indexterm>
    <indexterm>
      <primary>RAID</primary>
      <secondary>szoftver</secondary>
    </indexterm>

    <para>A lemezek kapacitása ugyan növekszik, de
      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 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>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.
      Például egy nagy forgalmú FTP vagy HTTP
      szerver több 100&nbsp;Mbit/s sebességû
      kapcsolattal is csatlakozhat a világhálóhoz,
      amelyeken keresztül párhuzamosan többezernyi
      tranzakciót is folytathat, ami jelentõsen meghaladja a
      legtöbb lemez átlagos átviteli
      sebességét.</para>

    <para>A jelenleg kapható lemezek soros adatátviteli
      sebessége egészen 70&nbsp;MB/s-ig is terjedhet, de
      ennek az értéknek kevés a
      jelentõsége olyan környezetekben, ahol több,
      egymástól függetlenül futó program
      próbál egyszerre hozzáférni, hiszen
      ilyen esetekben csak a töredékét képesek
      elérni.  Ilyenkor sokkal érdekesebb a lemezt
      kezelõ alrendszer szempontjából nézni a
      problémát: így az egyes adatátviteli
      kérések terhelése lesz a
      meghatározó paraméter, vagyis az az idõ,
      amit a kérés teljesítésében
      érintett meghajtók eltöltenek a
      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 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 ezeket.</para>

    <para><anchor id="vinum-latency"/>Tekintsünk egy
      átlagosnak mondható, nagyjából
      10&nbsp;kB méretû adatátvitelt: a
      legújabb nagyteljesítményû lemezek
      átlagosan 3,5&nbsp;ms alatt képesek
      pozicionálni a fejeket.  A leggyorsabb lemezek
      15&nbsp;000&nbsp; fordulatot tesznek meg percenként (RPM),
      így az átlagos forgási
      késleltetés (egy fél fordulat ideje)
      2&nbsp;ms.  70&nbsp;MB/s-os sebesség mellett az
      átvitel maga megközelítõleg
      150&nbsp;&mu;s, ami szinte elhanyagolható a
      pozicionálás idejéhez képest.  Ilyen
      esetekben a tényleges adatátviteli sebesség
      1&nbsp;MB/s-nél alig valamivel többre esik vissza,
      és tisztán látszik, hogy erõsen
      függ az átvitt adat
      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>

    <para>Az adatátvitelben bekövetkezõ javulás
      pontos aránya természetesen kisebb, mint a lemezek
      száma: habár az egyes meghajtók
      képesek párhuzamosan mozgatni az adatokat, semmilyen
      módon garantálhatjuk, hogy a kérések
      egyenletesen oszlanak el köztük.  Emiatt szinte
      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>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
      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
      nevezik <emphasis>összefûzésnek</emphasis>,
      és elõnye, hogy a résztvevõ lemezeknek nem
      kell azonos méretûeknek lenniük.  Ez a
      megoldás remekül mûködik abban az esetben,
      amikor a virtuális lemez hozzáférései
      egyenletesen oszlanak el annak teljes területén.
      Amikor viszont az elérés csak egy kisebb
      területre korlátozódik, kevesebb javulás
      tapasztalható.  A <xref linkend="vinum-concat"/> mutatja be
      lemezek egy ilyen összefûzött
      konfigurációját.</para>

    <para>
      <figure id="vinum-concat">
	<title>Az összefûzött szervezési
	  mód</title>
	<graphic fileref="vinum/vinum-concat"/>
      </figure>
    </para>

  <indexterm><primary>lemezcsíkozás</primary></indexterm>
  <indexterm>
    <primary>Vinum</primary>
    <secondary>csíkozás</secondary>
  </indexterm>
  <indexterm><primary>RAID</primary></indexterm>

  <para>Feloszthatjuk a virtuális lemezünket kisebb azonos
    méretû darabokra is, melyeket
    különbözõ eszközökön sorosan
    tárolunk el.  Például az elsõ 256 szektort
    eltároljuk az elsõ lemezen, majd a következõ
    256 szektort a következõ lemezen és így
    tovább.  Az utolsó lemez kitöltése
    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
    (<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
    jelenthet olyan esetekben, amikor az adatátvitel több
    lemezt is érint, de ezzel egyidõben sokkal jobban
    szétosztja a terhelést a lemezek között.  A
    <xref linkend="vinum-striped"/> mutatja be a lemezek csíkozott
    szervezését.</para>

    <para>
      <figure id="vinum-striped">
	<title>A csíkozott szervezési mód</title>
	<graphic fileref="vinum/vinum-striped"/>
      </figure>
    </para>

  </sect1>

  <sect1 id="vinum-data-integrity">
    <title>Adatintegritás</title>

    <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 meglehetõsen sokat fejlõdtek az
      utóbbi pár évben, egy szervernek még
      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>Vinum</primary>
      <secondary>tükrözés</secondary>
    </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>
      (<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õ.
      Így ha az egyik meghajtó tönkremenne, egy
      másikon még mindig megtalálható az
      összes adat.</para>

    <para>A tükrözés két problémát
      vet fel:</para>

      <itemizedlist>
	<listitem>
	  <para>Ár.  Legalább kétszer annyiba
	    kerül, mint a nem redundánsan
	    tároló megoldások.</para>
	</listitem>

	<listitem>
	  <para>Teljesítménycsökkenés.  Mivel
	    az írást minden meghajtón végre
	    kell hajtani, legalább kétszer annyi
	    sávszélességet is felémeszt,
	    mint a nem tükrözött kötetek
	    esetén.  Az olvasás viszont nem veszít
	    a sebességébõl: sõt, még
	    gyorsabbnak is tûnhet.</para>
	</listitem>
      </itemizedlist>

    <indexterm><primary>lemezparitás</primary></indexterm>
    <indexterm>
      <primary>Vinum</primary>
      <secondary>paritás</secondary>
    </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>
      használata, melyet a 2, 3, 4 és 5
      <acronym>RAID</acronym>-szintek valósítanak meg.
      Ezek közül talán a <acronym>RAID-5</acronym> a
      legérdekesebb.  A Vinumban egy olyan csíkozott
      szervezési módként
      valósították meg, ahol minden
      csíkból egy blokk az összes többi
      paritási információját tartalmazza.  A
      <acronym>RAID-5</acronym> által megvalósított
      szervezés hasonlít a csíkozáshoz,
      azonban a <acronym>RAID-5</acronym>-ben mindegyik csík
      tartalmaz egy paritási információt is.
      Tehát a Vinumban, ahogy azt <acronym>RAID-5</acronym> a
      megköveteli, a paritást tároló blokkok
      helye az egyik csíkról a másikra
      változik.  Az adatblokkokban található
      számok relatív blokkszámokat
      jelölnek.</para>

    <para>
      <figure id="vinum-raid5-org">
	<title>A RAID-5 szervezési mód</title>
	<graphic fileref="vinum/vinum-raid5-org"/>
      </figure>
    </para>

    <para>A <acronym>RAID-5</acronym>-nek a tükrözéshez
      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ó
      meghajtókról továbbra is a megszokott
      módon lehet olvasni, viszont a sérült
      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">
    <title>A Vinum objektumai</title>

    <para>A tárgyalt problémák
      orvoslására a Vinumban egy négyszintû
      objektumhierarchiát alakítottak ki:</para>

    <itemizedlist>
      <listitem>
	<para>A legjobban észlelhetõ objektum a
	  virtuális lemez, amelyet
	  <emphasis>kötet</emphasis>nek (volume) nevezünk.  Ez
	  a kötet lényegében ugyanazokkal a
	  tulajdonságokkal rendelkezik, mint egy &unix;-os
	  lemezmeghajtó, habár akadnak finomabb
	  különbségek.  Mérete korlátlan
	  lehet.</para>
      </listitem>

      <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
	  elképzelni, melyek ugyanazt az adatot
	  tartalmazzák.</para>
      </listitem>

      <listitem>
	<para>Mivel a Vinum a &unix; lemezes tárolást
	  megvalósító alrendszerében
	  helyezkedik el, a többlemezes erek
	  felépítéséhez
	  használhatnánk a &unix;-os
	  partíciókat, azonban ehhez a feladathoz nem
	  eléggé rugalmasak, mivel a &unix;-os lemezek
	  csak korlátozott számú
	  partíciót tartalmazhatnak.  A Vinum ehelyett
	  <emphasis>allemez</emphasis>nek (subdisk) nevezett folytonos
	  területekre osztja fel az egyes &unix;-os
	  partíciókat (a
	  <emphasis>meghajtó</emphasis>kat), melyeket
	  aztán az erek létrehozására
	  használ fel.</para>
      </listitem>

      <listitem>
	<para>A Vinum által létrehozott
	  <emphasis>meghajtó</emphasis>kon (drive) levõ
	  allemezek lesznek valódi &unix;-os
	  partíciók.  A Vinum-meghajtók
	  tetszõleges számú allemezt tartalmazhatnak.
	  Eltekintve a meghajtó elején
	  található apró területtõl,
	  melyen a beállításokra és az
	  állapotra vonatkozó információk
	  tárolódnak, az egész meghajtó
	  felhasználható adatok
	  tárolására.</para>
      </listitem>
    </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
      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õ 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>
      <title>Redundáns adattárolás</title>

      <para>A Vinum a tükrözést több ér
	egyetlen kötetté olvasztásával hozza
	létre.  Az erek mindegyike a köteten
	található adatokat képviseli.  Egy
	kötet legalább egy, legfeljebb nyolc eret
	tartalmazhat.</para>

      <para>Habár egy ér egy kötet teljes
	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ó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>
      <title>Teljesítmény</title>

      <para>A Vinum az összefûzést és a
	csíkozást is egyaránt
	megvalósítja az erek szintjén:</para>

      <itemizedlist>
	<listitem>
	  <para>Az <emphasis>összefûzött
	    ér</emphasis> allemezek területeibõl
	    építkezik.</para>
	</listitem>

	<listitem>
	  <para>A <emphasis>csíkozott ér</emphasis>
	    felosztja az adatokat az allemezek között.  Az
	    allemezek mindegyikének ugyanakkorának kell
	    lennie, és legalább két allemeznek
	    lennie kell, hogy eltérjen az
	    összefûzött értõl.</para>
	</listitem>
      </itemizedlist>

    </sect2>

    <sect2>
      <title>Hogyan szervezzük az ereket?</title>

      <para>A &os;&nbsp;&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
	    hozzáadásával tovább
	    bõvíthetõ.  Kevesebb processzoridõt
	    igényel, mint egy csíkozott ér,
	    habár a kettõ többletköltsége
	    közti eltérés nem mérhetõ.
	    Másrészrõl azonban nagyon
	    érzékenyek a forgalmasabb pontokra, vagyis
	    amikor az egyik lemez folyamatosan használatban van,
	    miközben a többi üresen jár.</para>
	</listitem>

	<listitem>
	  <para>A csíkozott (<acronym>RAID-0</acronym>) erek
	    legnagyobb elõnye, hogy csökkentik a forgalmasabb
	    pontok kialakulását: a megfelelõ
	    méretû csíkszélesség (ami
	    kb.  256&nbsp;kB) választásával el
	    tudjuk egyengetni a tömbben dolgozó
	    meghajtók terhelését.  Ennek a
	    megközelítésnek a hátránya
	    (részben) a sokkal összetettebb kód,
	    valamint az allemezekre vonatkozó
	    megszorítás, amely szerint meg kell
	    egyezniük a méretüknek, illetve az
	    érhez annyira bonyolult újabb allemezeket
	    kapcsolni, hogy a Vinum jelenleg nem is képes
	    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
	    tér el egy összefûzött
	    értõl.</para>
	</listitem>
      </itemizedlist>

      <para>A <xref linkend="vinum-comparison"/> foglalja össze az
	egyes erezések elõnyeit és
	hátrányait.</para>

      <table id="vinum-comparison" frame="none">
	<title>Vinum erezések</title>
	<tgroup cols="5">
	  <thead>
	    <row>
	      <entry>Erezés típusa</entry>
	      <entry>Legkevesebb allemez</entry>
	      <entry>Bõvíthetõ</entry>
	      <entry>Megegyezõ méret</entry>
	      <entry>Alkalmazás</entry>
	    </row>
	  </thead>

	  <tbody>
	    <row>
	      <entry>összefûzött</entry>
	      <entry>1</entry>
	      <entry>igen</entry>
	      <entry>nem</entry>
	      <entry>Sok adat tárolása, ahol a
		hangsúly a rugalmasságon és a
		mérsékelt teljesítményen
		van.</entry>
	    </row>

	    <row>
	      <entry>csíkozott</entry>
	      <entry>2</entry>
	      <entry>nem</entry>
	      <entry>igen</entry>
	      <entry>Nagy teljesítmény, nagy
		mennyiségû egyidejû
		hozzáférés mellett</entry>
	    </row>
	  </tbody>
	</tgroup>
      </table>

    </sect2>
  </sect1>

  <sect1 id="vinum-examples">
    <title>Példák</title>

    <para>A Vinum a rendszerben ismert objektumokkal kapcsolatos
      információkat egy
      <emphasis>konfigurációs
      adatbázis</emphasis>ban tartja fenn.  Kezdetben a
      felhasználó egy vagy több
      konfigurációs állomány
      segítségével hozza létre ezt az
      adatbázist a &man.gvinum.8; segédprogrammal.  A
      Vinum ezt a konfigurációs adatbázist
      bemásolja mindegyik irányítása alatt
      álló slice-ba (melyek a Vinum
      <emphasis>eszköz</emphasis>nek hív).  Az
      adatbázis minden egyes állapotváltás
      folyamán frissül, így egy
      újraindítás után minden egyes
      Vinum-objektum állapota pontosan
      helyreállítódik.</para>

    <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
	ki:</para>

      <programlisting>
    drive a device /dev/da3h
    volume myvol
      plex org concat
        sd length 512m drive a</programlisting>

      <para>Ez az állomány négy Vinum-objektumot
	definiál:</para>

      <itemizedlist>
	<listitem>
	  <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
	    szimbolikus és a konkrét eszköznevek
	    szétválasztásával
	    lehetõvé válik, hogy a lemezek
	    félreértések nélkül
	    átkerülhessek egyik helyrõl a
	    másikra.</para>
	</listitem>

	<listitem>
	  <para>A <emphasis>volume</emphasis> kezdetû sor adja meg
	    a kötetet.  Itt az egyetlen szükséges
	    jellemzõ a név, ami ebben az esetben a
	    <emphasis>myvol</emphasis>.</para>
	</listitem>

	<listitem>
	  <para>A <emphasis>plex</emphasis> kezdetû sor adja meg az
	    eret.  Itt az egyetlen szükséges
	    paraméter a szervezési mód, ami ebben
	    az esetben a <emphasis>concat</emphasis>
	    (összefûzött).  Nevet nem kell megadnunk,
	    mivel a rendszer automatikusan létrehoz egy nevet a
	    kötet nevébõl a
	    <emphasis>.p</emphasis><emphasis>x</emphasis> utótag
	    hozzáadásával, ahol az
	    <emphasis>x</emphasis> az ér száma lesz a
	    köteten belül.  Emiatt a most definiált
	    ér neve <emphasis>myvol.p0</emphasis> lesz.</para>
	</listitem>

	<listitem>
	  <para>Az <emphasis>sd</emphasis> kezdetû sor adja meg az
	    allemezt.  Itt legalább meg kell adnunk a
	    meghajtónak a nevét, ahol tárolni
	    akarjuk, ill.  a méretét.  Ahogy már
	    említettük az ereknél is, nevet nem
	    kötelezõ megadnunk, mivel a rendszer
	    magától rendel hozzá nevet, amit a
	    hozzá tartozó ér nevébõl
	    származtat, hozzáadja a
	    <emphasis>.s</emphasis><emphasis>x</emphasis>
	    utótagot, ahol az <emphasis>x</emphasis> az allemez
	    éren belüli sorszáma lesz.  Ennek
	    következtében a Vinum ennek az allemeznek a
	    <emphasis>myvol.p0.s0</emphasis> nevet adja.</para>
	</listitem>
      </itemizedlist>

      <para>Miután a &man.gvinum.8; feldolgozta ezt az
	állományt, az alábbi kimenetet fogja
	adni:</para>

      <programlisting width="97">
      &prompt.root; gvinum -&gt; <userinput>create config1</userinput>
      Configuration summary
      Drives:         1 (4 configured)
      Volumes:        1 (4 configured)
      Plexes:         1 (8 configured)
      Subdisks:       1 (16 configured)

	D a                     State: up       Device /dev/da3h        Avail: 2061/2573 MB (80%)

	V myvol                 State: up       Plexes:       1 Size:        512 MB

	P myvol.p0            C State: up       Subdisks:     1 Size:        512 MB

	S myvol.p0.s0           State: up       PO:        0  B Size:        512 MB</programlisting>

      <para>Ez a kimenet a &man.gvinum.8; egyszerû
	listázási formátumát mutatja.
	Grafikusan a <xref linkend="vinum-simple-vol"/> mutatja
	be.</para>

      <para>
	<figure id="vinum-simple-vol">
	  <title>Egyszerû Vinum-kötet</title>
	  <graphic fileref="vinum/vinum-simple-vol"/>
	</figure>
      </para>

      <para>Ezen és az ezt követõ ábrán
	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>

      <para>Az itt bemutatott kötetnek nincs semmilyen elõnye
	a hagyományos lemezpartícionáláshoz
	képest.  Egyetlen eret tartalmaz, tehát nem is
	redundáns.  Az ér egyetlen allemezt tartalmaz,
	tehát nem tér el a megszokott
	lemezpartíciók
	helyfoglalásától sem.  A
	következõ szakaszokban sokkal érdekesebb
	konfigurációs módszereket is
	illusztrálunk.</para>

    </sect2>

    <sect2>
      <title>Megnövelt rugalmasság:
	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
	károsítják mind a két eret.  Az
	alábbi konfigurációban egy kötetet
	tükrözünk:</para>

      <programlisting>
	drive b device /dev/da4h
	volume mirror
      plex org concat
        sd length 512m drive a
	  plex org concat
	    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>

      <programlisting width="97">
	Drives:         2 (4 configured)
	Volumes:        2 (4 configured)
	Plexes:         3 (8 configured)
	Subdisks:       3 (16 configured)

	D a                     State: up       Device /dev/da3h        Avail: 1549/2573 MB (60%)
	D b                     State: up       Device /dev/da4h        Avail: 2061/2573 MB (80%)

    V myvol                 State: up       Plexes:       1 Size:        512 MB
    V mirror                State: up       Plexes:       2 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

    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</programlisting>

      <para>A <xref linkend="vinum-mirrored-vol"/> ugyanezt a szerkezetet
	grafikusan is.</para>

      <para>
	<figure id="vinum-mirrored-vol">
	  <title>Tükrözött Vinum-kötet</title>
	  <graphic fileref="vinum/vinum-mirrored-vol"/>
	</figure>
      </para>

      <para>Ebben a példában minden ér tartalmazza
	a teljes 512&nbsp;MB-os területet.  Ahogy a korábbi
	példa esetén, itt is mindegyik ér csak
	egyetlen allemezt tartalmaz.</para>

    </sect2>

    <sect2>
      <title>A teljesítmény javítása</title>

      <para>Az elõbbi példában szereplõ
	tükrözött kötet egy tükrözetlen
	kötetnél már jobban ellenáll a
	hibáknak, azonban a teljesítménye is
	kisebb.  A köteten minden egyes írás mind a
	két meghajtóra érvényesül,
	ezáltal a lemezek teljes
	sávszélességét nagyobb
	arányban használja.  A
	teljesítményre vonatkozó
	megfontolásaink egy másik
	megközelítést kívánnak meg: a
	tükrözés helyett inkább csíkozzuk
	szét az adatot a lehetõ legtöbb lemezen.  Az
	alábbi konfiguráció egy olyan kötetet
	mutat be, ahol egy eret négy lemezmeghajtóan
	keresztül csíkozunk:</para>

      <programlisting>
	drive c device /dev/da5h
	drive d device /dev/da6h
	volume stripe
	plex org striped 512k
	  sd length 128m drive a
	  sd length 128m drive b
	  sd length 128m drive c
	  sd length 128m drive d</programlisting>

      <para>Mint ahogy azt már korábban is
	említettük, nem szükséges még
	egyszer megadni azokat a meghajtókat, amiket a Vinum
	már ismer.  A definíció feldolgozása
	után a konfigurációnk
	nagyjából így néz ki:</para>

      <programlisting width="92">
	Drives:         4 (4 configured)
	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
    S striped.p0.s0         State: up       PO:        0  B Size:        128 MB
    S striped.p0.s1         State: up       PO:      512 kB Size:        128 MB
    S striped.p0.s2         State: up       PO:     1024 kB Size:        128 MB
    S striped.p0.s3         State: up       PO:     1536 kB Size:        128 MB</programlisting>

      <para>
	<figure id="vinum-striped-vol">
	  <title>Csíkozott Vinum-kötet</title>
	  <graphic fileref="vinum/vinum-striped-vol"/>
	</figure>
      </para>

      <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>
      <title>Rugalmasság és
	teljesítmény</title>

      <para><anchor id="vinum-resilience"/>Megfelelõ hardver
	birtokában lehet olyan köteteket is
	építeni, amelyek mind megnövelt
	rugalmasságot, mind pedig megnövelt
	teljesítményt mutatnak a szabványos
	&unix;-os partíciókhoz képest.  Ennek a
	konfigurációs állománya így
	nézne ki:</para>

      <programlisting>
	volume raid10
      plex org striped 512k
        sd length 102480k drive a
        sd length 102480k drive b
        sd length 102480k drive c
        sd length 102480k drive d
        sd length 102480k drive e
      plex org striped 512k
        sd length 102480k drive c
        sd length 102480k drive d
        sd length 102480k drive e
        sd length 102480k drive a
        sd length 102480k drive b</programlisting>

      <para>A második ér allemezei el vannak tolva az
	elsõ ér allemezeitõl két
	meghajtónyival.  Ez segít megelõzni, hogy az
	írási mûveletek ne ugyanarra az allemezre
	vonatkozznak, még akkor is, ha az adatátvitel
	két meghajtón is keresztülível.</para>

      <para>A <xref linkend="vinum-raid10-vol"/> illusztrálja
	ennek a kötetnek a szerkezetét.</para>

      <para>
	<figure id="vinum-raid10-vol">
	  <title>Tükrözött, csíkozott
	    Vinum-kötet</title>
	  <graphic fileref="vinum/vinum-raid10-vol"/>
        </figure>
      </para>

    </sect2>
  </sect1>

  <sect1 id="vinum-object-naming">
    <title>Az objektumok elnevezése</title>

    <para>Korábban már megismerhettük, hogy a Vinum
      alapértelmezett neveket társít az erekhez
      é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
      rendelhetünk az objektumokhoz, használata során
      kiderült, hogy akkora mértékû
      rugalmasságot nem kínál fel, mint amennyi
      zavart képes okozni.</para>

    <para>A nevek tartalmazhatnak bármilyen nem üres
      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
      akár 64 karakteresek is lehetnek, a meghajtók nevei
      pedig 32 karakteresek.</para>

    <para>A Vinum objektumai a <filename
	class="directory">/dev/gvinum</filename> 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 következõ
      eszközleírók jönnek létre:</para>

    <itemizedlist>
      <listitem>
	<note>
	  <para>Ez a rész csak a Vinum korábbi, elavult
	    implementációjára vonatkozik.</para>
	</note>

	<para>A <filename
	    class="devicefile">/dev/vinum/control</filename> és
	  <filename class="devicefile">/dev/vinum/controld</filename>
	  nevû vezérlõeszközök, melyeket a
	  &man.gvinum.8; és a Vinum démon
	  használ.</para>
      </listitem>

      <listitem>
	<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 class="devicefile">/dev/gvinum/myvol</filename>,
	  <filename class="devicefile">/dev/gvinum/mirror</filename>,
	  <filename class="devicefile">/dev/gvinum/striped</filename>,
	  <filename class="devicefile">/dev/gvinum/raid5</filename>
	  és <filename
	    class="devicefile">/dev/gvinum/raid10</filename>
	  eszközök.</para>
      </listitem>

      <listitem>
	<note>
	  <para>Ez a rész csak a Vinum korábbi, elavult
	    implementációjára vonatkozik.</para>
	</note>

	<para>Az egyes meghajtókhoz tartozó
	  leírók a <filename
	    class="directory">/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>Minden kötethez közvetlen leírók
	  tartoznak <filename class="directory">/dev/gvinum</filename>
	  könyvtárban.</para>
      </listitem>

      <listitem>
	<para>Az egyes erek és allemezek
	  eszközleírói a
	  <filename class="directory">/dev/gvinum/plex</filename>
	  és <filename
	    class="directory">/dev/gvinum/sd</filename>
	  könyvtárakban jelennek meg.</para>
      </listitem>
    </itemizedlist>

    <para>Például tekintsük most az alábbi
      konfigurációs állományt:</para>

	<programlisting>
	drive drive1 device /dev/sd1h
	drive drive2 device /dev/sd2h
	drive drive3 device /dev/sd3h
	drive drive4 device /dev/sd4h
    volume s64 setupstate
      plex org striped 64k
        sd length 100m drive drive1
        sd length 100m drive drive2
        sd length 100m drive drive3
        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 class="directory">/dev/gvinum</filename>
      könyvtárban:</para>

    <programlisting>
	drwxr-xr-x  2 root  wheel       512 Apr 13 16:46 plex
	crwxr-xr--  1 root  wheel   91,   2 Apr 13 16:46 s64
	drwxr-xr-x  2 root  wheel       512 Apr 13 16:46 sd

    /dev/vinum/plex:
    total 0
    crwxr-xr--  1 root  wheel   25, 0x10000002 Apr 13 16:46 s64.p0

    /dev/vinum/sd:
    total 0
    crwxr-xr--  1 root  wheel   91, 0x20000002 Apr 13 16:46 s64.p0.s0
    crwxr-xr--  1 root  wheel   91, 0x20100002 Apr 13 16:46 s64.p0.s1
    crwxr-xr--  1 root  wheel   91, 0x20200002 Apr 13 16:46 s64.p0.s2
    crwxr-xr--  1 root  wheel   91, 0x20300002 Apr 13 16:46 s64.p0.s3</programlisting>

    <para>Jóllehet, az ereket és allemezeket nem
      ajánlott külön-külön elnevezni, a Vinum
      meghajtóknak nevet kell adni.  Ezzel
      megoldhatóvá válik, hogy az egyes
      meghajtók automatikusan felismerhetõek legyenek abban
      az esetben is, amikor fizikailag áthelyezzük ezeket.
      A meghajtók nevei legfeljebb 32 karakteresek
      lehetnek.</para>

    <sect2>
      <title>Állományrendszerek
	létrehozása</title>

      <para>A kötetek egyetlen kivétellel teljesen azonosak
	a lemezekkel a rendszer számára.  Ugyanis a
	&unix;-os meghajtóktól eltérõen a
	Vinum nem particionálja a köteteket, és
	ezért nem is tárolnak partíciós
	táblát.  Ez megkövetelte néhány
	lemezkezelõ segédprogram, leginkább a
	&man.newfs.8; módosítását, mivel
	azok korábban megpróbálták a
	Vinum-kötetek nevének utolsó betûit egy
	partíció azonosítójaként
	értelmezni.  Például egy lemezes
	meghajtó neve <filename
	  class="devicefile">/dev/ad0a</filename> vagy <filename
	  class="devicefile">/dev/da2h</filename> alakú.  Az
	elõbbi az elsõ (0) IDE lemez elsõ
	(<devicename>a</devicename>) partícióját,
	míg az utóbbi a harmadik (2) SCSI lemez nyolcadik
	(<devicename>h</devicename>) partícióját
	jelöli.  Ezzel szemben azonban a Vinum-kötetek neve
	<filename class="devicefile">/dev/gvinum/concat</filename>
	alakú lesz, ahol a név semmilyen kapcsolatban nem
	áll a 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.
	Például:</para>

      <screen>&prompt.root; <userinput>newfs /dev/gvinum/concat</userinput>
newfs: /dev/gvinum/concat: can't figure out file system partition</screen>

      <para>A köteten a &man.newfs.8; parancs
	kiadásával tudunk állományrendszert
	létrehozni:</para>

      <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>

	<screen>&prompt.root; <userinput>newfs -v /dev/vinum/concat</userinput></screen>
      </note>
    </sect2>
  </sect1>

  <sect1 id="vinum-config">
    <title>A Vinum beállítása</title>

    <para>A <filename>GENERIC</filename> rendszermag nem tartalmazza a
      Vinumot.  Habár készíteni lehet olyan
      rendszermagot, amelyik támogatja a Vinumot, mégsem
      ajánlott.  A Vinumot a szabványos módon
      modulként (<acronym>kld</acronym>) indíthatjuk el.
      Még a &man.kldload.8; használatára sincs
      szükség, mivel a &man.gvinum.8; indulása
      során ellenõrzi a modul jelenlétét
      és betölti, ha még nem lenne jelen.</para>

    <sect2>
      <title>Indítás</title>

      <para>A Vinum alapvetõen ugyanúgy tárolja a
	konfigurációkat a slice-okban, mint maguk a
	konfigurációs állományok.  A
	konfigurációs adatbázis beolvasása
	során a Vinum felismeri azokat a kulcsszavakat,
	amelyeknek nem szabad elõfordulniuk az
	állományokban.  Például a lemezek
	beállítása tartalmazhatja a
	következõ szöveget:</para>

      <programlisting width="119">volume myvol state up
volume bigraid state down
plex name myvol.p0 state up org concat vol myvol
plex name myvol.p1 state up org concat vol myvol
plex name myvol.p2 state init org striped 512b vol myvol
plex name bigraid.p0 state initializing org raid5 512b vol bigraid
sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b
sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b
sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b
sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b
sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b
sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b
sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b
sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b
sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b
sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b
sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b
sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b
sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b</programlisting>

      <para>Az elõbbiektõl nyilvánvalóan
	eltér abban, hogy itt már megjelennek a
	konkrét pozíciókra és
	elnevezésekre vonatkozó információk
	(melyeket a felhasználó is megadhat, azonban ezt
	nem tanácsoljuk), valamint az állapotok (ezeket
	nem láthatja a felhasználó).  A Vinum a
	konfigurációban nem tárolja a
	meghajtókat, helyette a beállított lemezes
	meghajtók partícióin fog
	Vinum-címkéket keresni.  Ennek
	köszönhetõen a Vinum még akkor is
	képes pontosan megtalálni a meghajtókat,
	amikor megváltoznak a hozzá tartozó
	&unix;-os meghajtók azonosítói.</para>

      <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
	    &man.loader.conf.5; közvetítésével
	    a <emphasis>Gvinum</emphasis> mindig automatikusan elindul a
	    hozzá tartozó modul
	    betöltésével együtt.  Ha a
	    rendszerindításkor be akarjuk tölteni a
	    <emphasis>Gvinum</emphasis> modult, akkor a
	    <filename>/boot/loader.conf</filename>
	    állományba vegyük fel a
	    <literal>geom_vinum_load="YES"</literal> sort.</para>
	</note>

	<para>Az alábbi sort mindenképpen hozzá
	  kell adnunk az <filename>/etc/rc.conf</filename>
	  állományhoz, hogy a Vinum a
	  rendszerindítás során automatikusan
	  elinduljon:</para>

	<programlisting>start_vinum="YES"		# állítsuk YES-re az indításhoz</programlisting>

	<para>Hozzuk létre és írjuk bele, ha nem
	  lenne <filename>/etc/rc.conf</filename> nevû
	  állományunk.  Ennek hatására a
	  rendszer az indulás során betölti a Vinum
	  <acronym>kld</acronym> modult, és a
	  konfigurációban szereplõ objektumokat
	  elindítja.  Ez még az
	  állományrendszerek csatlakoztatása
	  elõtt történik meg, aminek
	  révén a Vinum-köteteken
	  található állományrendszereket a
	  rendszer automatikusan át tudja vizsgálni az
	  &man.fsck.8; segítségével, majd
	  csatlakoztatja ezeket.</para>

	<para>Amikor a Vinumot a <command>vinum start</command>
	  paranccsal indítjuk el, a Vinum beolvassa a
	  konfigurációs adatbázist a
	  Vinum-meghajtók egyikérõl.  Normál
	  körülmények között mindegyik
	  meghajtón megtalálható a
	  konfigurációs adatbázis egy
	  példánya, ezért szinte teljesen mindegy,
	  melyik meghajtót is olvassa.  Egy
	  rendszer-összeomlás után azonban a Vinumnak
	  meg kell tudnia állapítania, melyik
	  meghajtón található meg az
	  adatbázis legfrissebb példánya, és
	  ezt kell beolvasnia.  Ezután a lemaradt
	  meghajtókon található
	  adatbázispéldányokat
	  szinkronizálja ehhez a változathoz.</para>

      </sect3>
    </sect2>
  </sect1>

  <sect1 id="vinum-root">
    <title>Rendszerindítás
      Vinum-kötetrõl</title>

    <para>Olyan számítógépeknél, ahol
      a teljesen tükrözött Vinum-alapú
      állományrendszereket használunk,
      kívánatos lehet magát a
      rendszerindításhoz használt
      állományrendszert is tükrözni.  Egy ilyen
      konfiguráció összeállítása
      már messze nem annyira egyszerû, mint egy
      tetszõleges állományrendszer esetén,
      mivel:</para>

    <itemizedlist>
      <listitem>
	<para>Az indításhoz használt
	  állományrendszernek már a folyamat nagyon
	  korai szakaszában rendelkezésre kell
	  állnia, ezért a Vinumnak már itt
	  elérhetõnek kell lennie.</para>
      </listitem>
      <listitem>
	<para>A rendszerindító
	  állományrendszert tartalmazó köteten
	  még ott kell lennie a rendszerindító
	  kódnak és a rendszermagnak is, melyeket a
	  rendszer saját eszközein (például
	  ilyen a BIOS a PC-knél) keresztül kell tudnunk
	  beolvasni, amiket viszont nem tudunk
	  felkészíteni a Vinumra.</para>
      </listitem>
    </itemizedlist>

    <para>A soronkövetkezõ szakaszokban
      <quote>rendszerindító kötetként</quote>
      (root volume) fogunk általánosságban
      véve hivatkozni a rendszerindításhoz
      használt állományrendszert tartalmazó
      Vinum-kötetre.  Ennek megfelelõen
      valószínûleg jó ötlet a
      <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>

    <sect2>
      <title>A Vinum kellõen korai indítása</title>

      <para>Ennek kiváltásához számos
	lépést kell megtennünk:</para>

      <itemizedlist>
	<listitem>
	  <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
	    <emphasis>nem</emphasis> is szabad használni a most
	    ismertetendõ konfigurációban.  A Vinumot
	    statikusan bele is építhetjük a
	    rendszermagba és így állandóan
	    elérhetõ, de ez általában nem
	    kielégítõ megoldás.  Megoldhatjuk
	    úgy is, ha a <filename>/boot/loader</filename>-re
	    (<xref linkend="boot-loader"/>) bízzuk a vinum modul
	    betöltését, még a rendszermag
	    elõtt.  Ezt az alábbi sorral válthatjuk
	    ki a <filename>/boot/loader.conf</filename>
	    állományban:</para>

	  <programlisting>geom_vinum_load="YES"</programlisting>
	</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>

	  <para>A Vinumot nagyon korán életre kell
	    keltenünk, hiszen a rendszerindításhoz
	    használt állományrendszert
	    tartalmazó kötetet kell
	    élesítenünk.
	    Alapértelmezés szerint a Vinum rendszerszinten
	    futó része nem keres addig semmilyen
	    Vinum-kötetinformációval rendelkezõ
	    meghajtót, amíg a rendszergazda (vagy
	    valamelyik rendszerindító szkript) ki nem adja
	    a <command>vinum start</command> parancsot.</para>

	  <note>
	    <para>A most következõ bekezdések
	      mutatják be a szükséges
	      lépéseket.</para>
	  </note>

	  <para>Ha hozzáadjuk a következõ sort a
	    <filename>/boot/loader.conf</filename>
	    állományhoz, akkor azzal utasíthatjuk a
	    Vinumot, hogy a rendszermag indítása
	    során vizsgálja át az összes
	    meghajtót:</para>

	  <programlisting>vinum.autostart="YES"</programlisting>

	  <para>Nem szükséges megmondani a rendszermagnak,
	    merre keresse a rendszerindításhoz
	    használt állományrendszert.  A
	    <filename>/boot/loader</filename> megkeresi a
	    hozzá tartozó eszközt a
	    <filename>/etc/fstab</filename> állományban
	    és átadja ezt az információt a
	    rendszermagnak.  Amikor a csatlakoztatására
	    kerül sor, a rendszermag az eszköz
	    nevébõl meg tudja állapítani,
	    melyik eszközmeghajtót kérje meg a
	    belsõ (fõ- és
	    al)eszközazonosító
	    leképzéséhez.</para>
	</listitem>
      </itemizedlist>

    </sect2>

    <sect2>
      <title>A Vinum-alapú rendszerindító
	kötet elérése a rendszertöltés
	során</title>

      <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 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
	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>

      <para>Mindez csak akkor válik
	elérhetõvé, ha az alábbi
	követelményeket teljesíti a
	rendszerindító kötet:</para>

      <itemizedlist>
	<listitem>
	  <para>Nem lehet csíkozott vagy RAID-5
	    típusú.</para>
	</listitem>

	<listitem>
	  <para>Erenként nem tartalmazhat egynél több
	    összefûzött allemezt.</para>
	</listitem>
      </itemizedlist>

      <para>Láthatjuk, hogy hasznos és lehetséges
	is több eret használni, melyek mindegyike a
	rendszerindító állományrendszer
	egy-egy másolatát tartalmazza.  Az indulás
	folyamán azonban ezen példányok
	közül csak az egyiken fogja keresni a rendszer a
	rendszertöltõt és a többi
	állományt egészen addig, amíg a
	rendszermag magát az állományrendszert nem
	csatlakoztatja.  A látszat kedvéért az
	ereken belül található allemezek
	mindegyikének lennie kell egy saját
	<literal>"a"</literal> partíciójának,
	amivel lényegében alkalmassá válik a
	rendszerindításra.  Ezeknek a hamis
	<literal>"a"</literal> partícióknak nem kell
	feltétlenül a többiekkel megegyezõ
	pozíciókon elhelyezkedniük, azonban a
	tévedések elkerülése
	érdekében valószínûleg hasznos
	olyan Vinum-köteteket létrehozni, ahol a
	keletkezõ tükrözött eszközök
	szimmetrikusak.</para>

      <para>A rendszerindító kötet egyes
	eszközökön található
	<literal>"a"</literal> partícióit az
	alábbiak segítségével
	állíthatjuk be:</para>

      <procedure>
	<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
	    eltolását) és méretét
	    ellenõrizni kell az alábbi parancs
	    segítségével:</para>

	  <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.
	    Ezekbõl tehát úgy nyerünk a
	    <command>bsdlabel</command> használatához
	    szükséges blokkszámokat, ha ezeket
	    elosztjuk 512-vel.</para>
	</step>

	<step>
	  <para>Futassuk le a</para>

	  <screen>&prompt.root; <userinput>bsdlabel -e <replaceable>eszköznév</replaceable></userinput></screen>

	  <para>parancsot minden olyan eszközön, amelyik
	    részt vesz a rendszerindító kötet
	    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
	    például <devicename>da0</devicename>), vagy
	    ellenkezõ esetben a slice neve (például
	    <devicename>ad0s1</devicename>).</para>

	  <para>Ha már lenne egy <literal>"a"</literal>
	    partíció az eszközön
	    (valószínûleg egy Vinum elõtti
	    rendszeríndító
	    állományrendszert tartalmaz), nevezzük
	    át valami másra és így
	    továbbra is elérhetõ marad (biztos, ami
	    biztos), viszont többé már nem lesz a
	    rendszer számára alapértelmezett
	    rendszerindító eszköz.  Az aktív
	    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
	    <quote>Fixit</quote> (Helyreállító)
	    eszközrõl indítjuk, vagy egy olyan
	    kétlépéses folyamat során, ahol
	    (tükrözés esetén) a lemezrõl
	    még nem indítottuk el a rendszert.</para>

	  <para>Ezt követõen az eszközön
	    található Vinum-partíciót
	    (amennyiben létezik) az eszközön levõ
	    allemez eltolásához kell helyezni.  Ennek
	    eredménye lesz az új <literal>"a"</literal>
	    partíció <literal>"offset"</literal>
	    értéke.  A partíció
	    <literal>"size"</literal> (méret)
	    értéke szó szerint
	    átemelhetõ a fenti
	    számításból.  Az
	    <literal>"fstype"</literal> legyen
	    <literal>4.2BSD</literal>.  Az <literal>"fsize"</literal>,
	    <literal>"bsize"</literal> és
	    <literal>"cpg"</literal> értékeket a jelenlegi
	    állományrendszerhez mérten
	    ajánlott megválasztani, azonban itt most
	    egyáltalán nem bírnak
	    jelentõséggel.</para>

	  <para>Ezzel a módszerrel
	    létesítettünk egy olyan új
	    <literal>"a"</literal> partíciót, amely lefedi
	    az eszközön található
	    Vinum-partíciót.  Jegyezzük meg, hogy a
	    <command>bsdlabel</command> kizárolag csak abban az
	    esetben fogja megengedi ezt az átfedést, ha a
	    Vinum-partíciónk <literal>"vinum"</literal>
	    típussal van megjelölve.</para>
	</step>

	<step>
	  <para>Készen is vagyunk!  Most már van minden
	    eszközön egy hamisított
	    <literal>"a"</literal> partíciónk, amelyeken
	    megtalálható a rendszerindító
	    kötet egy-egy másolata.  Határozottan
	    ajánlott még egyszer ellenõrizni a
	    munkánkat az alábbi parancs
	    kiadásával:</para>

	  <screen>&prompt.root; <userinput>fsck -n /dev/<replaceable>eszköznév</replaceable>a</userinput></screen>
	</step>
      </procedure>

      <para>Figyeljünk arra, hogy az összes
	vezérlési információt
	tartalmazó állománynak a Vinum-köteten
	található rendszerindító
	állományrendszerre kell vonatkoznia, ami viszont
	egy új Vinum rendszerindító kötet
	beállítása után nem
	feltétlenül egyezik meg a jelenlegi aktív
	állományrendszerrel.  Különösen az
	<filename>/etc/fstab</filename> és
	<filename>/boot/loader.conf</filename>
	állományokat kell ilyen szempontból
	ellenõriznünk.</para>

      <para>A következõ indítás során a
	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ó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>
      <title>Egy Vinum-alapú rendszerindító
	á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>

	<screen>
...
Subdisk root.p0.s0:
		Size:        125829120 bytes (120 MB)
		State: up
		Plex root.p0 at offset 0 (0  B)
		Drive disk0 (/dev/da0h) at offset 135680 (132 kB)

Subdisk root.p1.s0:
		Size:        125829120 bytes (120 MB)
		State: up
		Plex root.p1 at offset 0 (0  B)
		Drive disk1 (/dev/da1h) at offset 135680 (132 kB)
	</screen>

      <para>Itt (a <filename class="devicefile">/dev/da0h</filename>
	partícióhoz képesti)
	<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&nbsp;byte-os
	blokkra a lemezen.  Ehhez hasonlóan a
	rendszerindító kötet mérete
	245&nbsp;760 darab 512&nbsp;byte-os blokk lesz.  A
	rendszerindító kötet
	másodpéldányát tartalmazó
	<filename class="devicefile">/dev/da1h</filename> ugyanilyen
	beállításokkal rendelkezik.</para>

      <para>Az említett eszközök valahogy így
	jelennek meg a <command>bsdlabel</command> szerint:</para>

	<screen>
...
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   245760      281    4.2BSD     2048 16384     0   # (Cyl.    0*- 15*)
  c: 71771688        0    unused        0     0         # (Cyl.    0 - 4467*)
  h: 71771672       16     vinum                        # (Cyl.    0*- 4467*)
	</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
	<literal>"offset"</literal> paraméter
	értéke egyenlõ lesz a <literal>"h"</literal>
	Vinum-partíción belüli eltolás
	és az eszközön (vagy slice-on) belüli
	eltolás összegével.  Ez jellemzõen egy
	olyan beállítás, amivel
	szükségszerûen el tudjuk kerülni a <xref
	linkend="vinum-root-panic"/>ban leírt
	hibajelenséget.  Látható
	továbbá az is, hogy az egész
	<literal>"a"</literal> partíció végig az
	eszköz összes Vinum adatát tartalmazó
	<literal>"h"</literal> partíciójában foglal
	helyet.</para>

      <para>A példával kapcsolatban megjegyezzük,
	hogy itt az egész eszközt a Vinum felügyelete
	alá bocsátottuk, tehát nem marad
	hátra semmilyen Vinum elõtt használt
	rendszerindító partíció, hiszen ez
	egy olyan lemez, amelyet eleve egy
	Vinum-konfigurációba szántunk.</para>

    </sect2>

    <sect2>
      <title>Hibakeresés</title>

      <para>Fontos tudunk, hogy probléma esetén hogyan
	tudjuk helyreállítani a rendszerünket.  A
	következõ felsorolásban bemutatunk
	néhány ismert buktatót és a
	megoldásaikat.</para>

      <sect3>
	<title>A rendszertöltõ elindul, de a rendszer viszont
	  már nem</title>

	<para>Ha valamilyen okból a rendszer nem indulna el, a 10
	  másodpercig tartó
	  visszaszámlálás során a
	  rendszertöltõt még meg tudjuk
	  állítani a <keycap>szóköz</keycap>
	  lenyomásával.  Ekkor a betöltõ
	  által használt változók (mint
	  például a <literal>vinum.autostart</literal>) a
	  <command>show</command> segítségével
	  megvizsgálhatóak és a
	  <command>set</command> vagy <command>unset</command>
	  parancsokkal módosíthatóak.</para>

	<para>Ha mindössze az volt a probléma, hogy a Vinum
	  modulja nem szerepelt az automatikusan betöltendõ
	  modulok között, a <command>load geom_vinum</command>
	  parancs kiadásával betölthetjük
	  azt.</para>

	<para>Miután végeztünk, a
	  rendszerindítás folyamata a <command>boot
	  -as</command> paranccsal folytatható.  A
	  <option>-as</option> kapcsolók jelzik a rendszermag
	  számára, hogy kérdezzen rá a
	  rendszerindító állományrendszerre
	  a csatlakoztatása elõtt (<option>-a</option>)
	  és csak egyfelhasználós módban
	  indítsa a rendszert (<option>-s</option>), ahol a
	  rendszerindító állományrendszer
	  írásvédett.  Így, ha csak egyetlen
	  eret csatlakoztattunk egy többeres kötetbõl, az
	  erek még véletlenül sem tudnak
	  egymásnak ellentmondó állapotba
	  kerülni.</para>

	<para>Amikor megjelenik a csatlakoztatandó
	  rendszerindító állományrendszert
	  bekérése, bármelyik
	  érvényes rendszerindításra
	  alkalmas állományrendszer megadható.
	  Amennyiben az <filename>/etc/fstab</filename>
	  állományt jól beállítottuk,
	  az alapértelmezett érték egy
	  <literal>ufs:/dev/gvinum/root</literal> értékhez
	  hasonló alakú lesz.  Itt általában
	  egy <literal>ufs:da0d</literal> formátumú
	  értéket láthatunk, amely feltehetõen
	  egy Vinum használata elõtti
	  rendszerindító állományrendszert
	  tartalmazó partíció.  Legyünk
	  óvatosak, ha itt egy olyan <literal>"a"</literal>
	  partíciót adunk meg, amely
	  valójában egy rendszerindító
	  Vinum-eszköz allemezeire hivatkozik, mivel egy
	  tükrözött konfiguráció
	  esetén csak az eszköz egyik részét
	  fogjuk csatlakoztatni.  Ha a késõbbiekben ezt az
	  állományrendszert már nem csak
	  írásvédett módban csatlakoztatjuk,
	  mindenképpen el kell távolítanunk a
	  rendszerindító Vinum-kötetbõl a
	  többi eret, mivel máskülönben nagy
	  valószínûséggel eltérõ
	  adatokat fognak tartalmazni.</para>

      </sect3>

      <sect3>
	<title>Csak az elsõdleges rendszertöltõ indul
	  el</title>

	<para>Amikor az elsõdleges rendszertöltõ
	  még elindul, viszont a
	  <filename>/boot/loader</filename> már nem tud
	  betöltõdni (ezt rendszerindítás
	  megkezdése után bal oldalt rögtön
	  megjelenõ forgó vonalból vehetjük
	  észre), a <keycap>szóköz</keycap>
	  lenyomásával itt még tehetünk egy
	  kísérletet a betöltés
	  megszakítására.  Ennek
	  hatására a rendszertöltés
	  megáll a második fázisban, lásd
	  <xref linkend="boot-boot1"/>.  Itt a
	  rendszerindításhoz megpróbálhatunk
	  megadni egy másik partíciót,
	  például egy olyat, amely a korábbi
	  rendszerindító állományrendszert
	  tartalmazza és amelyet az elõbb
	  átneveztünk az
	  <literal>"a"</literal>-ról.</para>

      </sect3>

      <sect3 id="vinum-root-panic">
	<title>Semmi sem indul, a rendszertöltõ hibákat
	  ír</title>

	<para>Ez a helyzet akkor állhat elõ, ha a Vinum
	  telepítése során tönkretettük
	  volna a rendszertöltõt.  Sajnos a Vinum minden
	  esetben 4&nbsp;KB helyet hagy szabadon a
	  partíció elején, a saját
	  fejléc információjának
	  rögzítése elõtt.  Az ide
	  kerülõ elsõ és második
	  fázisú rendszertöltõk, illetve a
	  bsdlabel adatai azonban jelenleg 8&nbsp;KB helyet
	  kívánnak meg.  Így ha a
	  Vinum-partíció egy
	  rendszerindításra szánt slice vagy lemez
	  0.  eltolásánál kezdõdik, a Vinum
	  beállításai felül fogják
	  írni a rendszertöltõt.</para>

	<para>A rendszertöltõ is ugyanígy
	  felülírja a Vinum fejlécét és
	  akkor a Vinum nem találja a lemezeit, ha a fenti
	  problémát orvosolva, például egy
	  <quote>Fixit</quote> (Helyreállító) lemez
	  segítségével,
	  újratelepítjük a rendszertöltõt a
	  <xref linkend="boot-boot1"/>ban bemutatott <command>bsdlabel
	  -B</command> parancs segítségével.  Noha
	  a Vinum egyetlen konkrét konfigurációs
	  beállítása vagy a kötetekben
	  tárolt adat sem sérül meg és vissza
	  tudjuk állítani az összes elveszett
	  információt ugyannak a
	  Vinum-konfigurációnak az újbóli
	  megadásával, a helyzetet magát
	  nehéz megoldani.  A Vinum-fejléc és a
	  rendszertöltõ ütközésének
	  megszüntetéséhez ugyanis legalább
	  4&nbsp;KB-tal arrébb kell mozgatnunk az egész
	  Vinum-partíciót.</para>

      </sect3>
    </sect2>
  </sect1>
</chapter>