PERFORCE change 128708 for review
Gabor Pali
pgj at FreeBSD.org
Mon Nov 5 14:58:10 PST 2007
http://perforce.freebsd.org/chv.cgi?CH=128708
Change 128708 by pgj at disznohal on 2007/11/05 22:57:57
Add initial Hungarian translation of Chapter 20: The Vinum Volume
Manager.
Affected files ...
.. //depot/projects/docproj_hu/books/handbook/vinum/chapter.sgml#2 edit
Differences ...
==== //depot/projects/docproj_hu/books/handbook/vinum/chapter.sgml#2 (text+ko) ====
@@ -1,488 +1,664 @@
<!--
- The Vinum Volume Manager
- By Greg Lehey (grog at lemis dot com)
+ The Vinum Volume Manager
+ By Greg Lehey (grog at lemis dot com)
- Added to the Handbook by Hiten Pandya <hmp at FreeBSD.org>
- and Tom Rhodes <trhodes at FreeBSD.org>
+ Added to the Handbook by Hiten Pandya <hmp at FreeBSD.org>
+ and Tom Rhodes <trhodes at FreeBSD.org>
- For the FreeBSD Documentation Project
- $FreeBSD: doc/en_US.ISO8859-1/books/handbook/vinum/chapter.sgml,v 1.44 2007/03/06 22:47:35 keramida Exp $
+ For the FreeBSD Documentation Project
+ $FreeBSD: doc/en_US.ISO8859-1/books/handbook/vinum/chapter.sgml,v 1.44 2007/03/06 22:47:35 keramida Exp $
-->
+<!-- The FreeBSD Hungarian Documentation Project
+ Translated by: PALI, Gabor <pgj at FreeBSD.org>
+ Original Revision: 1.44 -->
-<chapter id="vinum-vinum">
+<chapter id="vinum-vinum" lang="hu">
<chapterinfo>
<authorgroup>
<author>
<firstname>Greg</firstname>
<surname>Lehey</surname>
- <contrib>Originally written by </contrib>
+ <contrib>Eredetileg írta:</contrib>
</author>
</authorgroup>
</chapterinfo>
- <title>The Vinum Volume Manager</title>
+ <title>A Vinum kötetkezelõ</title>
<sect1 id="vinum-synopsis">
- <title>Synopsis</title>
+ <title>Áttekintés</title>
- <para>No matter what disks you have, there are always potential
- problems:</para>
+ <para>Nem számít, milyen lemezeink is vannak, ugyanis
+ mindig adódnak velük kapcsolatban gondjaink:</para>
<itemizedlist>
<listitem>
- <para>They can be too small.</para>
+ <para>Kicsik.</para>
</listitem>
<listitem>
- <para>They can be too slow.</para>
+ <para>Lassúk.</para>
</listitem>
<listitem>
- <para>They can be too unreliable.</para>
+ <para>Nem elég megbízhatóak.</para>
</listitem>
</itemizedlist>
- <para>Various solutions to these problems have been proposed and
- implemented. One way some users safeguard themselves against such
- issues is through the use of multiple, and sometimes redundant,
- disks. In addition to supporting various cards and controllers
- for hardware RAID systems, the base FreeBSD system includes the
- Vinum Volume Manager, a block device driver that implements
- virtual disk drives. <emphasis>Vinum</emphasis> is a
- so-called <emphasis>Volume Manager</emphasis>, a virtual disk
- driver that addresses these three problems. Vinum provides more
- flexibility, performance, and reliability than traditional disk
- storage, and implements RAID-0, RAID-1, and RAID-5 models both
- individually and in combination.</para>
+ <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 képezni. A tehát
+ <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>This chapter provides an overview of potential problems with
- traditional disk storage, and an introduction to the Vinum Volume
- Manager.</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>
<note>
- <para>Starting with FreeBSD 5, Vinum has been rewritten in order
- to fit into the GEOM architecture (<xref linkend="GEOM">),
- retaining the original ideas, terminology, and on-disk
- metadata. This rewrite is called <emphasis>gvinum</emphasis>
- (for <emphasis> GEOM vinum</emphasis>). The following text
- usually refers to <emphasis>Vinum</emphasis> as an abstract
- name, regardless of the implementation variant. Any command
- invocations should now be done using
- the <command>gvinum</command> command, and the name of the
- kernel module has been changed
- from <filename>vinum.ko</filename>
- to <filename>geom_vinum.ko</filename>, and all device nodes
- reside under <filename>/dev/gvinum</filename> instead
- of <filename>/dev/vinum</filename>. As of FreeBSD 6, the old
- Vinum implementation is no longer available in the code
- base.</para>
+ <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>/dev/vinum</filename> könyvtár helyett a
+ <filename>/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>Disks Are Too Small</title>
+ <title>Kicsik a lemezeink</title>
<indexterm><primary>Vinum</primary></indexterm>
- <indexterm><primary>RAID</primary>
- <secondary>software</secondary></indexterm>
+ <indexterm>
+ <primary>RAID</primary>
+ <secondary>szoftver</secondary>
+ </indexterm>
- <para>Disks are getting bigger, but so are data storage
- requirements. Often you will find you want a file system that
- is bigger than the disks you have available. Admittedly, this
- problem is not as acute as it was ten years ago, but it still
- exists. Some systems have solved this by creating an abstract
- device which stores its data on a number of disks.</para>
+ <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
+ 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
+ tárolja el.</para>
</sect1>
<sect1 id="vinum-access-bottlenecks">
- <title>Access Bottlenecks</title>
+ <title>Szûk keresztmetszetek a
+ lemezhozzáférésben</title>
- <para>Modern systems frequently need to access data in a highly
- concurrent manner. For example, large FTP or HTTP servers can
- maintain thousands of concurrent sessions and have multiple
- 100 Mbit/s connections to the outside world, well beyond
- the sustained transfer rate of most disks.</para>
+ <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 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
+ legtöbb lemez átlagos átviteli
+ sebességét.</para>
- <para>Current disk drives can transfer data sequentially at up to
- 70 MB/s, but this value is of little importance in an
- environment where many independent processes access a drive,
- where they may achieve only a fraction of these values. In such
- cases it is more interesting to view the problem from the
- viewpoint of the disk subsystem: the important parameter is the
- load that a transfer places on the subsystem, in other words the
- time for which a transfer occupies the drives involved in the
- transfer.</para>
+ <para>A jelenleg kapható lemezek soros adatátviteli
+ sebessége egészen 70 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>In any disk transfer, the drive must first position the
- heads, wait for the first sector to pass under the read head,
- and then perform the transfer. These actions can be considered
- to be atomic: it does not make any sense to interrupt
- them.</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
+ í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>
- <para><anchor id="vinum-latency"> Consider a typical transfer of
- about 10 kB: the current generation of high-performance
- disks can position the heads in an average of 3.5 ms. The
- fastest drives spin at 15,000 rpm, so the average
- rotational latency (half a revolution) is 2 ms. At
- 70 MB/s, the transfer itself takes about 150 μs,
- almost nothing compared to the positioning time. In such a
- case, the effective transfer rate drops to a little over
- 1 MB/s and is clearly highly dependent on the transfer
- size.</para>
+ <para><anchor id="vinum-latency">Tekintsünk egy
+ átlagosnak mondható, nagyjából
+ 10 kB méretû adatátvitelt: a
+ legújabb nagyteljesítményû lemezek
+ átlagosan 3,5 ms alatt képesek
+ pozicionálni a fejeket. A leggyorsabb lemezek
+ 15 000 fordulatot tesznek meg percenként (RPM),
+ így az átlagos forgási
+ késleltetés (egy fél fordulat ideje)
+ 2 ms. 70 MB/s-os sebesség mellett az
+ átvitel maga megközelítõleg
+ 150 μs, ami szinte elhanyagolható a
+ pozicionálás idejéhez képest. Ilyen
+ esetekben a tényleges adatátviteli sebesség
+ 1 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>The traditional and obvious solution to this bottleneck is
- <quote>more spindles</quote>: rather than using one large disk,
- it uses several smaller disks with the same aggregate storage
- space. Each disk is capable of positioning and transferring
- independently, so the effective throughput increases by a factor
- close to the number of disks used.
- </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>The exact throughput improvement is, of course, smaller than
- the number of disks involved: although each drive is capable of
- transferring in parallel, there is no way to ensure that the
- requests are evenly distributed across the drives. Inevitably
- the load on one drive will be higher than on another.</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>disk concatenation</primary>
+ <primary>lemezek összefûzése</primary>
</indexterm>
<indexterm>
<primary>Vinum</primary>
- <secondary>concatenation</secondary>
+ <secondary>összefûzés</secondary>
</indexterm>
- <para>The evenness of the load on the disks is strongly dependent
- on the way the data is shared across the drives. In the
- following discussion, it is convenient to think of the disk
- storage as a large number of data sectors which are addressable
- by number, rather like the pages in a book. The most obvious
- method is to divide the virtual disk into groups of consecutive
- sectors the size of the individual physical disks and store them
- in this manner, rather like taking a large book and tearing it
- into smaller sections. This method is called
- <emphasis>concatenation</emphasis> and has the advantage that
- the disks are not required to have any specific size
- relationships. It works well when the access to the virtual
- disk is spread evenly about its address space. When access is
- concentrated on a smaller area, the improvement is less marked.
- <xref linkend="vinum-concat"> illustrates the sequence in which
- storage units are allocated in a concatenated
- organization.</para>
+ <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õ
+ 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>Concatenated Organization</title>
+ <title>Az összefûzött szervezési
+ mód</title>
<graphic fileref="vinum/vinum-concat">
</figure>
</para>
- <indexterm>
- <primary>disk striping</primary>
- </indexterm>
- <indexterm>
- <primary>Vinum</primary>
- <secondary>striping</secondary>
- </indexterm>
- <indexterm>
- <primary>RAID</primary>
- </indexterm>
+ <indexterm>
+ <primary>lemezcsíkozás</primary>
+ </indexterm>
+ <indexterm>
+ <primary>Vinum</primary>
+ <secondary>csíkozás</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>RAID</primary>
+ </indexterm>
- <para>An alternative mapping is to divide the address space into
- smaller, equal-sized components and store them sequentially on
- different devices. For example, the first 256 sectors may be
- stored on the first disk, the next 256 sectors on the next disk
- and so on. After filling the last disk, the process repeats
- until the disks are full. This mapping is called
- <emphasis>striping</emphasis> or <acronym>RAID-0</acronym>
+ <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 vagy
+ <acronym>RAID-0</acronym>-nak nevezzük.
- <footnote>
- <para><acronym>RAID</acronym> stands for <emphasis>Redundant
- Array of Inexpensive Disks</emphasis> and offers various forms
- of fault tolerance, though the latter term is somewhat
- misleading: it provides no redundancy.</para> </footnote>.
+ <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>
- Striping requires somewhat more effort to locate the data, and it
- can cause additional I/O load where a transfer is spread over
- multiple disks, but it can also provide a more constant load
- across the disks. <xref linkend="vinum-striped"> illustrates the
- sequence in which storage units are allocated in a striped
- organization.</para>
+ 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>Striped Organization</title>
+ <title>A csíkozott szervezési mód</title>
<graphic fileref="vinum/vinum-striped">
</figure>
</para>
</sect1>
<sect1 id="vinum-data-integrity">
- <title>Data Integrity</title>
+ <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 rettenetesen 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
+ 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>, 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>
- <para>The final problem with current disks is that they are
- unreliable. Although disk drive reliability has increased
- tremendously over the last few years, they are still the most
- likely core component of a server to fail. When they do, the
- results can be catastrophic: replacing a failed disk drive and
- restoring data to it can take days.</para>
+ <itemizedlist>
+ <listitem>
+ <para>Ár. Legalább kétszer annyiba
+ kerül, mint a nem redundánsan tároló
+ megoldások.</para>
+ </listitem>
- <indexterm>
- <primary>disk mirroring</primary>
- </indexterm>
- <indexterm>
- <primary>Vinum</primary>
- <secondary>mirroring</secondary>
- </indexterm>
- <indexterm>
- <primary>RAID-1</primary>
- </indexterm>
-
- <para>The traditional way to approach this problem has been
- <emphasis>mirroring</emphasis>, keeping two copies of the data
- on different physical hardware. Since the advent of the
- <acronym>RAID</acronym> levels, this technique has also been
- called <acronym>RAID level 1</acronym> or
- <acronym>RAID-1</acronym>. Any write to the volume writes to
- both locations; a read can be satisfied from either, so if one
- drive fails, the data is still available on the other
- drive.</para>
-
- <para>Mirroring has two problems:</para>
-
- <itemizedlist>
- <listitem>
- <para>The price. It requires twice as much disk storage as
- a non-redundant solution.</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>
- <listitem>
- <para>The performance impact. Writes must be performed to
- both drives, so they take up twice the bandwidth of a
- non-mirrored volume. Reads do not suffer from a
- performance penalty: it even looks as if they are
- faster.</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><indexterm><primary>RAID-5</primary></indexterm>An
- alternative solution is <emphasis>parity</emphasis>,
- implemented in the <acronym>RAID</acronym> levels 2, 3, 4 and
- 5. Of these, <acronym>RAID-5</acronym> is the most
- interesting. As implemented in Vinum, it is a variant on a
- striped organization which dedicates one block of each stripe
- to parity of the other blocks. As implemented by Vinum, a
- <acronym>RAID-5</acronym> plex is similar to a striped plex,
- except that it implements <acronym>RAID-5</acronym> by
- including a parity block in each stripe. As required by
- <acronym>RAID-5</acronym>, the location of this parity block
- changes from one stripe to the next. The numbers in the data
- blocks indicate the relative block numbers.</para>
+ <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>RAID-5 Organization</title>
- <graphic fileref="vinum/vinum-raid5-org">
- </figure>
- </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>Compared to mirroring, <acronym>RAID-5</acronym> has the
- advantage of requiring significantly less storage space. Read
- access is similar to that of striped organizations, but write
- access is significantly slower, approximately 25% of the read
- performance. If one drive fails, the array can continue to
- operate in degraded mode: a read from one of the remaining
- accessible drives continues normally, but a read from the
- failed drive is recalculated from the corresponding block from
- all the remaining drives.
- </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
+ 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>Vinum Objects</title>
- <para>In order to address these problems, Vinum implements a four-level
- hierarchy of objects:</para>
+ <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>
- <itemizedlist>
- <listitem>
- <para>The most visible object is the virtual disk, called a
- <emphasis>volume</emphasis>. Volumes have essentially the same
- properties as a &unix; disk drive, though there are some minor
- differences. They have no size limitations.</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>Volumes are composed of <emphasis>plexes</emphasis>,
- each of which represent the total address space of a
- volume. This level in the hierarchy thus provides
- redundancy. Think of plexes as individual disks in a
- mirrored array, each containing the same data.</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>Since Vinum exists within the &unix; disk storage
- framework, it would be possible to use &unix;
- partitions as the building block for multi-disk plexes,
- but in fact this turns out to be too inflexible:
- &unix; disks can have only a limited number of
- partitions. Instead, Vinum subdivides a single
- &unix; partition (the <emphasis>drive</emphasis>)
- into contiguous areas called
- <emphasis>subdisks</emphasis>, which it uses as building
- blocks for plexes.</para>
- </listitem>
-
- <listitem>
- <para>Subdisks reside on Vinum <emphasis>drives</emphasis>,
- currently &unix; partitions. Vinum drives can
- contain any number of subdisks. With the exception of a
- small area at the beginning of the drive, which is used
- for storing configuration and state information, the
- entire drive is available for data storage.</para>
- </listitem>
- </itemizedlist>
+ <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>The following sections describe the way these objects provide the
- functionality required of Vinum.</para>
+ <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>Volume Size Considerations</title>
+ <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
+ méretét, emiatt a kötetét sem.</para>
+ </sect2>
- <para>Plexes can include multiple subdisks spread over all
- drives in the Vinum configuration. As a result, the size of
- an individual drive does not limit the size of a plex, and
- thus of a volume.</para>
- </sect2>
-
<sect2>
- <title>Redundant Data Storage</title>
- <para>Vinum implements mirroring by attaching multiple plexes to
- a volume. Each plex is a representation of the data in a
- volume. A volume may contain between one and eight
- plexes.</para>
+ <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>Although a plex represents the complete data of a volume,
- it is possible for parts of the representation to be
- physically missing, either by design (by not defining a
- subdisk for parts of the plex) or by accident (as a result of
- the failure of a drive). As long as at least one plex can
- provide the data for the complete address range of the volume,
- the volume is fully functional.</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ó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>
</sect2>
-
+
<sect2>
- <title>Performance Issues</title>
+ <title>Teljesítmény</title>
- <para>Vinum implements both concatenation and striping at the
- plex level:</para>
+ <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>A <emphasis>concatenated plex</emphasis> uses the
- address space of each subdisk in turn.</para>
+ <para>Az <emphasis>összefûzött
+ ér</emphasis> allemezek területeibõl
+ építkezik.</para>
</listitem>
<listitem>
- <para>A <emphasis>striped plex</emphasis> stripes the data
- across each subdisk. The subdisks must all have the same
- size, and there must be at least two subdisks in order to
- distinguish it from a concatenated plex.</para>
+ <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>Which Plex Organization?</title>
- <para>The version of Vinum supplied with FreeBSD &rel.current; implements
- two kinds of plex:</para>
-
+ <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>Concatenated plexes are the most flexible: they can
- contain any number of subdisks, and the subdisks may be of
- different length. The plex may be extended by adding
- additional subdisks. They require less
- <acronym>CPU</acronym> time than striped plexes, though
- the difference in <acronym>CPU</acronym> overhead is not
- measurable. On the other hand, they are most susceptible
- to hot spots, where one disk is very active and others are
- idle.</para>
- </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>The greatest advantage of striped
- (<acronym>RAID-0</acronym>) plexes is that they reduce hot
- spots: by choosing an optimum sized stripe (about
- 256 kB), you can even out the load on the component
- drives. The disadvantages of this approach are
- (fractionally) more complex code and restrictions on
- subdisks: they must be all the same size, and extending a
- plex by adding new subdisks is so complicated that Vinum
- currently does not implement it. Vinum imposes an
- additional, trivial restriction: a striped plex must have
- at least two subdisks, since otherwise it is
- indistinguishable from a concatenated plex.</para>
+ <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 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 felül 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><xref linkend="vinum-comparison"> summarizes the advantages
- and disadvantages of each plex organization.</para>
-
+
+ <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 Plex Organizations</title>
+ <title>Vinum erezések</title>
<tgroup cols="5">
<thead>
<row>
- <entry>Plex type</entry>
- <entry>Minimum subdisks</entry>
- <entry>Can add subdisks</entry>
- <entry>Must be equal size</entry>
- <entry>Application</entry>
+ <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>concatenated</entry>
+ <entry>összefûzött</entry>
<entry>1</entry>
- <entry>yes</entry>
- <entry>no</entry>
- <entry>Large data storage with maximum placement flexibility
- and moderate performance</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>striped</entry>
+ <entry>csíkozott</entry>
<entry>2</entry>
- <entry>no</entry>
- <entry>yes</entry>
- <entry>High performance in combination with highly concurrent
- access</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>Some Examples</title>
+ <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
>>> TRUNCATED FOR MAIL (1000 lines) <<<
More information about the p4-projects
mailing list