diff --git a/hu_HU.ISO8859-2/articles/linux-users/article.sgml b/hu_HU.ISO8859-2/articles/linux-users/article.sgml index 094d45b008..cb7e595847 100644 --- a/hu_HU.ISO8859-2/articles/linux-users/article.sgml +++ b/hu_HU.ISO8859-2/articles/linux-users/article.sgml @@ -1,843 +1,843 @@ %articles.ent; ]>
&os; gyorstalpaló &linux; felhasználók számára John Ferrell 2008 A FreeBSD Dokumentációs Projekt $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.linux; &tm-attrib.intel; &tm-attrib.redhat; &tm-attrib.unix; &tm-attrib.general; Ez a cikk azért íródott, hogy röviden megismertesse a &os; alapjait a középhaladó-haladó &linux; felhasználókkal. Fordította: &a.hu.pgj; Bevezetés Ebben a leírásban a &os; és a &linux; közti alapvetõ eltéréseket igyekszünk szemléltetni, aminek révén a középhaladó és haladó &linux; felhasználók pillanatok alatt bepillantást nyerhetnek a &os; alapjaiba. Ez egyszerûen csak egy szakmai jellegû bevezetés, és nem foglalkozik a két rendszer felépítése közti filozófiai különbségekkel. A leírás feltételezi, hogy korábban már telepítettük a &os; rendszert. Amennyiben ezt még nem tettük volna meg, vagy segítségre lenne szükségünk a telepítésben, akkor olvassuk el a &os; kézikönyv A &os; telepítése címû fejezetét. Parancsértelmezõk: hova tûnt a Bash? A Linuxról áttérõ felhasználók gyakran meglepõdnek azon, hogy a &os;-ben nem a Bash az alapértelmezett parancsértelmezõ. Sõt, a Bash még az alaprendszerben sem található meg. Helyette a &man.tcsh.1; az alapértelmezett parancsértelmezõ a &os;-ben. Természetesen a Bash, a többi szintén közkedvelt parancsértelmezõhöz hasonlóan megtalálható a &os; Csomag- és Portgyûjteményében. Ha más parancsértelmezõket is telepítettünk, akkor a &man.chsh.1; parancs segítségével tudjuk megváltoztatni az alapértelmezett parancsértelmezõnket. A root felhasználó alapértelmezett parancsértelmezõjének megváltoztatását azonban nem javasoljuk. Ennek oka, hogy azok a parancsértelmezõk, amelyek nem részei az alaprendszernek, általában a /usr/local/bin vagy a /usr/bin könyvtárakban találhatóak, és bizonyos vészhelyzetekben elõfordulhat, hogy az ezeket az állományrendszereket nem tudjuk csatlakoztatni. Ilyen esetekben a root sem lesz képes elérni a saját alapértelmezett parancsértelmezõjét, amivel lényegében megakadályozzuk, hogy be tudjon jelentkezni. Erre a célra a root felhasználó egy alternatíváját, a toor felhasználót hozták létre, amelyet az alaprendszeren kívül található parancsértelmezõkkel is használhatunk. A toor hozzáférésérõl a GYIK biztonsági kérdésekkel foglalkozó részében tudhatunk meg többet (angolul). Csomagok és portok: szoftverek telepítése &os; alatt A szoftverek telepítésének hagyományos &unix;-os megoldásain (a forrás letöltésén, kitömörítésén, a forráskód módosításán és lefordításán) túl az alkalmazások telepítésének további két módját is felkínálja a &os;: ezek a csomagok és a portok. A rendszerhez elérhetõ összes port és csomag teljes listáját ezen a címen érhetjük el. Csomagok A csomagok lényegében elõre lefordított alkalmazások, amelyek megfelelnek a Debian/Ubuntu rendszerekben megtalálható .deb, vagy a Red Hat/Fedora rendszerekben megtalálható .rpm állományoknak. A csomagok a &man.pkg.add.1; segítségével telepíthetõek. Például az alábbi parancs az Apache 2.2 alkalmazást rakja fel: &prompt.root; pkg_add /tmp/apache-2.2.6_2.tbz Az kapcsolóval arra utasítjuk a &man.pkg.add.1; programot, hogy magától töltse le és telepítse a csomagot, valamint annak függõségeit: &prompt.root; pkg_add -r apache22 Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/apache22.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/expat-2.0.0_1.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/perl-5.8.8_1.tbz... Done. [nyissz] To run apache www server from startup, add apache22_enable="YES" in your /etc/rc.conf. Extra options can be found in startup script. Ha a &os; valamelyik kiadását használjuk (6.2, 6.3, 7.0 stb., tehát CD-rõl telepítettük), akkor a pkg_add -r az adott kiadáshoz tartozó csomagokat fogja letölteni. Ezek a csomagok azonban nem feltétlenül az alkalmazás legújabb verziójához tartoznak. Ezt az alapértelmezett viselkedést felül tudjuk bírálni, ha a PACKAGESITE környezeti változót a értékre állítjuk, és így például a 6.X sorozathoz készült legfrissebb csomagokat tölthetjük le. A &os; különbözõ változatairól a Válasszuk ki a nekünk igazán megfelelõ &os; verziót! címû cikkben olvashatunk bõvebben. A csomagok használatával kapcsolatban a &os; kézikönyvében kaphatunk részletesebb felvilágosítást, lásd A csomagrendszer használata. Portok A &os;-ben az alkalmazások telepítésének másik módja a Portgyûjtemény használata. A Portgyûjtemény lényegében Makefile állományok és javítások gyûjteménye, amelyek a különféle alkalmazások forráskódját készítik fel arra, hogy a &os;-n is használhatóak legyenek. Amikor telepítünk egy portot, akkor a rendszer elõször letölti az alkalmazás forráskódját, elvégzi a szükséges módosításokat, lefordítja a forrást és végül telepíti az alkalmazást (valamint mindezt megteszi az összes függõsége esetében). A Portgyûjtemény, vagy gyakran egyszerûen csak a portfa, a /usr/ports könyvtárban található. Itt nyilván feltételezzük, hogy a Portgyûjteményt is kiválasztottuk a &os; telepítése során. Amennyiben a Portgyûjteményt még nem telepítettük volna, a &man.sysinstall.8; segítségével feltehetjük a telepítõlemezrõl, vagy esetleg a &man.csup.1;, illetve &man.portsnap.8; használatával letölthetjük a &os; Projekt valamelyik szerverérõl. A Portgyûjtemény telepítésének részletes bemutatása megtalálható a kézikönyv 4.5.1. szakaszában. A telepítéshez (általában) csak be kell lépnünk az adott port könyvtárába és el kell indítanunk a fordítást. A következõ példában az Apache 2.2 alkalmazást telepítjük a Portgyûjteménybõl: &prompt.root; cd /usr/ports/www/apache22 &prompt.root; make install clean A portok alkalmazásának egyik legnagyobb elõnye, hogy a szoftverek telepítése során testre tudjuk szabni azok beállításait. Például amikor az Apache 2.2 alkalmazást portként telepítjük, a WITH_LDAP &man.make.1; változó megadásával engedélyezhetjük a mod_ldap használatát: &prompt.root; cd /usr/ports/www/apache22 &prompt.root; make WITH_LDAP="YES" install clean A Portgyûjteménnyel kapcsolatos további információk tekintetében olvassuk el a &os; kézikönyv A Portgyûjtemény használata címû szakaszát. Portok vagy csomagok, mégis melyiket használjam? A csomagok tulajdonképpen elõre lefordított portok, ezért igazából csak abban van köztük különbség, hogy forrásból (portok) vagy binárisan telepítjük-e az alkalmazásokat. Mindegyik módszernek megvannak a maga elõnyei: Csomagok (bináris) Gyorsabb telepítés (a nagyobb alkalmazások lefordítása viszont nagyon sokáig is eltarthat). Nem szükséges megértenünk a szoftverek lefordításának mikéntjét. Nem kell fordítóprogramokat telepítenünk a rendszerünkre. Portok (forrás) A telepítés beállításait tetszõlegesen szabályozhatjuk. (A csomagok általában szabványos beállításokkal készülnek. A portok esetében azonban lehetõségünk van ezeket kedvünk szerint megváltoztatni, mint például további modulok fordítását kérni vagy átállítani a telepítés alapértelmezett helyét.) Ha késztetést érzünk, akkor akár a saját javításainkat is beletehetjük a forráskódba. Ha nincsenek különös igényeink, akkor a csomagok minden bizonnyal tökéletesen megfelelnek számunkra. Amikor viszont valamit külön be szeretnénk állítani, akkor ahhoz a portokat érdemes választanunk. (Ne felejtsük el azonban, hogy ha elsõsorban a csomagokhoz ragaszkodunk, de mégis módosítanunk kell valamit bennük, akkor a make package parancs kiadásával a portokból is tudunk csomagot készíteni, majd átmásolni azokat más szerverekre.) A rendszer indítása: hova lettek a futási szintek? A &linux; a SysV rendszerindítási sémáját alkalmazza, miközben a &os; a hagyományos BSD típusú &man.init.8; megoldást. A BSD típusú &man.init.8; esetén nincsenek futási szintek és nem létezik /etc/inittab állomány. Helyette az &man.rc.8; vezérli a rendszer indítását. Az /etc/rc szkript beolvassa az /etc/defaults/rc.conf és /etc/rc.conf állományokat, amibõl megállapítja, hogy milyen szolgáltatásokat indítson el. A megadott szolgáltatásokat ezután az /etc/rc.d és a /usr/local/etc/rc.d könyvtárakban található megfelelõ indítószkriptek segítségével indítja el. Ezek a szkriptek hasonlóak a &linux; rendszereken az /etc/init.d könyvtárban található szkriptekhez. A szolgáltatások indításáért felelõs szkriptek miért két különbözõ helyen találhatóak? Az /etc/rc.d könyvtárban található szkriptek az alaprendszer részei (mint például a &man.cron.8;, &man.sshd.8;, &man.syslog.3; és a többi). A /usr/local/etc/rc.d könyvtárban pedig a felhasználó által telepíthetõ alkalmazások, például az Apache, Squid stb. szkriptjei találhatóak. Mi a különbség az alaprendszerben található és a felhasználó által telepített alkalmazások között? A &os;-t egy összefüggõ operációs rendszerként fejlesztik. Ezt másképpen úgy lehetne fogalmazni, hogy a rendszermagot, a rendszerszintû függvénykönyvtárakat és a hozzájuk tartozó programokat (mint például a &man.ls.1;, &man.cat.1;, &man.cp.1; stb.) együtt fejlesztik és adják ki. Ezt nevezzük az alaprendszernek. A felhasználó által telepíthetõ alkalmazások lényegében azok, amelyek nem részei ennek az alaprendszernek, például az Apache, X11, Mozilla Firefox stb. Ezek általában a &os; Csomag- és Portgyûjteményébõl telepíthetõek. Mivel a felhasználók által telepített alkalmazásokat igyekszünk elkülöníteni az alaprendszertõl, ezért ezek a /usr/local/ könyvtárba kerülnek. Ennek következtében a felhasználók által telepített binárisok a /usr/local/bin könyvtárban, míg a hozzájuk tartozó konfigurációs állományok a /usr/local/etc könyvtárban találhatóak, és így tovább. A szolgáltatásokat az /etc/rc.conf állományban (lásd &man.rc.conf.5;) tudjuk engedélyezni a SzolgáltatásNév_enable="YES" sor megadásával. A rendszer alapértelmezett beállításait az /etc/defaults/rc.conf állományban találhatjuk meg, amelyeket az /etc/rc.conf állományban tudjuk felülbírálni. Az alkalmazásokhoz tartozó szolgáltatások engedélyezésének lépéseihez pedig a telepítésük után ne felejtsük el átolvasni a hozzájuk tartozó dokumentációt. Az /etc/rc.conf állományból származó most következõ rövid kódrészlet az &man.sshd.8; és Apache 2.2 szolgáltatásokat engedélyezi, valamint az Apache számára beállítja az SSL használatát. # az SSHD engedélyezése sshd_enable="YES" # az Apache és benne az SSL támogatásának engedélyezése apache22_enable="YES" apache22_flags="-DSSL" Miután az /etc/rc.conf állományban engedélyeztük a szolgáltatásokat, a paranccsorból el is tudjuk indítani ezeket (a rendszer újraindítása nélkül): &prompt.root; /etc/rc.d/sshd start Ha egy szolgáltatást nem engedélyeztünk, akkor a parancssorból a paraméter megadásával tudjuk elindítani: &prompt.root; /etc/rc.d/sshd forcestart A hálózat beállítása Hálózati interfészek A hálózati csatolófelületekre a Linux esetén alkalmazott általános ethX alakú azonosítók helyett a &os; az adott hálózati kártya meghajtójának nevével és utána egy sorszámmal hivatkozik. Az &man.ifconfig.8; itt látható kimenetében két &intel; Pro 1000 hálózati kártya jelenik meg (em0 és em1): &prompt.user; ifconfig em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=b<RXCSUM,TXCSUM,VLAN_MTU> inet 10.10.10.100 netmask 0xffffff00 broadcast 10.10.10.255 ether 00:50:56:a7:70:b2 media: Ethernet autoselect (1000baseTX <full-duplex>) status: active em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=b<RXCSUM,TXCSUM,VLAN_MTU> inet 192.168.10.222 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:50:56:a7:03:2b media: Ethernet autoselect (1000baseTX <full-duplex>) status: active Az IP-cím beállítása Az interfészekhez az &man.ifconfig.8; paranccsal tudunk IP-címet rendelni. Az IP-címek beállítása azonban csak akkor marad meg az újraindítást követõen is, ha felvesszük az /etc/rc.conf állományba. A most következõ példában megadunk egy hálózati nevet, IP-címet és egy alapértelmezett átjárót: hostname="szerver1.minta.com" ifconfig_em0="inet 10.10.10.100 netmask 255.255.255.0" defaultrouter="10.10.10.1" DHCP esetén használjuk a következõt: hostname="szerver1.minta.com" ifconfig_em0="DHCP" Tûzfalak Hasonlóan a Linuxban található IPTABLES megoldáshoz, a &os; is kínál fel rendszermagszintû tûzfalazást. A &os; jelen pillanatban három tûzfalat támogat: IPFIREWALL IPFILTER PF Az IPFIREWALL avagy IPFW (az IPFW szabályrendszereit az &man.ipfw.8; paranccsal tudjuk kezelni) a &os; fejlesztõi által készített és karbantartott tûzfal. A forgalomszabályozás megvalósításához és különbözõ típusú hálózati kapcsolatok szimulációjához az IPFW kiegészíthetõ a &man.dummynet.4; használatával. Ez az IPFW szabály engedélyezi a beérkezõ SSH-kapcsolatokat: ipfw add allow tcp from any to me 22 in via $ext_if Az IPFILTER tûzfalat Darren Reed dolgozta ki. Nem csak &os; alatt találkozhatunk vele, több operációs rendszerre is portolták, többek közt NetBSD-re, OpenBSD-re, SunOS-re, HP/UX-ra és Solarisra. Ez az IPFILTER parancs engedélyezi a beérkezõ SSH-kapcsolatokat: pass in on $ext_if proto tcp from any to any port = 22 Az utolsó tûzfal, a PF, az OpenBSD Projekt fejlesztése. Az PF eredetileg az IPFILTER leváltására készült. Emiatt az PF szabályainak megadási módja nagyon hasonlít az IPFILTER esetében megismertekhez. A minõségalapú (QoS) forgalomszabályozás létrehozásához a PF az &man.altq.4; megoldásával egészíthetõ ki. Ez a PF parancs engedélyezi a beérkezõ SSH-kapcsolatokat: pass in on $ext_if inet proto tcp from any to ($ext_if) port 22 A &os; frissítése A &os; rendszer háromféleképpen frissíthetõ: forráskódból, binárisan és telepítõlemezek használatával. A forráskódon keresztüli frissítés ugyan a legbonyolultabb ezek közül, azonban ez kínálja fel egyben a legnagyobb rugalmasságot is. Ennek során szinkronizálnunk kell a &os; forráskódjának nálunk levõ (helyi) másolatát a &os; CVS (Concurrent Versioning System) szervereivel. Miután ezt megtörtént, le tudjuk fordítani a rendszermagot és a hozzátartozó programokat. A források frissítésével kapcsolatban olvassuk el &os; kézikönyv frissítésrõl szóló fejezetét. A bináris frissítés a &linux; típusú rendszereken elérhetõ yum vagy apt-get parancsok esetén megszokottakhoz hasonló. A &man.freebsd-update.8; parancs letölti a frissítéseket és telepíti ezeket. Ez a frissítési folyamat a &man.cron.8; használatával ütemezhetõ. Amikor a &man.cron.8; segítségével ütemezzük a frissítéseket, a &man.crontab.1; állományban lehetõség szerint a freebsd-update cron parancsot használjuk, ezáltal igyekezzünk csökkenteni annak valószínûségét, hogy egyszerre több számítógép is ugyanakkor terhelje a szervert. 0 3 * * * root /usr/sbin/freebsd-update cron Az utolsó frissítési módszer, a telepítõlemezek használata lényegében egy egyértelmû folyamat. Indítsuk el számítógépünket a telepítõlemezrõl és a telepítõben válasszuk a frissítés (upgrade) opciót. procfs: eltûnt, de nem nyomtalanul A &linux; alatt a /proc/sys/net/ipv4/ip_forward használatával tudjuk megmondani, hogy az IP-csomagok továbbítása engedélyezett-e rendszerünkben. Mivel a &man.procfs.5; a &os; jelenlegi verzióiban már elavultnak számít, ezért ezt a &man.sysctl.8; paranccsal nézhetjük meg a rendszer egyéb beállításai mellett. (A sysctl viszont &linux; alatt is egyaránt megtalálható.) Ha az IP-csomagok továbbításáról szóló példánál maradunk, akkor ezt az alábbi módon kérdezhetjük le, hogy engedélyezett-e a &os; rendszerünkön: &prompt.user; sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0 Az paraméter megadásával a rendszer összes jelenlegi beállítását le tudjuk kérdezni: &prompt.user; sysctl -a kern.ostype: FreeBSD kern.osrelease: 6.2-RELEASE-p9 kern.osrevision: 199506 kern.version: FreeBSD 6.2-RELEASE-p9 #0: Thu Nov 29 04:07:33 UTC 2007 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC kern.maxvnodes: 17517 kern.maxproc: 1988 kern.maxfiles: 3976 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: server1 kern.hostid: 0 kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } kern.posix1version: 200112 ... Bizonyos sysctl-értékek írásvédettek. Adódhatnak olyan alkalmak, amikor mégis szükségünk lehet a procfs használatára, mint például régi szoftverek futtatása, a rendszerhívások nyomkövetése a &man.truss.1; segítségével, vagy a bináris Linux kompatibilitás használata. (Noha a bináris Linux kompatibilitás egy saját procfs állományrendszert, egy &man.linprocfs.5; rendszert használ.) A procfs típusú állományrendszerek csatlakoztatásához a következõt kell megadnunk az /etc/fstab állományban: proc /proc procfs rw,noauto 0 0 A beállítás megadásával megakadályozzuk, hogy a /proc a rendszerindítás során magától csatlakoztatódjon. A procfs típusú állományrendszereket így lehet csaltkoztatni: &prompt.root; mount /proc Gyakori parancsok A csomagok kezelése Linuxos parancs (Red Hat/Debian) A &os;-s megfelelõje Leírás yum install csomag / apt-get install csomag pkg_add -r csomag A csomag telepítése egy távoli számítógéprõl rpm -ivh csomag / dpkg -i csomag pkg_add -v csomag Csomag telepítése rpm -qa / dpkg -l pkg_info A telepített csomagok megjelenítése A rendszer kezelése Linuxos parancs A &os;-s megfelelõje Leírás lspci pciconf A PCI-os eszközök megjelenítése lsmod kldstat A betöltött rendszermagmodulok felsorolása modprobe kldload / kldunload Modulok betöltése és eltávolítása strace truss A rendszerhívások nyomkövetése Lezárás Bízunk benne, hogy ez a leírás eleget mutatott be ahhoz, hogy elkezdjünk ismerkedni a &os;-vel. Ha az érintett témák még jobban érdekelnek minket vagy olyanról szeretnénk többet megtudni, ami itt nem szerepelt, akkor mindenképpen olvassunk bele a &os; kézikönyvbe.
diff --git a/hu_HU.ISO8859-2/books/handbook/vinum/chapter.sgml b/hu_HU.ISO8859-2/books/handbook/vinum/chapter.sgml index f560bf6d27..691438dea0 100644 --- a/hu_HU.ISO8859-2/books/handbook/vinum/chapter.sgml +++ b/hu_HU.ISO8859-2/books/handbook/vinum/chapter.sgml @@ -1,1864 +1,1871 @@ Greg Lehey Az eredeti változatot írta: A Vinum kötetkezelõ Áttekintés Nem számít, milyen lemezeink is vannak, ugyanis mindig adódnak velük kapcsolatban gondjaink: Kicsik. Lassúk. Nem elég megbízhatóak. Ezekre a problémákra javasoltak és meg is valósítottak számos megoldást. A felhasználók egy része általában úgy védekezik ellenük, hogy több, gyakran redundánsan tároló lemezt használ. A különféle kártyák és hardveres RAID-vezérlõk támogatása mellett a &os; alaprendszerében megtalálható egy blokkos eszközmeghajtóként a Vinum kötetkezelõ is, amellyel virtuális lemezmeghajtókat lehet létrehozni. Tehát a 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. Ebben a fejezetben összefoglaljuk a hagyományos lemezes tárolás jellegzetes problémáit és bemutatjuk a Vinum kötetkezelõt. 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. + /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. Kicsik a lemezeink Vinum RAID szoftver A lemezek kapacitása ugyan növekszik, de velük együtt a tárigények is. Ezért gyakran érezzük úgy, hogy a rendelkezésünkre álló lemezek tárkapacitását meghaladó állományrendszerre lenne szükségünk. Kétségtelen, hogy ez a probléma messze nem akkora jelentõségû, mint például tíz évvel ezelõtt, de még mindig fennáll. Egyes rendszerek ezt úgy hidalták át, hogy létrehoztak egy olyan absztrakt eszközt, amely az adatokat több lemezen tárolja el. A hozzáférési idõk szûk keresztmetszetei 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 tranzakciót is folytathat, ami jelentõsen meghaladja a legtöbb lemez átlagos átviteli sebességét. 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. Bármelyik kérést is vesszük, a kiszolgáláshoz a meghajtónak elõször a megfelelõ helyre kell mozgatnia az író/olvasó fejeket, meg kell várni a fej alatt elhaladó elsõ szektort, majd végrehajtani a megfelelõ mûveletet. Ezek a mûveletek szétválaszthatatlanok: semmi értelme nincs megszakítani ezeket. 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. 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. 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. lemezek összefûzése Vinum összefûzés A lemezekre esõ terhelés egyenletessége erõsen függ attól, hogyan osztjuk el az adatokat a meghajtók között. Az itt használt példában a lemezen tárolt adatokat egy könyv oldalaiként érdemes elképzelni, vagyis rengeteg szám szerint címezhetõ adatszektorként. A virtuális lemezt ennek megfelelõen a legegyszerûbben úgy tudjuk felosztani az egymás után következõ független fizikai lemezek mérete szerint és így használni, mintha egy nagy könyvet kisebb részekre téptünk volna. Ezt a módszert nevezik ö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.
Az összefûzött szervezési mód
lemezcsíkozás Vinum csíkozás RAID 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 (striping) vagy RAID-0-nak nevezzük 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. . 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.
A csíkozott szervezési mód
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 meglehetõsen sokat fejlõdtek az utóbbi pár évben, egy szervernek még mindig ezek azok a központi részei, amelyek a leginkább hajlamosak a meghibásodásra. Amikor ez bekövetkezik, a hatása akár egy katasztrófával is felérhet: a sérült lemezmeghajtók cseréje és az adatok visszaállítása napokat is igénybe vehet. 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 (mirroring), 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: Ár. Legalább kétszer annyiba kerül, mint a nem redundánsan tároló megoldások. 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. lemezparitás Vinum paritás RAID-5 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.
A RAID-5 szervezési mód
A RAID-5-nek a tükrözéshez képest megvan az az elõnye, hogy jelentõsen kevesebb tárhelyet igényel. Az olvasás hasonló a csíkozott szervezésekéhez, azonban az írás jóval lassabb, közel 25%-a az olvasás sebességének. Az egyik meghajtó meghibásodása esetén a tömb csökkentett módban még képes folytatni a mûködést: a fennmaradó meghajtókról továbbra is a megszokott módon lehet olvasni, viszont a sérült meghajtóról olvasott adatokat folyamatosan javítani kell a többirõl származó segédinformációk szerint. 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. 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. 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. 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. 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. 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õ allemezeket is nyalábba kötni. Ennek következményeképpen az egyes meghajtók mérete nem korlátozza az erek méretét, emiatt a kötetét sem. 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. Habár egy ér egy kötet teljes adatát ábrázolja, elõfordulhat olyan eset, hogy bizonyos részei hiányoznak fizikai, kialakítási (nem társítottunk allemezeket hozzájuk) okokból adódóan vagy véletlenül (a hozzátartozó lemezterületek sérültek). Amíg legalább egy ér képes a kötet teljes tartalmát szolgáltatni, addig a kötet teljesen épnek tekinthetõ. Teljesítmény A Vinum az összefûzést és a csíkozást is egyaránt megvalósítja az erek szintjén: Az összefûzött ér allemezek területeibõl építkezik. 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. Hogyan szervezzük az ereket? - A &os; &rel.current; verziójában két - fajta erezési megoldást találhatunk: + A &os; &rel.current; verziójában + két fajta erezési megoldást + találhatunk: 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. 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 kívü a Vinum még támaszt egy triviális igényt is: a csíkozott érben legalább két allemeznek lennie kell, mivel másképp nem tér el egy összefûzött értõl. A foglalja össze az egyes erezések elõnyeit és hátrányait. Vinum erezések Erezés típusa Legkevesebb allemez Bõvíthetõ Megegyezõ méret Alkalmazás összefûzött 1 igen nem Sok adat tárolása, ahol a hangsúly a rugalmasságon és a mérsékelt teljesítményen van. csíkozott 2 nem igen Nagy teljesítmény, nagy mennyiségû egyidejû hozzáférés mellett
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 adatbázis minden egyes állapotváltás folyamán frissül, így egy újraindítás után minden egyes Vinum-objektum állapota pontosan helyreállítódik. A konfigurációs állomány A konfigurációs állomány írja le az egyes objektumokat. Egy egyszerûbb kötet definíciója így nézhet ki: drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a Ez az állomány négy Vinum-objektumot definiál: A drive kezdetû sor adja meg a lemez partícióját (meghajtóját) és a hardveren levõ elhelyezkedését. Az a szimbolikus nevet kapta. A szimbolikus és a konkrét eszköznevek szétválasztásával lehetõvé válik, hogy a lemezek félreértések nélkül átkerülhessek egyik helyrõl a másikra. A volume kezdetû sor adja meg a kötetet. Itt az egyetlen szükséges jellemzõ a név, ami ebben az esetben a myvol. A plex kezdetû sor adja meg az eret. Itt az egyetlen szükséges paraméter a szervezési mód, ami ebben az esetben a concat (összefûzött). Nevet nem kell megadnunk, mivel a rendszer automatikusan létrehoz egy nevet a kötet nevébõl a .px utótag hozzáadásával, ahol az x az ér száma lesz a köteten belül. Emiatt a most definiált ér neve myvol.p0 lesz. Az sd kezdetû sor adja meg az allemezt. Itt legalább meg kell adnunk a meghajtónak a nevét, ahol tárolni akarjuk, ill. a méretét. Ahogy már említettük az ereknél is, nevet nem kötelezõ megadnunk, mivel a rendszer magától rendel hozzá nevet, amit a hozzátartozó ér nevébõl származtat, hozzáadja a .sx utótagot, ahol az x az allemez éren belüli sorszáma lesz. Ennek következtében a Vinum ennek az allemeznek a myvol.p0.s0 nevet adja. Miután a &man.gvinum.8; feldolgozta ezt az állományt, az alábbi kimenetet fogja adni: &prompt.root; gvinum -> create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB Ez a kimenet a &man.gvinum.8; egyszerû listázási formátumát mutatja. Grafikusan a mutatja be.
Egyszerû Vinum-kötet
Ezen és az ezt követõ ábrán egy kötetet láthatunk, amely ereket tartalmaz, amelyek pedig allemezeket. Ebben az alapvetõ példában a kötet egyetlen eret tartalmaz, amiben pedig egyetlen allemez van. Az itt bemutatott kötetnek nincs semmilyen elõnye a hagyományos lemezpartícionáláshoz képest. Egyetlen eret tartalmaz, tehát nem is redundáns. Az ér egyetlen allemezt tartalmaz, tehát nem tér el a megszokott lemezpartíciók helyfoglalásától sem. A következõ szakaszokban sokkal érdekesebb konfigurációs módszereket is illusztrálunk. Megnövelt rugalmasság: tükrözés A kötetek rugalmassága tükrözéssel növelhetõ. Egy tükrözött kötet kiosztása során feltétlenül gondoskodnunk kell arról, hogy az egyes erekhez tartozó allemezek eltérõ meghajtókon találhatóak, így az esetleges meghibásodások nem károsítják mind a két eret. Az alábbi konfigurációban egy kötetet tükrözünk: drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b Ebben a példában már nem kellett újra megadnunk az a meghajtót, mivel a Vinum figyelemmel kíséri az összes objektumot a saját konfigurációs adatbázisában. A definíció feldolgozása után a konfiguráció így fog kinézni: Drives: 2 (4 configured) Volumes: 2 (4 configured) Plexes: 3 (8 configured) Subdisks: 3 (16 configured) D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB A ugyanezt a szerkezetet grafikusan is.
Tükrözött Vinum-kötet
Ebben a példában minden ér tartalmazza a teljes 512 MB-os területet. Ahogy a korábbi példa esetén, itt is mindegyik ér csak egyetlen allemezt tartalmaz. A teljesítmény javítása Az elõbbi példában szereplõ tükrözött kötet egy tükrözetlen kötetnél már jobban ellenáll a hibáknak, azonban a teljesítménye is kisebb. A köteten minden egyes írás mind a két meghajtóra érvényesül, ezáltal a lemezek teljes sávszélességét nagyobb arányban használja. A teljesítményre vonatkozó megfontolásaink egy másik megközelítést kívánnak meg: a tükrözés helyett inkább csíkozzuk szét az adatot a lehetõ legtöbb lemezen. Az alábbi konfiguráció egy olyan kötetet mutat be, ahol egy eret négy lemezmeghajtóan keresztül csíkozunk: drive c device /dev/da5h drive d device /dev/da6h volume stripe plex org striped 512k sd length 128m drive a sd length 128m drive b sd length 128m drive c sd length 128m drive d Mint ahogy azt már korábban is említettük, nem szükséges még egyszer megadni azokat a meghajtókat, amiket a Vinum már ismer. A definíció feldolgozása után a konfigurációnk nagyjából így néz ki: Drives: 4 (4 configured) Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB S striped.p0.s0 State: up PO: 0 B Size: 128 MB S striped.p0.s1 State: up PO: 512 kB Size: 128 MB S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB
Csíkozott Vinum-kötet
Ez a kötet a ban látható. A csíkok sötétedése jelzi a helyüket az ér területében: a világosabbak elöl, a sötétebbek hátul szerepelnek. Rugalmasság és teljesítmény Megfelelõ hardver birtokában lehet olyan köteteket is építeni, amelyek mind megnövelt rugalmasságot, mind pedig megnövelt teljesítményt mutatnak a szabványos &unix;-os partíciókhoz képest. Ennek a konfigurációs állománya így nézne ki: volume raid10 plex org striped 512k sd length 102480k drive a sd length 102480k drive b sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e plex org striped 512k sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e sd length 102480k drive a sd length 102480k drive b A második ér allemezei el vannak tolva az elsõ ér allemezeitõl két meghajtónyival. Ez segít megelõzni, hogy az írási mûveletek ne ugyanarra az allemezre vonatkozznak, még akkor is, ha az adatátvitel két meghajtón is keresztülível. A illusztrálja ennek a kötetnek a szerkezetét.
Tükrözött, csíkozott Vinum-kötet
Az objektumok elnevezése Korábban már megismerhettük, hogy a Vinum alapértelmezett neveket társít az erekhez és az allemezekhez, habár ezek a nevek felülbírálhatóak. Ez viszont egyáltalán nem ajánlott, mivel már a VERITAS kötetkezelõ, ahol tetszõleges neveket rendelhetünk az objektumokhoz, használata során kiderült, hogy akkora mértékû rugalmasságot nem kínál fel, mint amennyi zavart képes okozni. A nevek tartalmazhatnak bármilyen nem üres karaktert, azonban érdemes inkább csak betûket, számjegyeket és az aláhúzást használni. A kötetek, erek és allemezek nevei akár 64 karakteresek is lehetnek, a meghajtók nevei pedig 32 karakteresek. - A Vinum objektumai a /dev/gvinum - könyvtáron belüli hierarchiában - helyezkednek el eszközleírókként. Az - imént említett - példakonfiguráció hatására a - következõ eszközleírók jönnek - létre: + A Vinum objektumai a /dev/gvinum könyvtáron + belüli hierarchiában helyezkednek el + eszközleírókként. Az imént + említett példakonfiguráció + hatására a következõ + eszközleírók jönnek létre: Ez a rész csak a Vinum korábbi, elavult implementációjára vonatkozik. - A /dev/vinum/control és - /dev/vinum/controld nevû - vezérlõeszközök, melyeket a + A /dev/vinum/control és + /dev/vinum/controld + nevû vezérlõeszközök, melyeket a &man.gvinum.8; és a Vinum démon használ. Mindegyik kötethez egy eszközleíró tartozik. Ezek a Vinum számára a központi eszközök, ezért az elõbbi konfiguráció révén megjelennek a - /dev/gvinum/myvol, - /dev/gvinum/mirror, - /dev/gvinum/striped, - /dev/gvinum/raid5 és - /dev/gvinum/raid10 + /dev/gvinum/myvol, + /dev/gvinum/mirror, + /dev/gvinum/striped, + /dev/gvinum/raid5 + és /dev/gvinum/raid10 eszközök. Ez a rész csak a Vinum korábbi, elavult implementációjára vonatkozik. Az egyes meghajtókhoz tartozó - leírók a /dev/vinum/drive + leírók a /dev/vinum/drive könyvtárban találhatóak. Ezek valójában szimbolikus linkek a megfelelõ lemezes eszközökre. Minden kötethez közvetlen leírók - tartoznak /dev/gvinum/ + tartoznak /dev/gvinum könyvtárban. Az egyes erek és allemezek eszközleírói a - /dev/gvinum/plex és - /dev/gvinum/sd könyvtárakban - jelennek meg. + /dev/gvinum/plex + és /dev/gvinum/sd + könyvtárakban jelennek meg. Például tekintsük most az alábbi konfigurációs állományt: drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4 Az állomány feldolgozása után az eszközleírókat a &man.gvinum.8; az alábbi módon szervezi a - /dev/gvinum könyvtárban: + /dev/gvinum + könyvtárban: drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd /dev/vinum/plex: total 0 crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/sd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 Jóllehet, az ereket és allemezeket nem ajánlott külön-külön elnevezni, a Vinum meghajtóknak nevet kell adni. Ezzel megoldhatóvá válik, hogy az egyes meghajtók automatikusan felismerhetõek legyenek abban az esetben is, amikor fizikailag áthelyezzük ezeket. A meghajtók nevei legfeljebb 32 karakteresek lehetnek. Állományrendszerek létrehozása A kötetek egyetlen kivétellel teljesen azonosak a lemezekkel a rendszer számára. Ugyanis a &unix;-os meghajtóktól eltérõen a Vinum nem particionálja a köteteket, és ezért nem is tárolnak partíciós táblát. Ez megkövetelte néhány lemezkezelõ segédprogram, leginkább a &man.newfs.8; módosítását, mivel azok korábban megpróbálták a Vinum-kötetek nevének utolsó betûit egy partíció azonosítójaként értelmezni. Például egy lemezes - meghajtó neve /dev/ad0a vagy - /dev/da2h alakú. Az elõbbi az - elsõ (0) IDE lemez elsõ (a) - partícióját, míg az utóbbi a - harmadik (2) SCSI lemez nyolcadik (h) - partícióját jelöli. Ezzel szemben - azonban a Vinum-kötetek neve - /dev/gvinum/concat alakú lesz, ahol - a név semmilyen kapcsolatban nem áll a - partíció nevével. + meghajtó neve /dev/ad0a vagy /dev/da2h alakú. Az + elõbbi az elsõ (0) IDE lemez elsõ + (a) partícióját, + míg az utóbbi a harmadik (2) SCSI lemez nyolcadik + (h) partícióját + jelöli. Ezzel szemben azonban a Vinum-kötetek neve + /dev/gvinum/concat + alakú lesz, ahol a név semmilyen kapcsolatban nem + áll a partíció nevével. Hétköznapi esetben a &man.newfs.8; megpróbálja a lemez nevét értelmezni, és panaszkodik, ha nem sikerül. Például: &prompt.root; newfs /dev/gvinum/concat newfs: /dev/gvinum/concat: can't figure out file system partition A köteten a &man.newfs.8; parancs kiadásával tudunk állományrendszert létrehozni: &prompt.root; newfs /dev/gvinum/concat A &os; 5.0 elõtt verzióiban a &man.newfs.8; parancsnak a régi elnevezési séma használata mellett még át kell adni egy -v kapcsolót is: - - - &prompt.root; newfs -v /dev/vinum/concat + &prompt.root; newfs -v /dev/vinum/concat + A Vinum beállítása A GENERIC rendszermag nem tartalmazza a Vinumot. Habár készíteni lehet olyan rendszermagot, amelyik támogatja a Vinumot, mégsem ajánlott. A Vinumot a szabványos módon modulként (kld) indíthatjuk el. Még a &man.kldload.8; használatára sincs szükség, mivel a &man.gvinum.8; indulása során ellenõrzi a modul jelenlétét és betölti, ha még nem lenne jelen. Indítás A Vinum alapvetõen ugyanúgy tárolja a konfigurációkat a slice-okban, mint maguk a konfigurációs állományok. A konfigurációs adatbázis beolvasása során a Vinum felismeri azokat a kulcsszavakat, amelyeknek nem szabad elõfordulniuk az állományokban. Például a lemezek beállítása tartalmazhatja a következõ szöveget: volume myvol state up volume bigraid state down plex name myvol.p0 state up org concat vol myvol plex name myvol.p1 state up org concat vol myvol plex name myvol.p2 state init org striped 512b vol myvol plex name bigraid.p0 state initializing org raid5 512b vol bigraid sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b Az elõbbiektõl nyilvánvalóan eltér abban, hogy itt már megjelennek a konkrét pozíciókra és elnevezésekre vonatkozó információk (melyeket a felhasználó is megadhat, azonban ezt nem tanácsoljuk), valamint az állapotok (ezeket nem láthatja a felhasználó). A Vinum a konfigurációban nem tárolja a meghajtókat, helyette a beállított lemezes meghajtók partícióin fog Vinum-címkéket keresni. Ennek köszönhetõen a Vinum még akkor is képes pontosan megtalálni a meghajtókat, amikor megváltoznak a hozzátartozó &unix;-os meghajtók azonosítói. Automatikus indítás Ez a rész csak a Vinum elavult implementációjára vonatkozik. A &man.loader.conf.5; közvetítésével a Gvinum mindig automatikusan elindul a hozzátartozó modul betöltésével együtt. Ha a rendszerindításkor be akarjuk tölteni a Gvinum modult, akkor a /boot/loader.conf állományba vegyük fel a geom_vinum_load="YES" sort. Az alábbi sort mindenképpen hozzá kell adnunk az /etc/rc.conf állományhoz, hogy a Vinum a rendszerindítás során automatikusan elinduljon: start_vinum="YES" # állítsuk YES-re az indításhoz Hozzuk létre és írjuk bele, ha nem lenne /etc/rc.conf nevû állományunk. Ennek hatására a rendszer az indulás során betölti a Vinum kld modult, és a konfigurációban szereplõ objektumokat elindítja. Ez még az állományrendszerek csatlakoztatása elõtt történik meg, aminek révén a Vinum-köteteken található állományrendszereket a rendszer automatikusan át tudja vizsgálni az &man.fsck.8; segítségével, majd csatlakoztatja ezeket. Amikor a Vinumot a vinum start paranccsal indítjuk el, a Vinum beolvassa a konfigurációs adatbázist a Vinum-meghajtók egyikérõl. Normál körülmények között mindegyik meghajtón megtalálható a konfigurációs adatbázis egy példánya, ezért szinte teljesen mindegy, melyik meghajtót is olvassa. Egy rendszer-összeomlás után azonban a Vinumnak meg kell tudnia állapítania, melyik meghajtón található meg az adatbázis legfrissebb példánya, és ezt kell beolvasnia. Ezután a lemaradt meghajtókon található adatbázispéldányokat szinkronizálja ehhez a változathoz. Rendszerindítás Vinum-kötetrõl Olyan számítógépeknél, ahol a teljesen tükrözött Vinum-alapú állományrendszereket használunk, kívánatos lehet magát a rendszerindításhoz használt állományrendszert is tükrözni. Egy ilyen konfiguráció összeállítása már messze nem annyira egyszerû, mint egy tetszõleges állományrendszer esetén, mivel: Az indításhoz használt állományrendszernek már a folyamat nagyon korai szakaszában rendelkezésre kell állnia, ezért a Vinumnak már itt elérhetõnek kell lennie. A rendszerindító állományrendszert tartalmazó köteten még ott kell lennie a rendszerindító kódnak és a rendszermagnak is, melyeket a rendszer saját eszközein (például ilyen a BIOS a PC-knél) keresztül kell tudnunk beolvasni, amiket viszont nem tudunk felkészíteni a Vinumra. A soronkövetkezõ szakaszokban rendszerindító kötetként (root volume) fogunk általánosságban véve hivatkozni a rendszerindításhoz használt állományrendszert tartalmazó Vinum-kötetre. Ennek megfelelõen valószínûleg jó ötlet a "root" névvel azonosítani ezt a kötetet, habár technikai szempontból ezt semmi nem követeli meg. Az itt felsorakozó példákban azonban ezt a nevet fogjuk használni. A Vinum kellõen korai indítása Ennek kiváltásához számos lépést kell megtennünk: A rendszermagnak már el kell érnie a Vinumot a rendszerindítás során. Emiatt a ban leírt automatikus indítási módszer nem alkalmazható erre a feladatra, és a start_vinum paramétert nem is szabad használni a most ismertetendõ konfigurációban. A Vinumot statikusan bele is építhetjük a rendszermagba és így állandóan elérhetõ, de ez általában nem kielégítõ megoldás. Megoldhatjuk úgy is, ha a /boot/loader-re () bízzuk a vinum modul betöltését, még a rendszermag elõtt. Ezt az alábbi sorral válthatjuk ki a /boot/loader.conf állományban: geom_vinum_load="YES" A Gvinum használata során az összes többi beállítás automatikusan végrehajtódik, amint a modul betöltõdik, ezért ilyenkor csak a fentebb leírt eljárásra van szükség. Az itt felsoroltak csak az elavult Vinum implementációra vonatkoznak, csupán a régebbi típusú rendszerek kedvéért említjük meg. A Vinumot nagyon korán életre kell keltenünk, hiszen a rendszerindításhoz használt állományrendszert tartalmazó kötetet kell élesítenünk. Alapértelmezés szerint a Vinum rendszerszinten futó része nem keres addig semmilyen Vinum-kötetinformációval rendelkezõ meghajtót, amíg a rendszergazda (vagy valamelyik rendszerindító szkript) ki nem adja a vinum start parancsot. A most következõ bekezdések mutatják be a szükséges lépéseket. Ha hozzáadjuk a következõ sort a /boot/loader.conf állományhoz, akkor azzal utasíthatjuk a Vinumot, hogy a rendszermag indítása során vizsgálja át az összes meghajtót: vinum.autostart="YES" Nem szükséges megmondani a rendszermagnak, merre keresse a rendszerindításhoz használt állományrendszert. A /boot/loader megkeresi a hozzátartozó eszközt a /etc/fstab állományban és átadja ezt az információt a rendszermagnak. Amikor a csatlakoztatására kerül sor, a rendszermag az eszköz nevébõl meg tudja állapítani, melyik eszközmeghajtót kérje meg a belsõ (fõ- és al)eszközazonosító leképzéséhez. A Vinum-alapú rendszerindító kötet elérése a rendszertöltés során Mivel a jelenlegi &os; rendszertöltõ csak 7,5 KB méretû és egyébként is csak az UFS állományrendszerrõl tud állományokat beolvasni (mint például a /boot/loadert), teljesen lehetetlen még a Vinum belsõ szerkezetére is megtanítani, tehát a Vinum-konfigurációk értelmezésére és magának a rendszerindító kötet elemeinek kielemzésére. Ezért be kell vetnünk néhány trükköt ahhoz, hogy a rendszerindító kód számára a rendszerindításhoz használható szabványos "a" partíció képzetét keltsük. Mindez csak akkor válik elérhetõvé, ha az alábbi követelményeket teljesíti a rendszerindító kötet: Nem lehet csíkozott vagy RAID-5 típusú. Erenként nem tartalmazhat egynél több összefûzött allemezt. Láthatjuk, hogy hasznos és lehetséges is több eret használni, melyek mindegyike a rendszerindító állományrendszer egy-egy másolatát tartalmazza. Az indulás folyamán azonban ezen példányok közül csak az egyiken fogja keresni a rendszer a rendszertöltõt és a többi állományt egészen addig, amíg a rendszermag magát az állományrendszert nem csatlakoztatja. A látszat kedvéért az ereken belül található allemezek mindegyikének lennie kell egy saját "a" partíciójának, amivel lényegében alkalmassá válik a rendszerindításra. Ezeknek a hamis "a" partícióknak nem kell feltétlenül a többiekkel megegyezõ pozíciókon elhelyezkedniük, azonban a tévedések elkerülése érdekében valószínûleg hasznos olyan Vinum-köteteket létrehozni, ahol a keletkezõ tükrözött eszközök szimmetrikusak. A rendszerindító kötet egyes eszközökön található "a" partícióit az alábbiak segítségével állíthatjuk be: A rendszerindító kötet részeként megjelenõ eszközön található allemez helyét (az eszköz elejétõl számított eltolását) és méretét ellenõrizni kell az alábbi parancs segítségével: &prompt.root; gvinum l -rv root Ne felejtsük el, hogy a Vinum az eltolásokat és méreteket byte-okban méri. Ezekbõl tehát úgy nyerünk a bsdlabel használatához szükséges blokkszámokat, ha ezeket elosztjuk 512-vel. Futassuk le a &prompt.root; bsdlabel -e eszköznév parancsot minden olyan eszközön, amelyik részt vesz a rendszerindító kötet kialakításában. Az eszköznév legyen a slice (fdisk)-táblát nem tartalmazó lemezek esetén a lemez neve (mint például da0), vagy ellenkezõ esetben a slice neve (például ad0s1). Ha már lenne egy "a" partíció az eszközön (valószínûleg egy Vinum elõtti rendszeríndító állományrendszert tartalmaz), nevezzük át valami másra és így továbbra is elérhetõ marad (biztos, ami biztos), viszont többé már nem lesz a rendszer számára alapértelmezett rendszerindító eszköz. Az aktív partíciók (mint például az éppen csatlakoztatott rendszerindító állományrendszer) nem nevezhetõek át, ezért ezt a lépést csak akkor tudjuk megtenni, ha a rendszerünket egy Fixit (Helyreállító) eszközrõl indítjuk, vagy egy olyan kétlépéses folyamat során, ahol (tükrözés esetén) a lemezrõl még nem indítottuk el a rendszert. Ezt követõen az eszközön található Vinum-partíciót (amennyiben létezik) az eszközön levõ allemez eltolásához kell helyezni. Ennek eredménye lesz az új "a" partíció "offset" értéke. A partíció "size" (méret) értéke szó szerint átemelhetõ a fenti számításból. Az "fstype" legyen 4.2BSD. Az "fsize", "bsize" és "cpg" értékeket a jelenlegi állományrendszerhez mérten ajánlott megválasztani, azonban itt most egyáltalán nem bírnak jelentõséggel. Ezzel a módszerrel létesítettünk egy olyan új "a" partíciót, amely lefedi az eszközön található Vinum-partíciót. Jegyezzük meg, hogy a bsdlabel kizárolag csak abban az esetben fogja megengedi ezt az átfedést, ha a Vinum-partíciónk "vinum" típussal van megjelölve. Készen is vagyunk! Most már van minden eszközön egy hamisított "a" partíciónk, amelyeken megtalálható a rendszerindító kötet egy-egy másolata. Határozottan ajánlott még egyszer ellenõrizni a munkánkat az alábbi parancs kiadásával: &prompt.root; fsck -n /dev/eszköznéva Figyeljünk arra, hogy az összes vezérlési információt tartalmazó állománynak a Vinum-köteten található rendszerindító állományrendszerre kell vonatkoznia, ami viszont egy új Vinum rendszerindító kötet beállítása után nem feltétlenül egyezik meg a jelenlegi aktív állományrendszerrel. Különösen az /etc/fstab és /boot/loader.conf állományokat kell ilyen szempontból ellenõriznünk. A következõ indítás során a rendszertöltõ már az új Vinum-alapú rendszerindító állományrendszerrõl fogja összeszedni a mûködéséhez szükséges adatokat és ezeknek megfelelõen cselekedni. Végül, a rendszermag inicializálója után, mikor az összes eszközt felismerte, egy ehhez hasonló feltûnõ üzenet fogja jelezni a beállítás sikerességét: Mounting root from ufs:/dev/gvinum/root Egy Vinum-alapú rendszerindító állományrendszer példája Miután sikeresen konfiguráltuk a rendszerindító Vinum-kötetet, a gvinum l -rv root kimenete nagyjából így fog kinézni: ... Subdisk root.p0.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p0 at offset 0 (0 B) Drive disk0 (/dev/da0h) at offset 135680 (132 kB) Subdisk root.p1.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p1 at offset 0 (0 B) Drive disk1 (/dev/da1h) at offset 135680 (132 kB) - Itt (a /dev/da0h + Itt (a /dev/da0h partícióhoz képesti) 135680-as eltoltás értékekre kell figyelnünk. Ez képzõdik le a bsdlabel fogalmi rendszerében aztán 265 darab 512 byte-os blokkra a lemezen. Ehhez hasonlóan a rendszerindító kötet mérete 245 760 darab 512 byte-os blokk lesz. A rendszerindító kötet másodpéldányát tartalmazó - /dev/da1h ugyanilyen + /dev/da1h ugyanilyen beállításokkal rendelkezik. Az említett eszközök valahogy így jelennek meg a bsdlabel szerint: ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) h: 71771672 16 vinum # (Cyl. 0*- 4467*) Megfigyelhetõ, hogy a hamis "a" partíció "size" paraméter értéke megegyezik a fentebb becsült értékkel, miközben az "offset" paraméter értéke egyenlõ lesz a "h" Vinum-partíción belüli eltolás és az eszközön (vagy slice-on) belüli eltolás összegével. Ez jellemzõen egy olyan beállítás, amivel szükségszerûen el tudjuk kerülni a ban leírt hibajelenséget. Látható továbbá az is, hogy az egész "a" partíció végig az eszköz összes Vinum adatát tartalmazó "h" partíciójában foglal helyet. A példával kapcsolatban megjegyezzük, hogy itt az egész eszközt a Vinum felügyelete alá bocsátottuk, tehát nem marad hátra semmilyen Vinum elõtt használt rendszerindító partíció, hiszen ez egy olyan lemez, amelyet eleve egy Vinum-konfigurációba szántunk. Hibakeresés Fontos tudunk, hogy probléma esetén hogyan tudjuk helyreállítani a rendszerünket. A következõ felsorolásban bemutatunk néhány ismert buktatót és a megoldásaikat. A rendszertöltõ elindul, de a rendszer viszont már nem Ha valamilyen okból a rendszer nem indulna el, a 10 másodpercig tartó visszaszámlálás során a rendszertöltõt még meg tudjuk állítani a szóköz lenyomásával. Ekkor a betöltõ által használt változók (mint például a vinum.autostart) a show segítségével megvizsgálhatóak és a set vagy unset parancsokkal módosíthatóak. Ha mindössze az volt a probléma, hogy a Vinum modulja nem szerepelt az automatikusan betöltendõ modulok között, a load geom_vinum parancs kiadásával betölthetjük azt. Miután végeztünk, a rendszerindítás folyamata a boot -as paranccsal folytatható. A kapcsolók jelzik a rendszermag számára, hogy kérdezzen rá a rendszerindító állományrendszerre a csatlakoztatása elõtt () és csak egyfelhasználós módban indítsa a rendszert (), ahol a rendszerindító állományrendszer írásvédett. Így, ha csak egyetlen eret csatlakoztattunk egy többeres kötetbõl, az erek még véletlenül sem tudnak egymásnak ellentmondó állapotba kerülni. Amikor megjelenik a csatlakoztatandó rendszerindító állományrendszert bekérése, bármelyik érvényes rendszerindításra alkalmas állományrendszer megadható. Amennyiben az /etc/fstab állományt jól beállítottuk, az alapértelmezett érték egy ufs:/dev/gvinum/root értékhez hasonló alakú lesz. Itt általában egy ufs:da0d formátumú értéket láthatunk, amely feltehetõen egy Vinum használata elõtti rendszerindító állományrendszert tartalmazó partíció. Legyünk óvatosak, ha itt egy olyan "a" partíciót adunk meg, amely valójában egy rendszerindító Vinum-eszköz allemezeire hivatkozik, mivel egy tükrözött konfiguráció esetén csak az eszköz egyik részét fogjuk csatlakoztatni. Ha a késõbbiekben ezt az állományrendszert már nem csak írásvédett módban csatlakoztatjuk, mindenképpen el kell távolítanunk a rendszerindító Vinum-kötetbõl a többi eret, mivel máskülönben nagy valószínûséggel eltérõ adatokat fognak tartalmazni. Csak az elsõdleges rendszertöltõ indul el Amikor az elsõdleges rendszertöltõ még elindul, viszont a /boot/loader már nem tud betöltõdni (ezt rendszerindítás megkezdése után bal oldalt rögtön megjelenõ forgó vonalból vehetjük észre), a szóköz lenyomásával itt még tehetünk egy kísérletet a betöltés megszakítására. Ennek hatására a rendszertöltés megáll a második fázisban, lásd . Itt a rendszerindításhoz megpróbálhatunk megadni egy másik partíciót, például egy olyat, amely a korábbi rendszerindító állományrendszert tartalmazza és amelyet az elõbb átneveztünk az "a"-ról. Semmi sem indul, a rendszertöltõ hibákat ír Ez a helyzet akkor állhat elõ, ha a Vinum telepítése során tönkretettük volna a rendszertöltõt. Sajnos a Vinum minden esetben 4 KB helyet hagy szabadon a partíció elején, a saját fejléc információjának rögzítése elõtt. Az ide kerülõ elsõ és második fázisú rendszertöltõk, illetve a bsdlabel adatai azonban jelenleg 8 KB helyet kívánnak meg. Így ha a Vinum-partíció egy rendszerindításra szánt slice vagy lemez 0. eltolásánál kezdõdik, a Vinum beállításai felül fogják írni a rendszertöltõt. A rendszertöltõ is ugyanígy felülírja a Vinum fejlécét és akkor a Vinum nem találja a lemezeit, ha a fenti problémát orvosolva, például egy Fixit (Helyreállító) lemez segítségével, újratelepítjük a rendszertöltõt a ban bemutatott bsdlabel -B parancs segítségével. Noha a Vinum egyetlen konkrét konfigurációs beállítása vagy a kötetekben tárolt adat sem sérül meg és vissza tudjuk állítani az összes elveszett információt ugyannak a Vinum-konfigurációnak az újbóli megadásával, a helyzetet magát nehéz megoldani. A Vinum-fejléc és a rendszertöltõ ütközésének megszüntetéséhez ugyanis legalább 4 KB-tal arrébb kell mozgatnunk az egész Vinum-partíciót.