Filerendszerek

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(ext4)
(ZFS: Külön szócikkbe költözött a ZFS)
503. sor: 503. sor:
 
==== [http://zfsonlinux.org/ ZFS] ====
 
==== [http://zfsonlinux.org/ ZFS] ====
   
* Linuxra párhuzamosan készül egy [http://zfs-fuse.net/ userspace] és egy [http://zfsonlinux.org/ kernelspace] megvalósítás.
+
L. a [[ZFS]] szócikket.
** A kernelspace implementáció licencproblémák miatt sosem kerülhet bele a hivatalos kernelbe (az OpenSolarist, aminek a ZFS a része, a CDDL alatt teszik elérhetővé, ez pedig jogilag nem kompatibilis a GPL-lel). Az egyetlen megoldás az lenne, hogy valaki nulláról újraírja a ZFS-t (úgy, hogy az adatstruktúrák és algoritmusok ugyanazok, de a kód teljesen új).
 
** A FUSE-os megoldásnak nincsenek ilyen gondjai, mivel a GPL-nek nem kell megfelelnie; cserébe valószínűleg lassúbb.
 
** Jelen sorok írásakor (2010. őszén) a kernelspace-verzió közvetlenül nem használható, mert nincs még hozzá POSIX layer (l. lejjebb); viszont pl. tud a [[Lustre]] számára adattárolóként működni, és a fejlesztők elsősorban erre akarják használni.
 
* Nem értek hozzá igazán; a kipróbálása rajta van a todo-listámon. Addig is néhány információmorzsa, amik között lehet olyan, amiben tévedek (például korántsem biztos, hogy mindez már Linuxon is elérhető):
 
** A Solarishoz fejlesztették; ez akart lenni a Nagy Végső Válasz (majdnem akkora, mint a 42) az összes fájlrendszerproblémára.
 
** Rettenetesen nagy bír lenni (logikailag több adatot tud tárolni, mint amennyi a Földön található összes anyag segítségével fizikailag tárolható lenne).
 
*** A meta-adatok is dinamikusan nőnek: akárhány fájl lehet egy könyvtárban, akárhány fájl lehet összesen stb.
 
** Architektúrafüggetlen.
 
*** A byte-sorrendet úgy kezeli, hogy a blockokban egy bit jelöli, az adott block big vagy little endian;
 
**** az írás mindig natív byte-sorrenddel történik;
 
**** olvasáskor byte-csere kell, ha a beolvasott blokk byte-sorrendje nem azonos a CPU-éval.
 
** A blokkméret változó (de extenteket nem használ).
 
** NTFS-jellegű ACL-eket valósít meg (jobb, mint a POSIX).
 
** Fájlok tulajdonosa windowsos SID is lehet (nemcsak unixos UID/GID).
 
** Eleve tartalmaz logikai kötetkezelőt.
 
** Tranzakciókezelést használ; a lemezen elvileg mindig csak konzisztens állapot létezik, tehát elvileg sosem kell fsck-zni.
 
** Integritásellenőrzés is van benne, így elvileg véd a kábelhibákból és hasonlókból eredő adathibák ellen (legalábbis olvasáskor).
 
** Blokkszintű [http://blogs.sun.com/bonwick/entry/zfs_dedup deduplikációt] valósít meg, ha szeretnénk.
 
*** Többféle hash közül választhatunk, és azt is előírhatjuk, hogy hash-egyezés esetén az adatokat hasonlítsa is össze byte-ról byte-ra, nehogy egy esetleges -- amúgy rendkívül valószínűtlen -- hash-ütközés az adatok sérülését okozza.
 
*** Nem kötelező az összes adatot deduplikálni; szelektíven is bekapcsolhatjuk.
 
** Copy-on-write-elven működik: nem helyben módosítja az adatokat, hanem (nagyjából) azt csinálja, hogy új példányt ír ki belőlük, és amikor végzett, frissíti az adatokra mutató pointert.
 
*** Így automatikusan előáll egy snapshot is (hiszen az eredeti adatok még megvannak); még olcsóbb is meghagyni, mint felszabadítani.
 
** Van "RAID-Z", ami elegendően bonyolult ahhoz, hogy ne lehessen azonnal minden részletében felfogni a működését; a fő előnyei elvileg:
 
*** Nincs szükség read-modify-write-ra (mint a [[RAID#RAID5|RAID5]]/[[RAID#RAID6|RAID6]] esetében).
 
*** Elkerüli azt a problémát, hogy ha az adatok kiírása után, de a paritás kiírása előtt megy el az áram, akkor inkonzisztens lesz a paritás.
 
*** Az integritásellenőrzésnek köszönhetően akkor is kijavítja a hibákat, ha az olvasás látszólag sikerül (tehát amikor egy hagyományos RAID-megvalósítás nem nyúlna a paritáshoz).
 
*** Resync esetén csak azokat a blokkokat másolja, amikben tényleg van adat.
 
*** A "fontos" adatblokkokat több példányban tárolja, mint a kevésbé fontosakat.
 
*** Disk scrubbing: időnként, a háttérben, végigolvassa az adatokat és kijavítja az esetleges hibákat.
 
*** Automatikusan csíkoz a rendelkezésre álló tárolók fölött.
 
**** Ha új diszket rakunk be, arra is elkezd csíkozni és a copy-on-write miatt idővel, szép lassan, minden adat az összes diszkre szétterül.
 
** A ZFS Részei:
 
*** ZFS POSIX Layer (ZPL).
 
**** Ettől látszik fájlrendszernek.
 
*** Data Management Unit (DMU).
 
**** Ez egy általános objektumtároló; ez szavatolja az adatintegritást (ellenőrző összegekkel).
 
**** Elvileg használható a ZPL nélkül is; pl. közvetlenül épülhet rá adatbázis.
 
*** Storage Pool Allocator (SPA).
 
**** Ez kezeli az egész alatti fizikai diszkeket.
 
**** Ez tömörít, blokkszinten; automatikusan megtalálja a "lukakat" a fájlokban és azoknak nem allokál helyet.
 
**** Valószínűleg a titkosítás is ebben a rétegben van megvalósítva.
 
** Nem kell előre eldöntenünk, mi mekkora legyen: a rendelkezésre álló helyből ("pool") a zfs maga gazdálkodik (nyilván állíthatunk be korlátokat).
 
*** Egy-egy "fájlrendszer", amit létrehozunk, igazából csak a benne tárolt fájlok adminisztratív csoportosítását szolgálja.
 
   
 
==== [http://www.lessfs.com/ lessfs] ====
 
==== [http://www.lessfs.com/ lessfs] ====

A lap 2012. október 12., 09:05-kori változata

Tartalomjegyzék

1 Filerendszerek Unix alatt

Unix alatt a Windows-környezetben megszokott elemeken (elsősorban könyvtár, file) kívül előfordulhat néhány további:

  • block special device (háttértár file-szerű absztrakciója)
  • character special device (egyéb driver, pl. hangkártya, terminál, sorosport file-szerű absztrakciója)
  • UNIX domain socket
    • olyan, mint egy hálózati kapcsolat végpontja, de csak az adott gépen belül érvényes
    • lehet rajta szervert üzemeltetni
    • kliens kapcsolódhat rá
    • lekérdezhető, milyen UID-val fut a socket túloldalán levő processz
  • FIFO (named pipe)
    • olyan csővezeték, mint ami a "|" hatására jön létre
    • de nem szükséges, hogy az író és olvasó folyamatoknak közös őse legyen
    • ha valaki megnyitja olvasásra, és olvasni próbál, blokkolódik, amíg valaki más nem ír bele
    • több egyidejű írás nemdeterminisztikus sorrendben hajtódik végre
    • több egyidejű olvasás szintén (ha ketten is várnak olvasható adatra, elvileg bármelyik megkaphatja a következőt, amit valaki beleír)
  • symlink (egy név átirányít egy másikra)
  • hardlink
    • egy file-hoz több név
    • van referenciaszámláló, a hely csak akkor szabadul fel, ha a file utolsó nevét is töröltük és így a számláló 0 lett
  • sparse file
    • "lukas" file
    • lehetnek benne olyan részek, amik számára nincs hely allokálva a filerendszerben
      • ha onnan olvasunk, 0-t kapunk
      • ha oda írunk, allokálódik a hely
    • disk image-nek kiváló
  • fork
    • több adatterület egy file-hoz
    • NTFS-en is van
    • az extended attribútum is ilyesmi
      • A Linuxban négy namespace van definiálva:
        • user (pl. Beagle search, l. pl. [1]),
        • trusted - csak CAP_SYS_ADMIN capabilityvel rendelkező processzek látják (kernelen kívül megvalósított rendszerszintű mechanizmusokhoz jó),
        • security (pl. SELinux),
        • system (pl. POSIX ACL-ek számára).

Ezen túlmenően fontos különbség, hogy a filerendszer case sensitive (de ez senkinek nem szabad, hogy újdonság legyen), hogy egy-gyökerű (szintúgy), és hogy backslash ("\") karakter helyett / választja el egymástól az alkönyvtár-hierarchia szintjeit.

2 Fontos tulajdonságok

Az alábbi tulajdonságok/képességek lehetnek fontosak egy fájlrendszernél:

  • méretkorlátok:
    • mekkora lehet a fájlrendszer?
    • mekkora lehet egy fájl?
    • hány fájl lehet a fájlrendszerben?
    • hány fájl lehet egy könyvtárban?
    • milyen hosszú lehet egy fájlnév?
  • "naplózás", tranzakciókezelés (journaling)
    • fizikai <-> logikai
    • metadata <-> teljes
    • beépített <-> külső
  • átméretezhetőség
    • online <-> offline
    • csak növelhető <-> zsugorítható is
    • milyen gyorsan?
  • milyen időbélyegeket tárol?
    • hozzáférés
    • létrehozás
    • módosítás
    • törlés
    • archiválás/backup (egyetlen linuxos fs sem tudja, de pl. a Sun ZFS igen)
  • bővített attribútumok
  • POSIX ACL-ek
  • verziókövetés
  • naplózás2 (file change log)
    • nem szerencsés mindkettőt naplózásnak hívni, de a journalingnál, ami voltaképpen inkább talán tranzakciókezelés, már elterjedt...
    • haszna: biztonsági audit, ill. adott dátum óta történt módosítások listája (pl. backup, rsync, indexelő használhatja)
  • snapshot-készítés (a ZFS és az NTFS pl. tudja, a linuxos fs-ek többnyire nem)
  • execute-in-place, XIP
    • inkább beágyazott rendszereknél hasznos
  • tail packing (vagy block suballocation)
  • delayed allocation (vagy allocate-on-flush)
    • íráskor csak lefoglalja a helyet, de nem dönti el azonnal, melyik blokkokba fog kerülni a file
    • a blokkok hozzárendelése csak a puffer ürítésekor történik meg
    • így nagyobb valószínűséggel kerül összefüggő helyre a file, kisebb a töredezettség
    • a kevesebb, nagyobb, egybefüggő írás gyorsabb, mint a több kisebb elszórt
  • extent-based allocation
    • a fájlokhoz extentlista tartozik, nem blokklista
    • mivel az extentek több blokkból is állhatnak, a lista rövidebb, mintha minden blokkot külön felsorolnánk
  • kuriózum: log-structured fs
    • a fájlrendszer egy körpuffer, mindig a végére írunk, minden írás egyben napló is
    • ha elfogyna a hely, töröljük a napló elejéről azokat az adatokat, amiknek azóta van újabb verziója
    • mivel a régi verziókból is sok megvan, azokat akár el is érhetjük menet közben (kvázi automatikus snapshot)
    • hátrány: nagyon nagy a fragmentáció
    • előny: egyenletesen koptatja a médiumot (CD-RW-nél vagy flashnél ez fontos)

3 A Linux filerendszerei

A Linux kernel számos filerendszert támogat; ezek között van "natív" linuxos (pl. az ext2, az ext3 és a reiserfs), és pár máshonnan importált filerendszer (pl. minix, vfat, ntfs, jfs, xfs) is.

3.1 Általános mount opciók

Az alábbi mount-opciókat szinte az összes fs támogatja:

  • defaults: rw, suid, dev, exec, auto, nouser, async
  • async: aszinkron I/O
  • auto: a mount -a mountolja (fstab alapján)
  • dev: érvényesek a device típusú file-ok
  • exec: a végrehajthatónak jelölt file-ok végrehajthatók
  • nouser: user nem mountolhatja/umountolhatja
  • rw: írható-olvasható
  • suid: érvényesek a setuid és setgid bitek
  • group: a device-t tulajdonló csoport tagjai mountolhatják, implikálja a nodev, nosuid opciókat
  • owner: mint a group, de a device-t tulajdonló felhasználó mountolhatja
  • noatime: nem frissíti az access dátumot (pl. mail spoolra vagy squid cache_dirre jó, de főleg desktopon érdemes globálisan bekapcsolni)
  • relatime: Viszonylag friss opció. Hatása: általában nem frissíti az atime-ot, de módosításkor igen (amikor úgyis írni kell a meta-adatokat). Levelezőprogramok szeretik, ha tudják, hogy az utolsó módosítás óta volt-e olvasás.
  • noauto: nem mountolódik a mount -a hatására (pl. bootkor)
  • nodev: nem érvényesek rajta a device típusú file-ok (a biztonság kedvéért)
  • noexec: nehezebb programot futtatni róla (shellscriptet könnyű, binárist már nem)
  • nosuid: nem érvényesek a binárisok setuid- és setgid-bitjei (suidperl esetén perlscripteken esetleg igen)
  • remount: újramountolás más opciókkal
  • ro: csak olvasható
  • sync: szinkron I/O (elvileg mindent kiír a diszkre, mielőtt visszatér az író rendszerhívás)
  • dirsync: a könyvtárakra vonatkozó írási műveletek szinkronak, a többi nem
  • user: a filerendszert bárki mountolhatja, de csak az umountolhatja, aki mountolta (bekerül az uidje a /etc/mtabba)
  • users: a filerendszert bárki mountolhatja és umountolhatja

3.2 ext2

  • 1993 óta ez a szabványos linuxos fs, bár mostanra nagyrészt kiszorította az ext3
  • méret: blokkmérettől függően max. 2-32 tebibyte
  • fileméret: blokkmérettől függően max. 16 GiB-64TiB
  • filenév max. 255 karakter
  • filenévben nem lehet NULL és /
  • elfogadható sebesség, bár inkább csak egyszálú I/O esetén
  • mára tud POSIX ACL-eket és extended attribute-okat
  • van hozzá transzparens tömörítést biztosító patch (de kit érdekel?)
  • nemigen használja senki, csak esetleg nagyon kicsi filerendszeren (pl. /boot)
  • offline növelhető (online is, de csak korlátozottan és csak kernelpatchelés után)
  • offline zsugorítható

Létrehozása:

# mke2fs /dev/...

Kapcsolódó eszközök:

  • tune2fs
  • e2fsck
  • resize2fs
  • ext2online
  • ext2resize
  • e2fsadm
  • e2defrag
  • e2undel
  • mke2fs
  • e2fsprogs csomag Debianon

mount opciók:

  • acl: legyen POSIX ACL support
  • check: mountoláskor legyen fsck
  • errors= - mi történjen konzisztenciahiba észlelése esetén?
    • errors=continue: folytatás
    • errors=remount-ro: újramountolás csak olvasható módban és folytatás
    • errors=panic: kernel panic kiváltása (alapértelmezés szerint ilyenkor megáll a kernel, de beállítható, hogy rebootoljon)
  • sb=x: az 1. blokkban levő szuperblokk helyett használjuk az x. blokkban levő másolatát. 2-hatványokkal érdemes próbálkozni.
  • user_xattr: támogassa a felhasználók által beállított extended attribútumokat

3.3 ext3

  • Az ext2 bővítése
    • journalinggal (fizikai, nem olyan jó)
    • sok file-t tartalmazó könyvtár esetén gyorsabb, mint az ext2
    • online növelhető
  • A 2.4.15-ös kernelben jelent meg hivatalosan (jó régen)
  • Mountolható ext2-ként, ha üres a journal
  • Az ext2 helyben upgrade-elhető ext3-ra
  • Az ext3-ból helyben csinálható ext2
  • Egész jó teljesítmény, bár inkább csak egyszálú I/O esetén
  • Jó helyreállíthatóság
  • Nagyon széles körben elterjedt
  • Más oprendszerek is támogatják (Windows driver is van), bár általában csak ext2-ként
  • POSIX ACL, extattr

Létrehozása:

# mke2fs -j /dev/...

Kapcsolódó eszközök: mint az ext2-nél, de undelete nincs.

  • debugfs -R "stat <8>" /dev/...: megmondja, hány blokkból áll a journal (vagyis mennyi helyet foglal). Ha nem a 8-as inode-on van, akkor értelemszerűen a megfelelő inode-számot kell megadni. A tune2fs -l kiírja, melyik a Journal inode.

mount opciók:

  • data= - journaling módja
    • data=journal: az adatműveleteket is naplózza. Lassú, de biztos.
    • data=writeback: a meta-adat-műveleteket naplózza, a többit nem. Crash esetén logfile-ok végén szemét várható.
    • data=ordered: alapértelmezés. Mint a writeback, de a meta-adatok változásainak naplózása előtt az adott file-lal kapcsolatos többi puffert üríti. Crash esetén logfile-ok vége hiányozhat.

3.4 ReiserFS

  • 2.4.1 óta a kernelben
  • első naplózó filerendszer a Linuxban (csak metadata; logikai vagy fizikai?)
  • készül a Reiser4, ezért a ReiserFS-t hívják Reiser3-nak is
  • online növelhető
  • offline zsugorítható
  • tail packing: belső töredezettséget csökkenti, de lassú
  • kis file-okra állítólag nagyon gyors (ez némileg ellentmond annak, hogy a tail packing lassú)
  • egy mérés szerint többszálú I/O esetén jelentősen csökken a sebessége
  • max. méret: 16 tebibyte
  • max. fileméret: 8 tebibyte
  • POSIX ACL, extattr
  • inode-ok lefoglalása dinamikus ("akárhány" file lehet rajta, valójában csak mintegy négymilliárd)
  • delayed allocation

Gyermekbetegségek (részben megoldva):

  • versenyhelyzetek
  • "tree rebuild" fsck során átverhető reiserfs-image-re emlékeztető file-lal
  • instabilitás
  • rossz angolsággal írt dokumentáció

Eszközök:

  • debugreiserfs
    • Általános diagnosztikai eszköz, mindenfélének a kiolvasására
  • reiserfsck
  • reiserfstune
    • journal-hangolás (méret, tranzakcióméret)
    • journal kihelyezése külső eszközre
  • resize_reiserfs
    • offline zsugorítás/növelés
    • online növelés
  • mkreiserfs
  • reiserfsprogs csomag

Fontosabb mount opciók:

  • notail: tail packing kikapcsolása (pl. a LILO kedvéért)
  • resize=blokkszám: remountoláskor használható a filerendszer növelésére

3.5 XFS

  • SGI fejlesztés
  • Az első unixos naplózó filerendszer (1994, IRIX 5.3)
  • Linuxban a 2.4.25 óta (2000 körül)
    • de: a Red Hat még mindig nem támogatja
  • FreeBSD 2005 vége óta olvassa, 2006. június (a 7.0) óta már írja is
  • max. méret: 8 exbibyte (32 biten 16 tebibyte)
  • max. fileméret: 8 exbibyte (32 biten 16 tebibyte)
  • metadata journal (logikai, belső vagy külső)
  • a journal-alapú helyreállítás mountkor automatikus és nagyon gyors
  • crash után a nemrég írt file-okban vagy a végükön nullák lehetnek (főleg naplófile-okban)
    • unwritten extent flagging kikapcsolt állapotában az adott szektorok előző tartalma is megjelenhet
  • többszálú I/O esetén is gyors, részben azért, mert...
  • ...több allocation groupból áll
    • magától felosztja magát ilyenekre
    • file átlóghat egyikből a másikba
    • minden AG maga gazdálkodik a saját szabad helyével és inode-jaival, saját meta-adatai vannak
    • több AG párhuzamos elérése gyors, főleg ha különböző diszkeken vannak (RAID miatt)
  • támogatja a csíkozást (tudja úgy szervezni magát, hogy előnyösen kihasználja az alatta levő RAID0-át)
  • változó méretű blokkokban allokálja a helyet (extent-based allocation)
  • az alap-blokkok mérete 512 byte-tól 64K-ig terjedhet, létrehozáskor kell beállítani
    • kis blokkméret: jobb tárolási hatékonyság, kevesebb belső fragmentáció
    • nagy blokkméret: jobb teljesítőképesség
  • delayed allocation
    • hátrány: sok írás időnként "túlfoglalja" az fs-t; azt mondja, nincs hely, pedig van; sync után tényleg van
    • reisernél is jelentkezik ez?
  • forkok ("villák" :)
    • minden file-típusnak lehet (symlinknek is)
    • valójában inkább bővített attribútumok
  • direct I/O
    • megkerüli az OS cache-t, közvetlenül userspace-be olvas DMA-val
  • realtime I/O (garantált sávszélesség)
  • DMAPI (házi feladat)
    • elvileg arra jó, hogy a diszk cache-eljen egy sokkal nagyobb, mondjuk szalagos tárat, transzparensen
  • snapshot support: ha LVM snapshotot csinálunk, arra az időre konzisztenssé teszi magát (Linux alatt)
  • online defragmentálható (de nem nagyon kell)
  • online növelhető (rendkívül gyorsan, de kell hozzá legalább minimális szabad hely)
  • POSIX ACL
  • dinamikusan allokálja az inode-okat (legfeljebb a teljes hely megadható hányadáig)
  • fejlett kvótarendszer
    • kvóta állítható:
      • userenként
      • csoportonként
      • "projektenként" (könyvtárfánként)
    • állítható soft/hard:
      • helyfoglalás
      • inode-szám
      • helyfoglalás a realtime sectionben (még nincs implementálva)
    • legfeljebb konfigurálható ideig maradhatunk a "soft" kvóta fölött; utána nem tudunk újabb helyet allokálni, amíg a "soft" kvóta alá nem csökkentjük a helyfoglalást

Három része lehet:

  1. data section
    • Meta-adatok
    • Felhasználói adatok (file-ok, könyvtárak tartalma)
  2. log section
    • Ez a journal
    • Alapértelmezés szerint a data section része
    • De lehet külső eszközön is
  3. realtime section
    • A realtime file-ok tárolására

Hátrányok:

  • a bootszektort is használja, nem rakhatunk oda bootloadert
  • nem lehet zsugorítani, offline sem
  • "nem szereti", ha teleírják
    • ha tele van, növelni sem lehet!
  • undelete lényegében lehetetlen
  • ritkán, de előfordulnak bugok; ilyenkor az xfs és a kernel fejlesztői előszeretettel mutogatnak egymásra...
  • nincs "ordered" journaling, úgyhogy tápvesztéskor nagyobb eséllyel kerül szemét a fájlokba
  • könyvtárbejegyzések létrehozása és törlése viszonylag lassú (de ki kellene mérni)
  • a Linux-vserver hashify mechanizmusának használata esetén a vserverek gyökérkönyvtárai ne xfs-en legyenek, különben közös fájlba íráskor az írásra megnyitott példány üresnek látszik (a vserver-fejlesztők dolgoznak rajta, csak nem túl gyorsan)
  • a fájlrendszer címkéje (LABEL) még read-only mountolt állapotban sem írható át, csak umount után

Eszközök:

  • xfsprogs csomag:
  • xfs_copy
    • párhuzamosan akár több új eszközre (vagy sparse image file-ba) is lemásolja a filerendszert
    • csak akkor használható, ha a forrás:
      • nincs mountolva, vagy
      • read-only van mountolva, vagy
      • xfs_freeze-zel befagyasztottuk.
    • a másolatok új UUID-t kapnak, hogy ugyanazon a gépen is használhassuk őket (kivéve -d kapcsoló esetén)
    • nem támogatja a realtime sectiont és a külső journalt
    • kis filerendszer nagyobb helyre másolásához jobb az xfsdump/xfsrestore
  • xfs_db
    • interaktív (de scriptelhető) diagnosztikai eszköz
    • több másik xfs_* program is ezt használja a háttérben
    • ~900 sornyi dokumentáció
    • not for the faint of heart
    • kapcsolgathatók vele opcionális featúrák, pl. extattr support
  • xfs_admin
    • label és UUID átállítása
    • néhány opcionális featúra bekapcsolása
      • pl. unwritten extent support
        • megjelöli azokat a blokkokat, amiket újonnan csapott hozzá fájlokhoz, de a tartalmukat még nem írta ki; journal-visszajátszás esetén ezeket kinullázza, hogy letörölt fájlok tartalma ne jelenjen meg más fájlok végén
      • log version 2
  • xfs_check
    • csak ellenőriz, nem javít
  • xfs_ncheck
    • filenév-inodeszám párok listázása, opcionálisan speciális és setuidos file-ok keresése
    • mire jó? Esetleg hardlinkek keresésére (tudunk egy inode-számot, és kell hozzá az összes név). De ezt tudja a find(1) is.
  • xfs_growfs
    • online átméretezés (offline nem is lehet)
    • elvileg tudná növelni és csökkenteni a journalt (de egyelőre nem tudja)
    • az adatterületet csak növelni lehet
    • a realtime sectiont csak növelni lehet
    • átállítható, hogy az összes helynek legfeljebb hány százalékát használja inode-ok tárolására
    • az utolsó allocation groupot növeli, amíg ugyanakkora nem lesz, mint a többi; ezután újat hoz létre
  • xfs_info
    • mindenféle paramétert kérdez le, pl. allocation group-ok száma, mérete (mountolt fs-re működik)
  • xfs_io
    • diagnosztikai eszköz, mint az xfs_db, de magasabb szintű műveletekkel
    • az xfs-driver tesztelésére, próbálgatására való
  • xfs_bmap
    • melyik blokkokat használja az adott file?
    • mire jó ez?
  • xfs_freeze
    • felfüggeszti az írhatóságot
    • folyamatban levő tranzakciók befejeződnek
    • író processzek blokkolódnak
    • az immár konzisztens filerendszerről csinálhatunk snapshotot
    • utána xfs_freeze -u "olvasztja ki"
    • erre nincs szükség, ha az LVM és a mountolt xfs tud egymásról
  • xfs_mkfile
    • tetszőleges méretű file-t hoz létre, opcionálisan sparse
    • miért jobb, mint a dd(1)?
  • xfs_logprint
    • megnézhetjük vele a journal tartalmát - csak xfs-szakértőknek mond valamit
  • xfs_quota
    • kvóta-adminisztráció
  • xfs_rtcp
    • file-okat másolhatunk vele a realime-adatterületre
  • fsck.xfs
    • nem csinál semmit, az fsck mountoláskor automatikus, ha piszkos a journal
  • mkfs.xfs
    • ez hozza létre az xfs-t
    • ajánlott opciók: -l version=2 -l lazy-count=1
    • érdekes lehetőség: egy szövegfile-ban megadhatunk egyfajta template-et, ami alapján már adatok is kerülnek az új filerendszerbe (image létrehozásakor lehet hasznos)
  • xfs_repair
    • offline javítóprogram
  • xfsdump csomag:
  • xfs_estimate: várhatóan mennyi helyet foglalna egy könyvtár, ha xfs-re másolnánk?
  • xfs_fsr: online defragmentáló
  • xfsdump: backup-eszköz
    • teljes vagy (többszintű) inkrementális
      • 0-ás szint: minden file
      • 1-es szint: minden, ami az utolsó 0-ás mentés óta változott
      • 2-es szint: minden, ami az utolsó 1-es mentés óta változott
      • stb., 9-ig
    • elvileg egyszerre több médiumra is tud írni, mindegyikre az fs egy-egy részét (így gyorsabb), de ez Linuxon még nincs meg
    • DMAPI-támogatás
    • megszakítható, majd folytatható
    • a kvótákat is menti
    • a dokumentáció alapján úgy tűnhet, hogy online is konzisztens mentést csinál, de ez nem így van!
  • xfsrestore: helyreállítás

Mount opciók:

  • logbufs=x: tuning-opció. Nagyobb érték -> több memória, de valamivel gyorsabb működés. Max. 8. (A hatást kimérhetné valaki...)
  • logdev=/dev/foo: külső journal
  • norecovery: csak a ro opcióval együtt használható. Nem játssza le a naplót mountkor, így még hozzáférünk a crash előtti állapothoz.
  • nouuid: nem sír, ha ilyen uuid-del rendelkező filerendszer már mountolva van. Snapshot mountolásakor kell megadni.
  • quota/usrquota: kvótakezelés bekapcsolása
  • uqnoenforce: nem akadályozza meg a kvótatúllépést, csak számolja a helyhasználatot
  • grpquota/gqnoenforce: mint fent, csak csoportkvótára
  • mi a helyzet a projektkvótával?

3.6 JFS

  • IBM fejlesztés
  • Igazából ez már a JFS2, az OS/2 Warpban jelent meg (1999-ben)
  • Linuxban 2001 óta
  • méltatlanul mellőzött
  • kiegyensúlyozott, viszonylag jó teljesítmény mindenféle terhelés esetén
  • jó (bár nem kiváló) stabilitás
  • journaling (logikai vagy fizikai?)
  • xattr, POSIX ACL
    • tud külső journalt
  • 64 bites
    • max. fileméret: 512 TiB (512 byte-os blokkméret esetén) - 4 PiB (4 KiB-os blokkméret esetén)
    • max. méret: 32 pebibyte
    • minimális méret: 16 MiB
  • unicode kódolású
  • dinamikusan allokálja az inode-okat
  • a legfeljebb 8 bejegyzést tartalmazó könyvtárak tartalmát is a könyvtár inode-jában tárolja (ez gyors)
  • portolták rá az xfs DMAPI-ját
  • tud(ni fog) olyasmit, mint a Sun ZFS: egy block device-on (a JFS aggregate-nek hívja) több mountolható filerendszer (a JFS-ben fileset), amik közösen gazdálkodnak a szabad hellyel
    • ez olyasmi, mint az xfs projektkvótája
  • szintén támogatja a snapshot-készítést (mint az XFS)
  • White paper, bár nem túl részletes

Eszközök:

  • jfs_fsck
    • a működéséről naplót készít, amit beleír a filerendszerbe
  • jfs_fscklog
    • kiolvassa a filerendszerbe írt naplót
  • jfs_logdump
    • file-ba írja a journal tartalmát - csak JFS-szakértőknek hasznos
  • jfs_mkfs
    • érdekesség: -O opcióval case insensitive filerendszert csinál
  • jfs_tune
  • jfs_debugfs
    • a szokásos
  • jfsutils csomag

Mount opciók:

  • resize: remountoláskor megnöveli a filerendszert (zsugorítani nem lehet)
  • nointegrity: naplózás kikapcsolása; backup visszaállításakor lehet érdemes használni (gyorsabb)

3.7 A közeli jövő fájlrendszerei

Jelenleg is tart néhány új fájlrendszer fejlesztése mind a Linuxban, mind a FreeBSD-ben. Néhány címszóban:

3.7.1 btrfs

  • Linus Torvalds egyik notebookjának a rootfs-e, yay!
  • Az Oracle kezdte fejleszteni (az egyik fejlesztő Valerie Aurora, aki korábban a Sunnál dolgozott a ZFS-en).
    • Ő úgy tippeli, hogy 2011 közepére a btrfs lesz az alapértelmezett linuxos fájlrendszer. Meglátjuk.
  • Sok olyasmit tud, mint a Sun ZFS, de teljesen más a megvalósítás (l. pl. A short history of btrfs).
  • Jelenleg még nem használható (pl. még nem végleges az adatformátum).
  • Nagyon nagy, de nem feltétlenül nagyon gyors háttértárakon akar jól működni.
  • Van benne objektumszintű többszörözés és csíkozás;
    • emiatt több blokkeszköz egyidejű kezelése is.
  • Tud röptömörítést.
  • Tudja saját magát snapshotolni, és a snapshotok írhatók (az egész fs copy-on-write szemantikát használ).
  • Online defragmentálható és fsck-zható.
  • Az architektúrája és az algoritmusai valószínűleg megérnének néhány előadást - de nem ezen a kurzuson.

Irodalom: a hivatalos wiki; egy interjú Valerie Aurorával; néhány nem túl átgondolt benchmark; egy német nyelvű cikk a btrfs mindennapi használatáról (a cikk angol fordítása).

3.7.2 NILFS2

  • Log-structured.
  • Folyamatosan snapshotol; olyan, mint egy verziókövető rendszer.
    • Ebből következően van "undelete".
  • Néhány másodpercenként vagy szinkron írásonként készül egy checkpoint; ezeket léptethetjük elő snapshottá, ha akarjuk.
  • A snapshotok csak olvashatók.
  • Állítólag SSD-re kiváló.

3.7.3 ext4

  • Az ext3 közvetlen utódjának szánják.
    • Az ext2 és az ext3 helyben upgrade-elhető ext4-re.
    • Állítólag stabil; nekem más a tapasztalatom.
  • Valódi modern fájlrendszer, minden fontos csengővel és síppal:
    • Részben 64 bites (lehetnek 16TiB-os fájljaink és 1EiB-os, vagyis 1048576TiB-os fájlrendszereink).
    • Extent-alapú allokációt használ.
    • Tud delayed allocationt.
    • A journalt ellenőrző összeggel védi, úgyhogy hibás journalt nem fog visszajátszani.
    • A metaadatokat is tudja cheksummolni (3.5 kerneltől felfelé)
    • Nanoszekundumos felbontású időbélyegeket tárol.
    • Tárolja a létrehozás dátumát is (de egyelőre nem lehet használni).
    • Néhány optimalizáció miatt sokkal gyorsabban fsck-z, mint az ext3.
    • Elvileg online defragmentálható lesz.
    • 32000-ről 64000-re nőtt az egy alkonyvtárban létrehozható alkönyvtárak száma (és gányolva efölé is mehetünk).
    • Támogatja a preallokációt: az fallocate() rendszerhívással előre lefoglalhatunk (jó eséllyel összefüggő) helyet egy fájlnak, amelyről tudjuk, mekkora lesz (ezt amúgy csak az xfs tudja jelenleg).

3.7.4 ZFS

L. a ZFS szócikket.

3.7.5 lessfs

  • FUSE-ra épül.
  • Blokkszinten deduplikál.
    • A blokkméret és a hash hossza és típusa változtatható.
  • Opcionálisan röptömörít és titkosít.
  • Tud master-slave replikációt.
  • Aránylag sok memóriát foglal (bár ez konfigurálható).
  • Rettenetesen lassú, ami korlátozza a felhasználhatóságát.
    • Tömörítés nélkül nem próbáltam, úgy bizonyára gyorsabb (lehetséges házi feladat).
  • Aluldokumentált.
  • Nem támogatja sem az ACL-eket, sem a bővített attribútumokat.
  • Statikusan kell méretezni (előre meg kell mondani, legfeljebb hány fájl stb. lesz rajta).

4 Attribútumok

Néhány filerendszerben mindenféle attribútumai lehetnek a file-oknak; ennek semmi köze a bővített attribútumokhoz. Nem minden fs ismeri az alábbiak közül az összeset. (Mit tud ebből a reiserfs és a jfs? A jfs látszólag semmit.)

  • lsattr
  • chattr
  • xfs_io
  • A: atime ne módosuljon (ext2, ext3, xfs)
  • a: csak hozzáfűzni lehet (ext2, ext3, xfs)
  • c: röptömörített (ext2, ext3 - de csak patchel)
  • D: könyvtáron: mintha dirsync opcióval mountoltuk volna az fs-t (ext2, ext3)
  • d: ne backupolódjon (nyilván programfüggő, hogy nézi-e) (ext2, ext3, xfs)
  • f: no-defrag: a file-t nem szabad defragmentálni. Könyvtár esetén a file-ok öröklik. (xfs)
  • i: immutable. Nem módosítható, nem törölhető, nem hardlinkelhető file. (ext2, ext3, xfs)
  • j: a file úgy viselkedik, mintha data=journal opcióval mountoltuk volna az fs-t. Logfile-okra jó lehet. (ext3)
  • n: a könyvtárban nem lehet symlinket létrehozni (mindenki által írható könyvtárakban bizonyos támadások elkerülésére jó) (xfs)
  • P: project inheritance. A könyvtárban létrehozott új file-ok öröklik a project ID-t a könyvtártól (xfs, kvóta)
  • s: törléskor nullázódik a tartalma (ext2, ext3)
  • S: szinkron írandó file (ext2, ext3, xfs)
  • T: rejtélyes funkciójú ext2/ext3 tuning-attribútum (A directory with the 'T' attribute will be deemed to be the top of directory hierarchies for the purposes of the Orlov block allocator). (ext2, ext3)
  • t: realtime inheritance. A könyvtárban létrehozott új file-ok automatikusan a realtime sectionbe kerülnek (xfs)
  • t: mintha notail opcióval mountoltuk volna (noha az ext2/3-ban egyelőre nincs tail packing/merging) (ext2, ext3)
  • u: törléskor a file nem törlődik valóban, hanem helyreállítható - szerintem nincs implementálva (ext2, ext3)
  • az ext2/3-nak és az xfs-nek is van még pár, részben belső használatra szánt

5 Trükkök a mount körül

  • mount --bind
  • mount --rbind
  • mount --move
  • pivot_root
mount /dev/hda1 /new-root
cd /new-root
pivot_root . old-root
exec chroot . sh <dev/console >dev/console 2>&1
umount /old-root

6 Ideiglenes fájlok biztonságos létrehozása

Lássuk egy tempfile(1)-hívás működésének érdekes részeit:

% env - PATH=$PATH strace -ffF -s200 tempfile -d /tmp -p foo >/dev/null
[...]
stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=20480, ...}) = 0
lstat("/tmp/fooQynlaL", 0x7fff78e730f0) = -1 ENOENT (No such file or directory)
open("/tmp/fooQynlaL", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
close(3)                                = 0
write(1, "/tmp/fooQynlaL\n", 15)        = 15
exit_group(0)                           = ?

Ugyanez mktemp(1) esetén:

% env - PATH=$PATH strace -ffF -s200 mktemp /tmp/fooXXXXXX >/dev/null
[...]
open("/tmp/fooFRUhJW", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
close(3)                                = 0
write(1, "/tmp/fooFRUhJW\n", 15)        = 15
exit_group(0)                           = ?

A fő különbség az, hogy a tempfile a tempname(3) függvényt használja, míg az mktemp nem. Mindkettő biztonságos; az mktemp(3) könyvtári függvény azonban nem! C programokban a kevésbé hordozható, de biztonságos mkstemp(3) függvényt érdemes használni.

Az O_CREAT|O_EXCL flag-kombináció szavatolja, hogy nem létező fájlt nyitunk meg; az open() hibával tér vissza, ha az adott néven már létezik könyvtárbejegyzés (a symlinkeket sem követi).

7 AFS

Írta: Palásti Gábor

7.1 Andrew File System (AFS)

Egy elosztott hálózati fájlrendszer, amit a Carnegie Mellon Egyetemen futó Andrew projekt keretében fejlesztettek ki. A projekt az 1980-as évek közepén indult azzal a céllal, hogy az egyetemen lévő számítógépekhez egy sok funkcióval fűszerezett elosztott rendszert készítsenek. Ennek egyik fő komponense volt az AFS, mint a rendszer által használt fájlrendszer. Később megjelent kereskedelmi formában is a Transarc Corporation gondozásában, jelenleg az IBM kezében van. Az IBM-nek köszönhetően 2000-ben a kereskedelmi változat egy fork-jából megszületett az OpenASF, amit közösségi szinten tartanak karban és fejlesztenek tovább. Ez mellett már korábban megjelent egy ingyenes implementáció, ami az Arla névre hallgat, de ez még mindig eléggé fejlesztés alatt áll.

7.2 Mire jó az AFS?

Segítségével a felhasználók transzparens módon a helyi fájlrendszerükbe illeszthetik az AFS szerveren tárolt fájlokat, könyvtárakat. Ezt helyi megkötések nélkül tehetjük, tehát nem feltétlenül kell a helyi hálózaton lennie az AFS szerveren, akár WAN-on keresztül is elérhetjük.

7.3 Működésének alapelvei

7.3.1 Cache-elés

Működésének alapelve az, hogy a fájlokat a lokális gépen gyorstárazza, ez egyrészt növeli a sebességet, ha többször egymásután hozzá akarunk férni ugyanahhoz a fájlhoz. Másrészt az által, hogy a helyileg meg tudjuk nyitni, nem terheli feleslegesen a szervereket és a hálózatot. Harmadrészt ez segít azokban az esetekben, amikor egy fájlszerver meghibásodik, vagy karbantartási, hálózati okokból nem tudunk hozzáférni a szerverhez, mert a helyi másolatot még mindig tudjuk használni. Ez a módszer azért működik mivel az esetek többségében egy fájlt csak egy ember ír, itt természetesen nem beszélhetünk az adatbázisokat tároló fájlokról. Egyes mérési eredmények szerint egy hét leforgása alatt, a fájlok csupán 0.4%-át módosította egynél több ember.

7.4 Callback mechanizmus

Minden írási és olvasási művelet a helyi fájlon történik. Ha a fájlt becsukjuk, akkor a megváltozott részek visszamásolódnak a szerverre. A callback mechanizmus nem csinál mást, mint megjegyzi, hogy melyik kliens milyen fájlokat töltött le tőle és amint ennek valaki egy újabb változatát hozza létre, erről értesíti az érintett klienst. A callback-eket minden rendszerhiba után újra kell inicializálnunk, a hiba forrása mindegy, lehet a szerverben, a kliensben, vagy akár hálózati jellegű, az inicializálásnak minden esetben le kell futnia. Ehhez azonban nem szükséges a fájlokat újra letöltenünk egyszerűen egy státusz ellenőrzést kell végrehajtani. A cachelési stratégiákból kitűnik, hogy a rendszert inkább több kisebb fájl tárolására, alakították, mivel ez megfelelőbb volt az egyetemi igények kiszolgálására. Ezért sajnos nem ajánlatos sok adatot tömörítő, illetve sokak által módosított fájlokat tárolnunk, mint például adatbázisokat ezen a fájlrendszeren.

7.5 Skálázhatóság

Az AFS tervezéséből adódóan rendkívül, jól skálázható. Nem ritkák az 50. 000 klienst tömörítő AFS cellák sem a professzionális felhasználás körében.

7.6 Biztonság

Az AFS a Kerberos-t használja a felhasználók azonosítására. Ebből következik, hogy a rendszer használatához a kliensnek rendelkeznie kell installált Kerberos-sal Linux esetén kinit, Windows esetén Kerberos for Windows. Az azonosítás során egy Kerberos ticketet kapunk, amivel lehetőségünk van szolgáltatásokat igénybe venni, jelen esetben ezzel tudjuk használni magát az AFS-t. Ez a ticket egy adott ideig azonosítja a felhasználót. Az AFS nem közvetlenül ezt a ticket-et használja, hanem az ebből nyert token-t. POSIX ACL-eket is használhatunk, melyeket könyvtárakra adhatunk meg és userenként, vagy csoportonként állíthatunk. ACL-eket kizárólag könyvtárakra adhatunk meg, a fájlok a szülő könyvtár ACL-jeit öröklik. 7 féle jogot különböztet meg: Read, Look-up, Insert, Delete, Write, Lock, Administer . Negatív bejegyzéseket is használhatunk, ekkor engedélyezés helyett tiltásokat adhatunk meg. Ide tartozó parancsok fs listacl, fs setacl. Az fs parancsokkal bővebben megismerkedhetünk a manuálból.

7.7 AFS felépítése

A /afs/ könyvtárban az ls parancs hatására jó eséllyel további könyvtárakat láthatunk. Ezek az AFS cellák. Egy AFS cella összetartozó szerverek halmaza, melyek egységesen alkotnak egy fájlrendszer. Ebbe beletartoznak a különböző host-ok, melyek tipikusan egy domain-ben vannak, de ez nem szükségszerű. Egy szerver csak egy cellához tartozhat, míg egy kliens akár többhöz is. A tervezésből adódóan 50:1-hez ajánlott a kliens:szerver arányt tartani, de elvileg a 200:1-hez sem okozhatna gondot.

7.8 Migrálhatóság

Akár menet közben is migrálhatjuk a fájlrendszert, szerverről szerverre, vagy diszkről diszkre, a cache-elés miatt a felhasználókat erről nem kell értesíteni. Lehetőség a redundancia miatt read-only másolatok elhelyezésére. Mindehhez megfelelő eszközöket nyújt az AFS.

7.9 Linux kliens telepítése

Feltételezzük, hogy rendelkezünk telepített Kerberos-al, a krb5.conf megfelelően be van állítva. Forrásból: telepítenünk kell a kernel-headers-t, illetve a krb5-dev-et. Symlink a /usr/local/include/com_err.h-ra az aklog könyvtárban.

# ./configure --with-afs-sysname=i386_linux26 --with-krb5-conf=/usr/local/bin/krb5-config [--enable-transarc-paths]
# make
# make install

Konfig fájlok létrehozása: /etc/openafs Itt CellServSDB és a ThisCell beállítása

# mkdir /afs
echo "/afs:cache könyvtár:cache mérete kB-ban" >etc/openafs/cacheinfo

/etc/init.d-be a megfelelő könyvtárkezeléshez tartozó startup script (dir, transarc, default)

8 Ajánlott irodalom

9 Potenciális zh-kérdések

  • Milyen szempontokat érdemes figyelembe venni fájlrendszer választásakor?
  • Mire jó az „append only” attribútum, mikor érdemes használni? Mi a hatása? És az „immutable”-nak?
  • Mi a sparse file? Mire lehet használni? Mondjon minél konkrétabb felhasználási példát!
  • Mi a különbség a hardlink és a symlink között?
  • Filerendszerek kontextusában mi a fork?
  • Egyes fájlrendszerek támogatnak attribútumokat és bővített attribútumokat is. Mi a különbség? Mire való az egyik, mire a másik? Mondjon példát is!
  • Milyen konkrét felhasználásai vannak a bővített attribútumoknak?
  • Mi a named pipe? Mik a főbb különbségek a named pipe és a unix domain socket között? Mik a hasonlóságok?
  • Mi a különbség a logikai és a fizikai journaling között?
  • Milyen opciókkal célszerű mountolni a /home filerendszert? Miért? (Ha a nevük nem ugrana be, elég a hatásuk.)
  • Mire jó a mount --bind?
  • Mire jó a mount --move?
  • Mire jó a pivot_root? Mit csinál?
  • Mire jó az "immutable" attribútum?
  • Mi a különbség az xfsdump/xfsrestore és az xfs_copy között?
  • Mire jók a POSIX ACLek?
  • Mi a DMAPI?
  • Mire jók a POSIX ACLek? Mondjon példát olyan jogosultságrendszerre, ami POSIX ACL-ekkel leírható, de hagyományos unixos jogosultságokkal nem! Bónuszkérdés: olyanra is tud példát, ami POSIX ACL-ekkel sem írható le?
  • Mi a késleltetett allokáció (delayed allocation)? Mi az előnye?
  • Mi a log-structured filesystem? Mik az előnyei, mik a hátrányai?
  • Mit tud az xfs kvótarendszere, amit más filerendszereké általában nem?
  • Mi az előnye annak, hogy az xfs több allokációs csoportból (allocation group, AG) áll?
  • Mi a Mandatory Access Control, és mi az előnye a DAC-cal szemben? Mi a hátránya? Mondjon példát olyan esetre, amikor a DAC nem elegendő, és nem azért, mert nem elég biztonságos!
  • Milyen támadást tesz lehetővé, ha egy program megjósolható nevű fájlt hoz létre mindenki számára írható könyvtárban?
Személyes eszközök