Mihez kezdhetünk Linux alatt egy fájlrendszerrel?

Mihez kezdhetünk Linux alatt egy fájlrendszerrel? Bárgyú kérdés, fájlokat, könyvtárakat készítünk, módosítunk és törlünk rajta, egyszóval használjuk, a legjobb, ha nem is kell gondolnunk rá, mert minden rendben működik. A következő néhány oldalon azonban nem ilyen hétköznapi feladatokról lesz szó. Olyan kipróbált, hasznos tippeket, ötleteket osztok meg az olvasóval (nem mindegyik az enyém), amelyekre valószínűleg csak kisebb katasztrófák esetén lesz szüksége, de akkor nagyon.

A szöveg tapasztaltabb felhasználók számára íródott, az egyszerűség kedvéért végig a Linux hagyományosnak számító ext2/ext3 fájlrendszerivel fogunk dolgozni, ez mégsem jelenti azt, hogy az ismertetett módszerek kizárólag csak az ext2-alapú rendszerekkel működnek, de feltételezem, hogy aki más fájlrendszert választ, az tisztában van a különbségekkel. A használandó programok legtöbbje alapvető eszköznek számít, a netcat-tól eltekintve nagy valószínűséggel nem lesz szükségünk új csomagok telepítésére a példák kipróbálásához.

A címben feltett kérdésre az első válaszunk: formázhatjuk. A formázás az mke2fs programmal történik. A programot ritkán szokták extra paraméterekkel használni, pedig a finomhangoláson rengeteg múlhat. Itt van mindjárt a -c kapcsoló, ez arra utasítja a mke2fs-t, hogy ellenőrizze a lemez felületét a fájlrendszer létrehozása előtt. Általában csak egyszer van rá szükség: amikor használatba veszünk egy új merevlemezt. A következő parancs a hda1 partíción hoz létre ext2 típusú rendszert az ellenőrzés után:

[~]# mke2fs -c /dev/hda1

A formázáskor érdemes figyelnünk arra, hogy mountolt fájlrendszert -- az ilyen fájlrendszerek listáját a mount parancs argumentumok nélküli futtatásának eredményeképp kapjuk meg -- soha ne próbáljunk formázni.

A fájlrendszer létrehozásának egyik legfontosabb pillanata, amikor eldől, hogy mekkora lesz blokkméret. Ezt nem érdemes a programra bízni, döntsük el mi magunk, hogy mekkora legyen a legkisebb írható és olvasható egység. Amennyiben a fájlrendszer egy Linux-telepítés gyökere lesz, célszerű a legkisebb, 1024 bájtos blokkméret választása, így akár több száz MB helyet is megspórolhatunk egy 4096 bájtos blokkméretű, azonos tartalmú fájlrendszerhez képest. A kisebb blokkméret leheletnyivel lassabb fájlrendszert eredményez, az optimális választás a felhasználón, és rendszer által ellátott feladatokon múlik; a kicsi blokkok inkább a sok kicsi fájlt tartalmazó rendszereknek kedveznek. A blokkméretet a -b kapcsolóval szabályozhatjuk, választási lehetőségeink: 1024, 2048, 4096.

[~]# mke2fs -b 1024 /dev/hda1

Az ext2 fölülről kompatibilis bővítése az ext3 fájlrendszer, amely a műveletekről naplót vezet, ezáltal jelentősen megnő az adatbiztonság. Ext3 rendszert a -j kapcsolóval hozhatunk létre. A fájlrendszer létrehozásakor azt is definiálhatjuk, hogy mekkora terület legyen fenntartva a root felhasználónak. Ennek optimális értéke szintén a felhasználáson múlik, az alapértelmezés 5%, vagyis ennyi hely a normál felhasználók számára mindig elérhetetlen lesz. Ezt az -m kapcsolóval növelhetjük vagy csökkenthetjük. A következő parancs egy 2048 bájt blokkméretű (-b2048), fenntartott hely nélküli (-m0) naplózó fájlrendszert (-j) készít a hda1 partícióra:

[~]# mke2fs -b 2048 -j -m0 /dev/hda1

A részletekre is ügyelő formázási parancs utolsó fontos eleme az inode-ok számának megadása. Fájlrendszerünkön minden egyes fájl és könyvtár egy-egy inode-ot igényel. Ha túl sok inode-unk van, az csupán a helyet foglalja, egyéb problémákat nem okoz, a túl kevés inode azonban rendkívül bosszantó: amint elhasználtuk az utolsót, a rendszer képtelenné válik új fájl vagy könyvtár létrehozására. Előfordulhat, hogy néhány tízezer, rendkívül kevés helyet igénylő, teljesen üres fájllal "véletlenül" teletömünk egy több 100 MB-os partíciót. Fájlrendszereink inode-jainak telítettségét a df -i paranccsal vizsgálhatjuk meg.

[root@server /]# df -i
Filesystem Inodes  IUsed  IFree   IUse% Mounted on
/dev/sda3  525312  31741  493571  7%    /
/dev/sda1  6024    26     5998    1%    /boot
/dev/sda4  1645088 105621 1539467 7%    /var
/dev/hdc1  4882432 19454  4862978 1%    /mnt/hdc1

A formázás során több opcióval is befolyásolhatjuk az inode-ok számát, az egyik ezek közül a -N, amely után megadhatjuk, hogy hány darab idode-ot szeretnénk. Nem kell számolgatnunk, ha a -T kapcsolót, és az ahhoz tartozó három paraméter valamelyikét alkalmazzuk. A -T news hatására -- blokkmérettől függetlenül -- 4KB-onként lesz egy-egy inode-unk, a -T largefile esetében 1 MB-onként, a -T largefile4 esetén pedig 4 MB-onként.

[oldal:Másolhatjuk]

Ideálisan formázott fájlrendszerünkre érdemes a későbbiekben is odafigyelni, például időnként készíthetünk a rajta tárolt adatokról mentést. A jól ismert cp parancsot használjuk most erre a feladatra. Mire kell ügyelnünk a másolás során? Például a fájlrendszerek határaira.

A legtöbb feltelepített Linux egynél több partíciót fogyaszt, még az otthoni felhasználók is szívesen különítik el a tényleges rendszertől a felhasználói könyvtárakat és állományokat tartalmazó /home könyvtárat, és gyakran kerül önálló fájlrendszerre a /usr illetve a /var könyvtár is, a /boot-ról nem is beszélve, bár az effajta, sokpartíciós fölállás inkább szerverekre jellemző. Ha tehát meg szeretnénk őrizni rendszerünk szegmentáltságát, figyelnünk kell arra, hogy a másolási parancs egyik partícióról a másikra csak egy fájlrendszer adatait másolja. Pontosan erre találták ki a cp -x kapcsolóját, ami a másolás forrását egyetlen fájlrendszerre korlátozza. Vegyük azt a köznapi esetet, hogy a Linux rendszer a /dev/hda2-n van, míg a felhasználói adatok a hda3-as partíción, és a hda3 bootoláskor mindig felkerül a hda2 fájlrendszerének /home könyvtárába.

[~]# df -h
Filesystem    Size  Used Avail Use% Mounted on
/dev/hda2     2.0G  779M  1.2G  39% /
/dev/hda3      17G  7.0G  9.6G  42% /home

Pontosan le szeretnénk másolni a hda2 tartalmát, a fájlok és könyvtárak tulajdonosi és hozzáférési jogaival együtt, a rendszerben lévő linkeket pedig úgy szeretnénk megőrizni, ahogy vannak. Mi a teendő? Egy olyan másoló parancsra lesz szükségünk, amelyik (1) vigyáz a linkekre, (2) megőrzi az attribútumokat, (3) rekurzív módon működik, (4) csak egyetlen fájlrendszer adatait másolja, (5) és esetleg a felhasználót is informálja az éppen végzett műveletekről. A megoldás: cp -dpRxv honnan hova (a kapcsolók az előbbi lista sorrendjének megfelelően követik egymást).

Ezen még érdemes finomítanunk. A dpR helyett írhatunk egyszerűen a-t is, és el kell döntenünk, hogy honnan, illetve hová fogunk másolni. A feladatot egyébként a másolás tárgyát képező, működő rendszer alól is elvégezhetjük, de tanácsos ilyen alkalmakkor inkább hajlékonylemezről vagy CD-ről bebootolnuk. A célnak tökéletesen megfelel disztribúciónk telepítő CD-jének rescue disk funkciója, példának okáért a SuSE és a Mandrake rendszerek telepítőkészletének első CD-je remek választás, még akkor is, ha nem ilyen disztribúcióval dolgozunk. Természetesen, ha van, akkor használhatjuk a saját rendszerlemezünket is.

A bootolás után mountoljuk föl a másolandó fájlrendszert mondjuk az /mnt/honnan könyvtárba. A /dev/hda2 állományait a home partíciónk egyik könyvtárába fogjuk másolni, pontosaban a hda3 gyökeréből nyíló rendszer-be. Tehetnénk máshova is, például az /mnt/masikvinyo könyvtárba mountolt /dev/hdb1-re, akárhova, csak ne a /dev/hda2-re. Tehát: a /dev/hda2 az /mnt/honnan-ba van mountolva, a /dev/hda3 pedig az /mnt/hova-ba. A végleges parancs így fog festeni:

cp -avx /mnt/honnan/. /mnt/hova/rendszer

Amíg a cp szorgoskodik, elgondolkodhatunk, hogy mire is jó ez a módszer. Segítségével átköltöztethetjük gondosan beállított Linux-rendszerünket egy új HDD-re, vagy egyszerű biztonsági másolatot készíthetünk. A költöztetésnél két további dologra figyeljünk: az /etc/fstab frissítésére (amennyiben szükséges) és a bootmenedzser megfelelő beállítására (amennyiben szükséges).

[oldal:Reprodukálhatjuk]

A másolás nem mindig megfelelő módszer adataink duplikálására, bármennyire is vonzó az egyszerűsége, nem a cp-vel szokás biztonsági másolatokat készíteni, hanem a tar paranccsal, amelynek lehetőségeiről és gyakori használati módjairól szinte bármelyik Linux kézikönyvben, Administrator's Guide-ban olvashatunk. A következő néhány tipp egy másik, végtelenül egyszerű, ám egyszerűségében is zseniális eszközt mutat be: a dd-t. A dd a szabványos bemenetről vagy egy megadott fájlból a szabványos kimenetre vagy egy megadott fájlba képes másolni, eközben pedig számos konverzióra képes. Mi most csupán másolási képességét vesszük igénybe.

Tegyük fel, hogy van egy rendkívül értékes adatokkal teli hajlékonylemezünk. Mit tehetünk annak érdekében, hogy a lemez adatai ne vesszek el? Lemásoljuk egy másik lemezre? Nem az igazi, hiszen a floppy az egyik legbizonytalanabb adathordozó, sérülékeny, jó lenne valami biztosabb helyre is elmenteni a tartalmát. A dd-vel a floppy első bitjétől az utolsóig mindent lementhetünk egyetlen fájlba:

dd if=/dev/fd0 of=floppy.img

Az első argumentumban megadtuk, hogy a hajlékonylemezes meghajtóban végződő eszközfájl, a /dev/fd0 lesz a bemenetünk, a kimenet pedig egy közönséges fájl lesz, a floppy.img. A kiterjesztés önkényes, megszokásból nevezzük az angol image (kép, képmás, tükörkép) szó nyomán .img-nek. A dd, mint említettem, alapvetően buta program, fogalma sincs arról, hogy mi van a lemezen, de képes tökéletesen másolni a bemenetéről a kimenetére. Ha megnyitjuk egy text/hexeditorral a /dev/fd0 eszközt, egy másik ablakban pedig a már elkészült floppy.img fájlt, észrevehetjük, hogy mindenben megegyeznek.

A lenyomatot ezek után a világ bármelyik, az eredetivel azonos kapacitású hajlékonylemezére felírhatjuk, ugyanolyan lemezt fogunk kapni, megőrizve a floppy fájlrendszerének jellemzőit, a rajta lévő törölt fájlok normál esetben nem látható nyomait, a fájlrendszer töredezettségének mértékét stb. Ebben áll a dd zsenialitásának titka. A lenyomat visszaírása hasonló módszerrel történik:

dd if=floppy.img of=/dev/fd0

Innen már csak egy lépés választ el minket a GB-os fájlrendszerek, sőt egész merevlemezek tarral való archiválásnál jóval pontosabb reprodukciójától:

dd if=/dev/hda1
of=/home/mentés/hda1.img

dd if=/dev/hda
of=/home/mentés/hda.img

[oldal:Tömöríthetjük]

A jól bevált tar+gzip vagy tar+bzip2 párost használók bizonyára nagyokat mosolyognak az előbbi példákon, és joggal vethetik fel a kérdést, hogy vajon hol lesz annyi helyünk, ahol egy egyébként is nagy partíció lenyomata elférhetne. Linux alatt minden megoldható, teszünk egy rövid kitérőt, majd megtudjuk, hogyan készíthetünk jelentősen csökkentett méretű lenyomatokat.

A dd-vel való teljes reprodukció előnye, a tökéletes másolás, egyben az egyik legnagyobb hátránya is. Egy fájlrendszeren nemcsak értékes adatok vannak, hanem szabad terület is, és ez csupa olyan dologgal van tele, ami azelőtt, hogy a terület szabaddá vált volna, értékes volt. Törölt fájlok maradványai, mindenféle bejegyzések, amelyekkel sosem találkozunk, mert a rendszer a felhasználó felé csupán az adatokra váró üres területet mutatja. A dd a lenyomat készítése során ezeket az információkat is precízen lemásolja, ahogy minden más adatot is eltárol a fájlrendszerről.

Amennyiben az üres helyen visszamaradt információktól meg szeretnénk szabadulni, forduljuk csak továbbra is a dd-hez. Bizonyára hallottunk már a Linux rendszerek /dev/zero eszközéről, ezt fogjuk most használni:

dd if=/dev/zero of=/mnt/hda1/00000000.000

Mit csinálhat ez a parancs? Az első felét, gondolom nem szükséges megmagyarázni: nullákat olvasunk ki a /dev/zero-ból. A második fele már érdekesebb, egy 00000000.000 nevű fájlba kerülnek a devzéróból kiolvasott nullák. Nagyszerű, zérókat teszünk a nullába, ez már maga a Zen.

A fájlnév, a 00000000.000 a régi DOS-os időkből maradt névadási reflex eredménye, különben tetszőleges névre keresztelhetjük a születő semmit. A parancs kiadásának előfeltétele a felmountolt, megtisztításra váró fájlrendszer, esetünkben a /dev/hda1, amit az /mnt/hda1 könyvtár alá csatlakoztattunk. Bepötyögjük az előbbi parancsot, és csak várunk, várunk, a merevlemez halkan duruzsol, miközben a fájlrendszerünkön lévő szabad hely fokozatosan feltöltődik a /dev/zero-ból: ezáltal kivételesen nehéz lesz az üres helyről bármit is visszaállítani, mert tényleg üres lesz, telis-tele nullákkal. Amikor a fájlrendszer megtelt, a dd közli, hogy ennyi és ennyi rekordot írt ki, majd leáll, mert betelt a hda1. Ezzel a 00000000.000 teljesítette feladatát, lelkifurdalás nélkül töröljük le, így felszabadul a fájl által foglalt hely. A mentés elkészültéig már ne írjuk semmit a hda1-re, sőt umountoljuk!

A módszer szinte bármilyen fájlrendszer tisztítására használható, régi Linuxokon figyeljünk arra, hogy a 2.2-es kernelben lévő ext2 maximum 2GB-os fájlokat tud csak kezelni. Más okból, de ugyanekkora a maximális fájlméret a FAT32 rendszereken is. Ha 2GB-nál több szabad helyünk van egy ilyen fájlrendszeren, akkor írjunk egy rövid szkriptet, amely egy ciklus segítségével hoz létre a maximális fájlméretnél kisebb fájlokat (00000000.000, 00000000.001 stb.), a dd-vel kiírható adatok maximális méretét a bs és count opciókkal állíthatjuk be, később még kitérünk rájuk.

Ott tartunk tehát, hogy a lementendő fájlrendszer szabad területeit ténylegesen is kiürítettük, nulláztuk így hozzáfoghatunk a lenyomat elkészítéséhez, de nem a szokásos módon, hanem egy csővezetéken keresztül írjuk ki az adatokat a tárolóeszközre:

dd if=/dev/hda1 | bzip2 -9 > /valahova/mentem/hda1.img.bz2

A parancs első része (dd if=/dev/hda1) a hda1 tartalmát az STDOUT-ra teszi ki, ezt a bzip2 röptében, jó hatásfokkal (-9) tömöríti, az eredmény pedig a hda1.img.bz2 nevű fájlba fog kerülni. A hda1-en lévő szabad hely, valamint a fájlrendszerről tárolt egyéb metaadatok a tömörítésnek köszönhetően minimális helyet fognak csak elfoglalni, ráadásul az adatainkat (fájlok és könyvtárak) is egyből tömörítve tároljuk. A visszaállítás sem nehezebb:

bzip2 -dc /valahova/mentem/hda1.img.bz2 | dd of=/dev/hda1

A módszerrel egy-egy fájlrendszer, vagy akár egy egész merevlemez is pontosan reprodukálható, a dd-vel készített lenyomatok a tar-os megoldásnál jóval több információt hordoznak, ezért gyakran szerencsésebb a dd használata. Ugyanakkor a hagyományos (tar+bzip2) mentés és visszaállítás gyorsabb: a most ismertetett eljárással egy 100 GB-os lemezről (még akkor is, ha azon csupán 1 MB adat van) először egy 100 GB-os lenyomat készül, ezt persze a csővezetéken keresztül nagyon picire összetömöríti a bzip, de a merevlemeznek akkor is be kell olvasnia mind a 100 GB-ot, visszaállításnál pedig ismét csak 100 GB-ot fog kiírni. A tar+bzip2 esetében nem a teljes fájlrendszerről készül másolat, csupán a rajta lévő fájlokról és könyvtárakról, így csak 1 MB-ot fog beolvasni a merevlemez és ugyanennyit fog kiírni visszaállításkor is. A mentést tartalmazó fájl mérete azonban mindkét esetben egészen hasonló lesz.

[oldal:Hálózaton küldözgethetjük]

Lássuk csak, mit tehetünk még egy fájlrendszerrel Linux alatt? Áh, igen, hálózaton küldözgethetjük. Ráadásul az egész annyira magától értetődő! Csupán azt kell megszoknunk, hogy Linux alatt "minden fájl". Ha egyszer ráérzünk a logikára, csak rajtunk múlik, hogy miféle ügyes műveletekre képes rendszereket állítunk össze. Következő példánkban a hálózati kommunikációt a netcat csomaggal valósítjuk meg.

A csomag, ha esetleg még nem telepítettük volna rendszerünkre, netcat néven fog szerepelni a telepítőkészletben, bármilyen meglepő. Ami a csomagban van, az már nem ennyire egységes, egyik disztribúcióban nc a futtatható állomány neve, a másikban netcat. Hogy a mi rendszerünkön mi a helyzet, azt egyszerűen kideríthetjük a telepítés után: deb-re épülő disztribúcióknál a dpkg -L netcat listázza a netcat csomaggal települt fájlokat, rpm-es rendszereken pedig az rpm -ql netcat.

A program, legalábbis a kézikönyvoldala szerint, ugyanaz a TCP/IP területén, mint az éllel rendelkező tárgyak birodalmában a svájci bicska. A netcat TCP vagy UDP protokoll használatával képes adatokat küldeni és fogadni hálózaton keresztül, nincs túl sok opciója, ezek közül is csak néhányat fogunk használni.

Van egy rendszerünk, ennek az egyik partícióját el szeretnénk tárolni, mert valami azt súgja, hogy később még jól fog jönni a mentés. A számítógépen azonban nincs elég hely, nincs benne CD-író sem, viszont 100 megabites TCP/IP hálózati kapcsolattal rendelkezik (az IP-címe legyen mondjuk 10.10.10.10). Mi a teendő? Ennyi az egész:

cat /dev/hda1 | netcat -l -p 9456

A parancs első fele beolvassa a /dev/hda1 partíciót egy csővezetékbe, míg a másik fele egy nem használt TCP porton (legyen ez például a 9456, de csak akkor, ha nem itt futtatjuk a titkos belső webszerverünket) figyel és a megfelelő kliensnek továbbítani fogja az adatokat. A megfelelő klienst egy perc alatt összedobhatjuk a hálózat egy másik, például a 10.10.10.11-es számítógépén:

netcat 10.10.10.10 9456 > /vhova/másikgép-hda1.img

Az első paraméter a mentendő adatokat tartalmazó "szerver" számítógép IP-címe, a második paraméter az a TCP port, amihez a kliensünk csatlakozni fog, a parancs vége pedig, ami egyben a hálózaton átívelő csővezeték vége is, arra a fájlra mutat, amelybe elmentjük a 10.10.10.10-es gép hda1 partíciójának lenyomatát. A gyorsan összeállított kliens-szerver rendszert lehet cifrázni, a már ismert módszerrel akár tömöríthetjük is az adatokat, a fogadó gépen nem kötelező hagyományos fájlba írnunk, közvetlenül írhatunk egy pontosan ugyanakkora partícióba is, mint amekkoráról a lenyomat készül.

[oldal:Emulálhatjuk]

A címben felvetett kérdésre rengeteg további válasz létezik, ezek közül még egyet szeretnék kiemelni: emulálhatjuk. Eszközünk megint csak a dd lesz, szükségünk lesz továbbá a kernel egyik funkciójára, a loopback device néven ismert blokkeszközre. Ezzel a párossal létrehozhatunk egy tetszőleges méretű fájlt, amit később önálló fájlrendszerként kezelhetünk. Magyarán egy felmountolt fájlrendszerben létrehozunk egy üres fájlt, amit szépen leformázunk, hogy aztán ezt is felmountolhassuk. Ha jól belegondolunk, már készítettünk ilyen fájlokat, csak azokat lenyomatnak neveztük, és nem tetszőleges méretűek voltak, hanem egy-egy eszköz méretéhez igazodtak. Első lépésünk egy 20 MB-os fájl készítése legyen:

dd if=/dev/zero of=/home/20mega.img bs=1024 count=20480

A bs=1024 a dd által egyszerre beolvasott és kiírt bájtok számát adja meg, a példában ez tehát 1 KB. A count szimpla számláló, ennyi olvasás/írás ciklust fog végrehajtani a dd. A kész fájlt formázzuk az mke2fs segítségével:

[/]# /sbin/mke2fs -b1024 -N 1000 -m0 /home/20mega.img
mke2fs 1.27 (8-Mar-2002)
/home/20mega.img is not a block special device.
Proceed anyway? (y,n) y

A program, mivel nem blokkeszközfájlt kapott formázásra, előzékenyen megkérdi, hogy folytathatja-e, válaszoljunk igennel, és egy pillanat alatt létrejön a fájlrendszerünk, amit akár fel is mountolhatunk:

mount -oloop -text2 /home/20mega.img /mnt/loop/

A fájl úgy fog viselkedni, mintha egy komplett 20 MB-os partíció lenne, az útmutató szerzője pedig úgy örül ennek, mintha komplett bolond lenne -- gondolhatja most az olvasó. Mire jó ez? Rengeteg dolgot kezdhetünk vele, kiírhatjuk például CD-re, úgy, mint az igazi ISO fájlokat. A létrejövő ext2 CD-t a speciális formátum miatt persze csak Linux alatt lehet majd olvasni, de ez ne tartson vissza senkit sem. Használhatjuk továbbá (nem túl komplikált esetekben) a quota rendszer helyett, ugyanis egyszerűbb és biztonságosabb egy ilyen kis loopback fájlrendszer létrehozása, mint a teljes kvótázási rendszer beüzemelése. A SuSE Linux egy CD-s Live Eval változata is ilyen loopback fájlban tárolja a felhasználói adatokat, így érték el a rendszer összeállítói, hogy ne legyen szükség önálló felhasználói partícióra.

Az utolsó tipphez már nem is fűzök magyarázatokat, ennyi gyakorlat után maguktól értetődőek az alábbi parancsok:

dd if=/dev/zero of=/var/extraswap.img bs=1024 count=32786
mkswap /var/extraswap.img
swapon /var/extraswap.img

GFDL | Szólj hozzá a fórumban!

v 1.0 -- Copyright (c) 2002, Karsai Róbert, HWSW (www.hwsw.hu).
A szöveg a GNU Free Documentation License 1.1 (vagy bármelyik későbbi verzió) feltételei szerint másolható, terjeszthető és módosítható. A szöveg másolatainak és a belőle származtatott munkáknak szintén a GNU Free Documentation License feltételeivel kell megjelenniük, a licenc változatlan másolatát és ezt a copyright-megjegyzést mellékelni kell hozzájuk.