Filerendszerek

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2006. október 27., 01:53-kor történt szerkesztése után volt.

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á
  • 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 szülője 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 beleírnak)
  • 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
      • négy namespace: user, trusted, security, system

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.

1.1 AFS

1.1.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.

1.1.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.

1.1.3 Működésének alapelvei

1.1.3.1 Cachelé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.

1.1.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.

1.1.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.

1.1.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.

1.1.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.

1.1.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.

1.2 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)

2 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.

Fontos tulajdonságok:

  • naplózás
    • fizikai <-> logikai
    • metadata <-> teljes
    • beépített <-> külső
  • átméretezhetőség
    • online <-> offline
    • csak növelhető <-> zsugorítható is

Altalános mount opciók:

  • 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ó)
  • 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

2.1 ext2

  • 1993 óta ez a szabványos linuxos fs, bár mostanra nagyrészt kiszorította az ext3
  • max. 4 tebibyte (más forrás szerint 8)
  • fileméret max. 2 tebibyte (más forrás szerint 1 tebibyte)
  • filenév max. 255 karakter
  • filenévben nem lehet NULL és /
  • elfogadható sebesség
  • mára tud POSIX ACLeket é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ő (ez biztos, de mintha lenne online növeléshez patch)
  • offline zsugorítható (patch-csel esetleg online is?)

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

2.2 ext3

  • Az ext2 bővítése
    • journalinggal (fizikai, nem olyan jó)
    • sok file-t tartalmazó könyvtár esetén gyorsabb
    • 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
  • 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.

2.3 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 nagyon gyors
  • 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
    • í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

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

2.4 XFS

  • SGI fejlesztés
  • Az első unixos naplózó filerendszer (1994, IRIX 5.3)
  • Linuxban a 2.4.25 óta (2000 körül)
  • FreeBSD 2005 vége óta olvassa, a 7.0 már írja is
  • max. méret: 9 exbibyte (32 biten 16 tebibyte)
  • max. fileméret: 9 exbibyte (32 biten 16 tebibyte)
  • metadata journal (logikai, hatékony)
  • 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)
  • 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
    • 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 (extents)
  • az alap-blokkok mérete 512 byte-tól 64K-ig terjedhet, létrehozáskor kell beállítani
  • 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)

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
  • undelete lényegében lehetetlen

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 fele 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
      • unwritten extent support (mire jó?)
      • 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
  • 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
  • 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"
  • 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ó: -l version=2
    • é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
    • 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
  • 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?

2.5 JFS

  • IBM fejlesztés
  • Igazából ez már a JFS2, az OS/2 Warpban jelent meg (1999-ben)
  • Linuxban 2001 óta
  • kiegyensúlyozott, jó teljesítmény
  • jó stabilitás
  • journaling (logikai vagy fizikai?)
    • 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
  • 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:

  • iocharset=utf8: hogyan képezzük le a Unicode fileneveket (itt utf8, de megadhatunk mást is)
  • 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 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

4 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

5 Ajánlott irodalom

6 Potenciális zh-kérdések

  • Mi a sparse file?
  • Mi a különbség a hardlink és a symlink között?
  • Filerendszerek kontextusában mi a fork?
  • Mi a különbség az attribútumok (attributes) és a bővitett attribútumok (extended attributes) között?
  • Milyen konkrét felhasználásai vannak a bővített attribútumoknak?
  • Mi a named pipe?
  • 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?
  • 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?
  • Specifikáljon olyan jogosultságokat egy könyvtárra, amelyeket hagyományos unix-jogosultságokkal nem lehet megvalósítani, de POSIX ACL-ekkel igen!
  • Mi a késleltetett allokáció (delayed allocation)? Mi az előnye?
  • 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?
Személyes eszközök