From owner-p4-projects@FreeBSD.ORG Mon Nov 5 22:58:10 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 32E5C16A41A; Mon, 5 Nov 2007 22:58:10 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5AF016A419 for ; Mon, 5 Nov 2007 22:58:09 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 9A59913C4B6 for ; Mon, 5 Nov 2007 22:58:09 +0000 (UTC) (envelope-from pgj@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id lA5Mw9pK037436 for ; Mon, 5 Nov 2007 22:58:09 GMT (envelope-from pgj@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.1/8.14.1/Submit) id lA5Mw9Rx037433 for perforce@freebsd.org; Mon, 5 Nov 2007 22:58:09 GMT (envelope-from pgj@FreeBSD.org) Date: Mon, 5 Nov 2007 22:58:09 GMT Message-Id: <200711052258.lA5Mw9Rx037433@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to pgj@FreeBSD.org using -f From: Gabor Pali To: Perforce Change Reviews Cc: Subject: PERFORCE change 128708 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 22:58:10 -0000 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 @@ + - + Greg Lehey - Originally written by + Eredetileg írta: - The Vinum Volume Manager + A Vinum kötetkezelõ - Synopsis + Áttekintés - No matter what disks you have, there are always potential - problems: + Nem számít, milyen lemezeink is vannak, ugyanis + mindig adódnak velük kapcsolatban gondjaink: - They can be too small. + Kicsik. - They can be too slow. + Lassúk. - They can be too unreliable. + Nem elég megbízhatóak. - 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. Vinum is a - so-called Volume Manager, 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. + 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 + Vinum egy olyan ún. + kötetkezelõ, 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. - This chapter provides an overview of potential problems with - traditional disk storage, and an introduction to the Vinum Volume - Manager. + Ebben a fejezetben összefoglaljuk a hagyományos + lemezes tárolás jellegzetes + hátulütõit és bemutatjuk a Vinum + kötetkezelõt. - Starting with FreeBSD 5, Vinum has been rewritten in order - to fit into the GEOM architecture (), - retaining the original ideas, terminology, and on-disk - metadata. This rewrite is called gvinum - (for GEOM vinum). The following text - usually refers to Vinum as an abstract - name, regardless of the implementation variant. Any command - invocations should now be done using - the gvinum command, and the name of the - kernel module has been changed - from vinum.ko - to geom_vinum.ko, and all device nodes - reside under /dev/gvinum instead - of /dev/vinum. As of FreeBSD 6, the old - Vinum implementation is no longer available in the code - base. + A &os; 5-ös verziójától kezdve a + Vinumot újraírták a GEOM-nak megfelelõen + (), megtartva az eredeti + elgondolásokat, elnevezéseket és a lemezen + tárolt metaadatok formátumát. Ezt az + újraírt változatot nevezik + gvinumnak (GEOM + vinum). A szövegben a + Vinumra kizárólag csak + általánosságban hivatkozunk, + függetlenül az + implementációjától. Most már + az összes parancsot a gvinum + használatával kell kiadni, illetve a + hozzátartozó modul neve + vinum.ko-ról + geom_vinum.ko-ra változott és + a megfelelõ eszközleírók a + /dev/vinum könyvtár helyett a + /dev/gvinum 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. - - Disks Are Too Small + Kicsik a lemezeink Vinum - RAID - software + + RAID + szoftver + - 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. + 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. - Access Bottlenecks + Szûk keresztmetszetek a + lemezhozzáférésben - 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. + 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. - 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. + 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. - 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. + 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. - 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. + 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. - The traditional and obvious solution to this bottleneck is - more spindles: 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. - + A hagyományos és kézenfekvõ + megoldása ennek a problémának még + több cséve 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. - 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. + 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. - disk concatenation + lemezek összefûzése Vinum - concatenation + összefûzés - 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 - concatenation 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. - illustrates the sequence in which - storage units are allocated in a concatenated - organization. + 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 összefûzésnek, + é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 mutatja be + lemezek egy ilyen összefûzött + konfigurációját.
- Concatenated Organization + Az összefûzött szervezési + mód
- - disk striping - - - Vinum - striping - - - RAID - + + lemezcsíkozás + + + Vinum + csíkozás + + + RAID + - 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 - striping or RAID-0 + 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 + csíkozásnak vagy + RAID-0-nak nevezzük. - - RAID stands for Redundant - Array of Inexpensive Disks and offers various forms - of fault tolerance, though the latter term is somewhat - misleading: it provides no redundancy. . + + A RAID 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. + - 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. illustrates the - sequence in which storage units are allocated in a striped - organization. + 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 + mutatja be a lemezek csíkozott + szervezését.
- Striped Organization + A csíkozott szervezési mód
- Data Integrity + Adatintegritás + + 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. + + + lemeztükrözés + + + Vinum + tükrözés + + + RAID-1 + + + Ennek a problémának a hagyományos + megközelítése lenne a + tükrözés, vagyis amikor + ugyanarról az adatról tartunk két + példányt két eltérõ fizikai + hardveren. A RAID-szintek + beköszöntével ezt a technikát + RAID level 1-nak vagy + RAID-1-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. + + A tükrözés két problémát + vet fel: - 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. + + + Ár. Legalább kétszer annyiba + kerül, mint a nem redundánsan tároló + megoldások. + - - disk mirroring - - - Vinum - mirroring - - - RAID-1 - - - The traditional way to approach this problem has been - mirroring, keeping two copies of the data - on different physical hardware. Since the advent of the - RAID levels, this technique has also been - called RAID level 1 or - RAID-1. 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. - - Mirroring has two problems: - - - - The price. It requires twice as much disk storage as - a non-redundant solution. - + + 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. + + - - 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. - - + + lemezparitás + + + Vinum + paritás + + + RAID-5 + - RAID-5An - alternative solution is parity, - implemented in the RAID levels 2, 3, 4 and - 5. Of these, RAID-5 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 - RAID-5 plex is similar to a striped plex, - except that it implements RAID-5 by - including a parity block in each stripe. As required by - RAID-5, the location of this parity block - changes from one stripe to the next. The numbers in the data - blocks indicate the relative block numbers. + Az adatintegritás megõrzésére egy + másik megoldás a paritás + használata, melyet a 2, 3, 4 és 5 + RAID-szintek valósítanak meg. + Ezek közül talán a RAID-5 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 + RAID-5 által megvalósított + szervezés hasonlít a csíkozáshoz, + azonban a RAID-5-ben mindegyik csík + tartalmaz egy paritási információt is. + Tehát a Vinumban, ahogy azt RAID-5 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. - -
- RAID-5 Organization - -
- + +
+ A RAID-5 szervezési mód + +
+ - Compared to mirroring, RAID-5 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. - + A RAID-5-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. - Vinum Objects - In order to address these problems, Vinum implements a four-level - hierarchy of objects: + A Vinum objektumai + + A tárgyalt problémák + orvoslására a Vinumban egy négyszintû + objektumhierarchiát alakítottak ki: + + + + A legjobban észlelhetõ objektum a + virtuális lemez, amelyet + kötetnek (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. + - - - The most visible object is the virtual disk, called a - volume. Volumes have essentially the same - properties as a &unix; disk drive, though there are some minor - differences. They have no size limitations. - + + A kötetek erekbõ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. + - - Volumes are composed of plexes, - 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. - + + 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 + allemeznek (subdisk) nevezett folytonos + területekre osztja fel az egyes &unix;-os + partíciókat (a + meghajtókat), melyeket + aztán az erek létrehozására + használ fel. + - - 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 drive) - into contiguous areas called - subdisks, which it uses as building - blocks for plexes. - - - - Subdisks reside on Vinum drives, - 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. - - + + A Vinum által létrehozott + meghajtó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. + + - The following sections describe the way these objects provide the - functionality required of Vinum. + 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. - Volume Size Considerations + A kötetek mérete + 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. + - 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. - - - Redundant Data Storage - 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. + Redundáns adattárolás + + 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. - 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. + 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õ. - + - Performance Issues + Teljesítmény - Vinum implements both concatenation and striping at the - plex level: + A Vinum az összefûzést és a + csíkozást is egyaránt + megvalósítja az erek szintjén: - A concatenated plex uses the - address space of each subdisk in turn. + Az összefûzött + ér allemezek területeibõl + építkezik. - A striped plex 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. + A csíkozott ér + 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. - Which Plex Organization? - The version of Vinum supplied with FreeBSD &rel.current; implements - two kinds of plex: - + Hogyan szervezzük az ereket? + A &os; &rel.current; verziójában két + fajta erezési megoldást találhatunk: + - 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 - CPU time than striped plexes, though - the difference in CPU 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. - + 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. + - The greatest advantage of striped - (RAID-0) 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. + A csíkozott (RAID-0) 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. - - summarizes the advantages - and disadvantages of each plex organization. - + + A foglalja össze az + egyes erezések elõnyeit és + hátrányait. + - Vinum Plex Organizations + Vinum erezések - Plex type - Minimum subdisks - Can add subdisks - Must be equal size - Application + Erezés típusa + Legkevesebb allemez + Bõvíthetõ + Megegyezõ méret + Alkalmazás - concatenated + összefûzött 1 - yes - no - Large data storage with maximum placement flexibility - and moderate performance + igen + nem + Sok adat tárolása, ahol a + hangsúly a rugalmasságon és a + mérsékelt teljesítményen + van. - + - striped + csíkozott 2 - no - yes - High performance in combination with highly concurrent - access + nem + igen + Nagy teljesítmény, nagy + mennyiségû egyidejû + hozzáférés mellett
- + - Some Examples + Példák + + A Vinum a rendszerben ismert objektumokkal kapcsolatos + információkat egy + konfigurációs + adatbázisban 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 + eszköznek hív). Az >>> TRUNCATED FOR MAIL (1000 lines) <<<