Date: Mon, 5 Nov 2007 22:58:09 GMT From: Gabor Pali <pgj@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 128708 for review Message-ID: <200711052258.lA5Mw9Rx037433@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=128708 Change 128708 by pgj@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@FreeBSD.org> - and Tom Rhodes <trhodes@FreeBSD.org> + Added to the Handbook by Hiten Pandya <hmp@FreeBSD.org> + and Tom Rhodes <trhodes@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@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) <<<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711052258.lA5Mw9Rx037433>