Amikor létrehozunk egy fájlrendszert, akkor számos beállítása az alapértelmezett értékez veszi fel. Ezek viszont nem minden körülmények között biztosítják az optimális megbízhatóságot, hatékonyságot vagy teljesítményt. Nézzük át, hol és hogyan hangolhatjuk a saját igényeink szerint ezeket. Mivel az Ubuntu Linux disztribúciót használjuk, és ebben az ext4 az alapértelmezett fájlrendszer, ezzel fogunk foglalkozni..
Blokkok
A bejegyzés legelején azzal kezdtük, hogy a blokkos eszközök használatával fogunk foglalkozni. A blokk egy egységesen kezelt lemezterület. Mint láttuk, több szinten is megjelenik: fizikai és logikai szektorok, logikai blokkok, de akár a partíció is egy egységesen kezelt területnek fogható fel. Mivel mi itt a fájlrendszerekkel foglalkozunk éppen, vizsgáljuk meg a fájlrendszer szintjén kezelt blokkokat. Ezek a fájlrendszer létrehozásakor alakulnak ki, az ext4 típus esetén például 4096 byte-osak. Az operációs rendszer, amikor fájlokat kezel, minden fájl számára annyi blokkot foglal le, amennyibe belefér. Egyetlen blokk csak egyetlen fájlhoz tartozhat, vagyis ha van egy 1 byte-os fájlunk, az is egy teljes blokkot foglal le, nem kezdődhet ezen a blokkon egy másik fájl. Ha van 1 millió 1 kbyte-os fájlunk az alapértelmezett ext4 fájlrendszeren, akkor hiába foglalnak el az érvényes adatok csak kb. 1MByte-ot, a rendszer akkor is 4MByte tárterületet tart fenn a számukra. Ezért amikor egy fájlrendszert tervezünk, előre kell látnunk, hogy túlnyomórészt milyen fájlokat fogunk rajta tárolni. Ha nagy mennyiségú kisméretű fájllal számolunk, akkor érdemes a blokkméretet kisebbre venni, ha viszont nagyméretű fájlok tárolása a cél, akkor nagyobbra is állíthatjuk az alapértelmezett értéknél. a lehetséges értékek: 1024 byte, 2048 byte, 4096 byte, 8192 byte, stb… A fájlrendszer létrehozásakor a -b kapcsolóval adjuk meg a kívánt blokkméretet, ez utólag már nem módosítható. (Ha nem érvényes blokkméretet adunk meg, a parancs lefelé kerekíti az első érvényesre.)
root@server:~# mkfs.ext4 -b 2048 /dev/sdd1
Kérdezzük is le:
root@server:~# dumpe2fs -h /dev/sdd1 | grep "Block size"
Block size: 2048
Ha egy fájl nem fér bele egy blokkba, akkor a rendszer keres számára egy új, üres blokkot. Egy fájlrendszer hosszas használata után (törölünk, másolunk, mozgatunk, létrehozunk fájlokat), az egy fájlhoz tartozó blokkok nem biztos hogy egymás után fognak fizikailag elhelyezkedni. Ezt nevezzük fregmentáció-nak (töredezettség). (Ennek negatív hatása főleg a merevlemezes háttértárolóknál jelentkezett, ahol az író/olvasó fejeknek ténylegesen kellett mozogniuk egy fájl tartalmának végigolvasása közben.)
Az, hogy egy adott kötet mennyire fregmentált, az fsck paranccsal kérdezhetjük le. Az alábbi példában ez egy nagyon kis érték lett (0.2%).
root@server:~# fsck -fn /dev/mapper/ubuntu--vg-ubuntu--lv | grep contiguous
/dev/mapper/ubuntu--vg-ubuntu--lv: 66003/655360 files (0.2% non-contiguous), 858529/2621440 blocks
Egyetlen fájl töredezettsége is lekérdezhető a filefrag paranccsal:
root@server:~# filefrag -v ./filesystem.img
Filesystem type is: ef53
File size of ./filesystem.img is 10485760 (2560 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 8: 2602512.. 2602520: 9:
1: 9.. 18: 2601488.. 2601497: 10: 2602521:
2: 19.. 19: 2594815.. 2594815: 1: 2601498:
3: 20.. 24: 2601498.. 2601502: 5: 2594816:
4: 25.. 34: 2601503.. 2601512: 10: unwritten
5: 35.. 35: 2602521.. 2602521: 1: 2601513:
6: 195.. 195: 2590719.. 2590719: 1: 2602681:
7: 196.. 1194: 2601513.. 2602511: 999: 2590720: unwritten
8: 1195.. 1195: 2594816.. 2594816: 1: 2602512:
9: 2544.. 2559: 2601472.. 2601487: 16: 2596165: last,unwritten,eof
./filesystem.img: 9 extents found
A parancs nem olyan százalékos formában írja ki a töredezettséget, mint az fsck, de megmutatja, hogyan helyezkednek el a fájl egyes blokkjai a lemezen. A kimenetről leolvashatjuk a fájlrendszer típusát (ef53, ami az ext4 úgynevezett mágikus száma a fájlrendszer szuperblokkjában). Utána láthatjuk, hogy a fájl összesen 2560 darab 4096 byte-os blokkból áll, így a teljes mérete 10MB. Összesen 10 részletben van eltárolva. Minden egyes rész blokkban mért hosszát (length) és elhelyezkedését is leolvashatjuk. A logikai offset (logical_offset) a blokk fájlon belüli pozícióját, míg a fizikai offset (physical_offset) a tárolón elfoglalt helyét jelzi. Az expected oszlopban az adott töredék elvárt helyét jelzi, míg a flag oszlopban azt jelzik, hogy mely töredék nem íródott még ki a lemezre (unwritten), melyik az utolsó töredék (last), és melyikben van a fájl vége (eof). (Ebben a blokkban csak a fájl végéig, és nem a blokk végéig kell az adatokat értelmezni.)
Lehetőségünk van az adott lemez töredezettségét csökkenteni az e4defrag paranccsal. Csökkentsük a töredezettségét az előbbi filesystem.img fájlnak:
root@server:~# e4defrag ./filesystem.img
e4defrag 1.46.5 (30-Dec-2021)
ext4 defragmentation for ./filesystem.img
[1/1]./filesystem.img: 100% [ OK ]
Success: [1/1]
Kérdezzük le ismét, hogyan helyezkednek el a blokkjai. Azt láthatjuk, hogy lényegesen csökkent a töredezettsége, 3 összefüggő szegmensben helyezkedik el, az előző 9 szegmenséhez képest.
root@server:~# filefrag -v ./filesystem.img
Filesystem type is: ef53
File size of ./filesystem.img is 10485760 (2560 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 24: 99584.. 99608: 25:
1: 25.. 34: 99609.. 99618: 10: unwritten
2: 35.. 35: 99619.. 99619: 1:
3: 195.. 195: 114226.. 114226: 1: 99779:
4: 196.. 1194: 114227.. 115225: 999: unwritten
5: 1195.. 1195: 115226.. 115226: 1:
6: 2544.. 2559: 99344.. 99359: 16: 116575: last,unwritten,eof
./filesystem.img: 3 extents found
inode-ok
Ejtsünk pár szót az inode-okról. Mint olvashattuk, egy-egy inode egy-egy fájlt (illetve könyvtárat) ír el. Ahány van belőlük, annyi inode van lefoglalva. És mi van, ha elfogynak a szabad inode-ok? Akkor bizony hiába van szabad helyünk a lemezen, nem hozhatunk újabb állományokat létre. (Ezért van az, hogy bizonyos tárhelyszolgáltatók nem csak a felhasználható lemezterületet, hanem az állományaink darabszámát is korlátozzák. Ha többet szeretnénk bármelyikből, fizessünk értük.) Nagyon fontos megjegyezni, hogy a fájlrendszer létrehozása után már nem változtatható meg a felhasználható inode-ok száma, tehát erre még korábban kell gondolni. De hogyan válasszuk ezt meg? Egyáltalán konfigurálható? A válasz az, hogy igen, bár a rendszer alapértelmezetten meghatározza az inode-ok számát a tárterület nagyságából. Ezt mi is megtehetnénk, a mkfs.ext4 -i kapcsoló használatával, ahol blokkokban kell megadni az értéket.
Hogy megértsük ennek a hátterét, be kell vezetnünk a byte/inode arány fogalmát. Ez az arány megmutatja, hogy hány byte-ot lehet tárolni egyetlen inode-ra jutóan. Minél nagyobb ez a szám, annál nagyobb adatot lehet tárolni egyetlen inode-ra jutóan. A rendszer kevesebb inode-ot kezel, helyettük adatokat képes tárolni. Amennyiben ez az arány kicsi, egyetlen inode-ra kisebb adatterület jut, így több inode lesz tárolva, kevesebb adatterület marad a tényleges adatok tárolására, viszont így több kisebb fájlt lesz képes eltárolni a fájlrendszer.
Vegyünk példaképpen egy 1000 oldalas könyvet a tartalomjegyzékével együtt. A tartalomjegyzékben ugye fejezetcímek vannak eltárolva a hozzájuk tartozó oldalszámokkal együtt. Ha a tartalomjegyzékben csak 20 sor fér el, akkor a könyvben maximum 20 fejezet lehet. Ha mindegyik fejezetünk 50 oldalas, akkor pont 20 db. fér be a tartalomjegyzékbe. Ha viszont van 20 db. 10 oldalas fejezetünk, akkor ezek összesen 200 oldalt fednek le, a maradék 800 oldalon azért nem tárolhatunk szöveget, mert nem tudunk rájuk hivatkozni a tartalomjegyzékből. (Persze itt számos kombináció lehet, de érezzük, hogy a kicsi tartalomjegyzék ára a kevés fejezet.) Szánjunk több területet a tartalomjegyzékre, férjen el benne 100 sor, vagyis 100 fejezetcím. Ilyenkor már akár 100 db. 10 oldalas fejezetettel is lefedhetjük a teljes könyvet, tehát több fejezetünk (fájlunk) lehet. A probléma persze nem szűnt meg, 100 db. 1 oldalas fejezettel csak 100 oldalt fedünk le, 900 felhasználatlanul maradt., tehát ilyen esetben még rosszabb is lehet a helyzet, mint az előbb. (A példa annyiban torzít, hogy a tartalomjegyzék is a könyv oldalaiból vesz el helyet, ahogyan az inode tábla is a lemez teljes tárterületéből.)
Kérdezzük le /dev/sdd1 partíciónk méretét, blokkméretét és inode információit. (A partíción az ext4 fájlrendszer alapértelmezett beállításokkal lett létrehozva.)
root@server:~# df -h /dev/sdd1
Filesystem Size Used Avail Use% Mounted on
/dev/sdd1 40G 24K 38G 1% /mnt/adatok3
root@server:~# dumpe2fs -h /dev/sdd1 | grep "Block size"
dumpe2fs 1.46.5 (30-Dec-2021)
Block size: 4096
root@server:~# tune2fs -l /dev/sdd1 | egrep -i 'inode'
...
Inode count: 2621440
Free inodes: 2621429
Inodes per group: 8192
Inode blocks per group: 512
First inode: 11
Inode size: 256
...
root@server:~# df -i /dev/sdd1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 2621440 11 2621429 1% /mnt/adatok3
Miért kérdeztük le kétféleképpen is a szabad inode-ok számát? Azért, mert a tune2fs a fájlrendszer inicializálásakor érvényes adatokat írja ki, míg a df az éppen aktuálisakat. Most az elején még ugyanazokat az értékeket mutatják.
Értelmezzük a parancsok kimenetét. Láthatjuk, ez egy 40 GB-os partíció, alig van rajta adat. Összesen 2621440 inode-ot tud tárolni, vagyis darabszámra ennyi állományt. Mivel a rendszer létrehozott rajta egy lost+found könyvtárat, arra elment 1 db. inode, és még 10 másikat elhasznált egyéb célokra, maradt 2621429. Az inode-okat csoportokban tárolja. Egy csoportban 8192 inode van (Inodes per group), és egy inode 256 byte hosszú (Inode size). Egy csoportnyi inode így 8192×256=2097152 byte tárterületet igényel. Az ext4 alapértelmezett blokkmérete 4096 byte, ahogyan a dumpe2fs parancs kimenetén is láthatjuk, így egy csoportnyi inode 2097512/4096=512 blokkot foglal le. Pont ezt látjuk az inode blocks per group sorban.
Hozzunk létre egy új file-t a köteten, majd nézzük meg, hogyan alakul az inode-ok száma:. Azt látjuk, hogy a vártaknak megfelelően 1-gyel csökkent a szabad inode-ok száma, a foglaltaké pedig ugyanennyivel nőtt.
root@server:~# touch /mnt/adatok3/adatok.txt
root@server:~# df -i /dev/sdd1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 2621440 12 2621428 1% /mnt/adatok3
Most hozzunk létre egy könyvtárat, ugyanezt tapasztaljuk:
root@server:~# mkdir /mnt/adatok3/adatok
root@server:~# df -i /dev/sdd1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 2621440 13 2621427 1% /mnt/adatok3
Ha pedig egy szimbolikus linket, akkor is:
root@server:~# ln -s /mnt/adatok3/adatok.lnk /mnt/adatok3/adatok3.txt
root@server:~# df -i /dev/sdd1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 2621440 14 2621426 1% /mnt/adatok3
Nézzünk meg egy éles rendszert. Azon a virtuális gépen, ahol ezeket a példákat beírom, egy Ubuntu disztribúció van felinstallálva. Kérdezzük le, mennyire van elhasználva a szabad tárhely és a szabad inode-ok:
root@server:~# df -i /dev/mapper/ubuntu--vg-ubuntu--lv
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv 655360 66001 589359 11% /
root@server:~# df -h /dev/mapper/ubuntu--vg-ubuntu--lv
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv 9.8G 3.0G 6.3G 33% /
Jól látható, a tárhelynek már a 33%-a elfogyott, de az inode-okból csak 11%. Vagyis ha minden így megy tovább, hamarabb fogy el a tárhely, mint a szabad inode-ok. Persze ez csak egy példa, és amennyiben sok, nagyon kis méretű fájlt hozunk létre, az inode fogyás “beelőzhet”.
Térjünk vissza a byte/inode arányhoz. Az ext4 fájlrendszeren alapértelmezetten ez az érték 16 kbyte, vagyis minden 16 kbyte-ra jut egy inode. Ez azt jelenti, hogy a 16kbyte-nál kisebb fájlok “rontanak a helyzeten”, míg az ennél nagyobbak “javítanak”. A fájlrendszer byte/inode aránya utólag nem változtatható, vagyis a létrehozásánál kell másik értéket megadnunk, ha szeretnénk. Mivel az alapértelmezett blokkméret 4kbyte, nincsen értelme ez alá menni, hiszen egy 1byte tartalmú fájl is legalább 4kbyte-ot (egy blokkot) elfoglal, így hiába állítjuk a byte/inode arányt mondjuk 2kbyte-ra, nem tud 2kbyte-onként létrejönni egy fájl. Ilyenkor legrosszabb esetben is (tehát ha csak 2 kbyte méretű állományokat hozunk létre a fájlrendszeren), az inode-ok fele nem lesz elhasználva. Azt is meg kell említeni, hogy a fájlrendszer létrehozásakor az alapértelmezett blokkméretet is változtathatjuk (Csak ekkor, nem utólag!), tehát ha úgy akarjuk, akkor levihetjük a blokkméretet 2kybte-ra. Ilyen esetek viszont ritkán fordulnak elő. Az alábbi példában egy olyan ext4-es fájlrendszert hozunk létre, melyben az inode arány 4kbyte, a blokkméret pedig 2kbyte.
root@server:~# mkfs.ext4 -i 4096 -b 2048 /dev/sdd1
Kérdezzük le most az inode-ok számát. (Fontos megjegyezni, hogy a df használata előtt csatoljuk fel a fájlrendszert! Ezekben a példákban ezt a csatolási parancsot nem tüntetem fel külön.) Ez most 4-szerese az előzőnek. Persze, ugyanaz a 40GB-os partíció, de most nem 16kbyte-onként, hanem 4kbyte-onként lehet egy indode. Ezen a rendszeren már 10 millió állományt tudunk tárolni. Soha ne felejtsük el, hogy az inode-ok számának változtatásával a rájuk szánt adminisztrációs terület is nőt, amit az adatok tárolásától veszünk el.
root@server:~# df -i /dev/sdd1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 10485760 11 10485749 1% /mnt/adatok1
Ellenőrizzük le, hogy a blokkméret is változott-e. Mivel mindent helyesen csináltunk, azt tapasztaljuk, hogy igen.
root@server:~# dumpe2fs -h /dev/sdd1 | grep "Block size"
dumpe2fs 1.46.5 (30-Dec-2021)
Block size: 2048
Az mkfs rendelkezik egy -T kapcsolóval, mely után egy sablon nevét adhatjuk meg, amely szerint hozza létre az adott fájlrendszert. A sablonok neve lehet például small, large, huge. Ezek a nevek a tervezett tárolandó fájlok méretére vonatkoznak. A következő paranccsal például sok kis fájl tárolására alkalmas fájlrendszert hozunk létre:
root@server:~# mkfs.ext4 -T small /dev/sdd1
Érdekességképpen hozzunk létre egy btrfs típusú fájlrendszert, és kérdezzük le a szabad inode számát:
root@server:~# mkfs.btrfs -f /dev/sdd1
root@server:~# df -i /dev/sdd1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdd1 0 0 0 - /mnt/adatok3
Miért kaptunk az inode-ok számára 0-t? Azért, mert a btrfs fájlrendszer nem egy előre meghatározott inode készletből gazdálkodik, hanem azokat képes dinamikusan, a használat során létrehozni.
Térjünk vissza egy pillanatra az inode-ok méretére. Mint emlékszünk, ez 256 byte:
root@server:~# tune2fs -l /dev/sdd1 | grep "Inode size"
Inode size: 256
Viszont ennek a parancsnak a kimenetén még 2 érdekes adat jelenik meg az indode-ok méretéről:
root@server:~# tune2fs -l /dev/sdd1 | grep "extra isize"
Required extra isize: 32
Desired extra isize: 32
Egy inode-hoz a 256 byte-on felül még extra tárterületek is tartoznak, melyekben a rendszer a kiterjesztett attribútumok (extended attributes) és az ACL-ek (Access Control List) információit tárolják. (A kiterjesztett attribútumok egyedi metaadatok állományokhoz való rendelését teszik lehetővé, míg az ACL-ek használatával a hagyományos Linux jogosultságon felül további jogosultságokat is tudunk az állományokon érvényesíteni.)
Naplózás
A fájlrendszeren a rendszer működése során műveleteket hajtunk végre. Fájlokat és könyvtárakat hozunk létre, átnevezzük, töröljük azokat, a fájlok tartalmát módosítjuk, stb. Ezek a műveletek sok apró lépésből állnak, és csak akkor tekinthetők érvényesnek, ha minden lépésük sikeresen végrehajtódik. Egy ilyen folyamatot tranzakciónak nevezünk a naplózás szemszögéből. Egy ilyen tranzakció végrehajtása időbe kerül, és ezalatt van annak valószínűsége, hogy a folyamat valamilyen okból megszakad. Ilyen ok lehet egy áramkimaradás, a RESET gomb megnyomása, vagy valamilyen rendszerösszeomlás. Ilyenkor azonban inkonzisztencia (ellentmondás) léphet fel mind a metaadatok, mind az adatok szintjén, illetve a metaadatok és az adatok között. Ezért a modern fájlrendszerek bevezették a naplózást (journaling), mely segítségével rendszerinduláskor, amikor egy naplózott fájlrendszert felcsatolódik, megpróbálja a naplóbejegyzések alapján felderíteni és kijavítani ezeket az inkonzisztenciákat. A naplózott fájlkezelő műveletek alapvetően a következő lépésekből állnak:
- Műveletek gyűjtése: Amikor végre kell hajtani a fájlrendszerben egy feladatot (például fájl létrehozása, módosítása vagy törlése), az ehhez szükséges műveletek először összegyűjti a rendszer.
- Naplóba írás: Az előző lépésben összegyűjtött lépéseket a rendszer először a naplófájlban hajtja végre, tehát nem az éles adattárolási területen. Ezt a naplófájlt lehet aztán használni bármi baj esetén az eredeti állapotok helyreállítására, vagy éppen az félbeszakadt műveletek befejezésére, így biztosítva az inkonzisztencia helyreállítását. (Az, hogy a naplóba milyen adatok és mikor kerülnek tárolsára, a naplózás módjától függ.)
- Véglegesítés: Amennyiben a naplóba írás sikeres volt, a rendszer véglegesíti a műveleteket a fájlrendszerben, vagyis a változtatásokat ténylegesen alkalmazza a fájlokon és könyvtárakon.
Jól látható, hogy ezek a lépések csökkentik a fájlrendszer teljesítményét (hiszen nem csak a valós adatokkal kell foglalkoznia), ezért a naplózásnak több módját alakították ki. Az ext4 fájlrendszer háromféle naplózási módot támogat: writeback (visszaírás), ordered (rendezett) és data journaling (adatnaplózás). Nézzük meg melyik milyen előnyökkel és hátrányokkal jár:
- writeback: Ennél a módszernél a napló írásának és a tényleges fájlrendszer adatai írásának a sorrendje nem szigorúan rögzített. A rendszer úgy határozza meg az írásuk sorrendjét, hogy a lehető legnagyobb teljesítményt érje el. Ennek viszont az lehet a következménye, hogy egy rendszerösszeomlás esetén a naplóba még nem kerülnek be a javításhoz szükséges információk. Tehát a writeback módszert nagy teljesítmény, de kisebb biztonság jellemzi. Ennél a módszernél csak a metaadatok kerülnek naplózásra.
- ordered: Olyan mint a writeback, de itt a sorrend szigorúan kötött, először a naplót fejezi be, csak utána a fájlrendszer módosítását. (Ezért a rendezett elnevezés.) Tehát a napló alapján az esetleges inkonzisztenciák javíthatók. A megbízhatóság nagyobb, de a teljesítmény kisebb. Itt is csak a metaadatokat naplózza.
- data journaling: Ez a legmegbízhatóbb, de a legkisebb teljesítményű naplózási mód, melyet úgy ér el, hogy mind az adatokat, mint a metaadatokat naplózza.
Az ext4 alapértelmezetten az ordered módot használja. Az egyes módok között a tune2fs paranccsal tudunk váltani:
root@server:~# tune2fs -o journal_data_writeback /dev/sdd1
root@server:~# tune2fs -o journal_data_ordered /dev/sdd1
root@server:~# tune2fs -o journal_data /dev/sdd1
Azt, hogy éppen melyik naplózási mód aktív a következőképpen kérdezhetjük le:
root@server:~# tune2fs -l /dev/sdd1 | grep "Default mount options"
Default mount options: journal_data_ordered user_xattr acl
A naplózás akár ki is kapcsolható a következő módon:
root@server:~# tune2fs -O ^has_journal /dev/sdd1
Kérdezzük le a fájlrendszer naplózásának információit a logdump paranccsal. A parancs kimenetéből láthatjuk, hogy a naplózás nem tartalmaz extra szolgáltatásokat, összesen 256MB tárterületet használ el 65536 blokkban (65536x4k=256MB). A fast commit, egy olyan funkció, amellyel gyorsabb naplózást lehet elérni, itt ez most nincsen bekapcsolva. Jelenleg egyetlen naplózási műveletet sem tartalmaz.
root@server:~# debugfs -R 'logdump -S' /dev/sdd1
debugfs 1.46.5 (30-Dec-2021)
Journal features: (none)
Total journal size: 256M
Total journal blocks: 65536
Max transaction length: 65536
Fast commit length: 0
Journal sequence: 0x00000001
Journal start: 0
Kérdezzük le a rendszer kötetének naplózását. Itt már láthatunk naplóbejegyzéseket, persze nem a halandó emberek számára olvasható formában. Itt még léthatunk egy érdekes bejegyzést, ez pedig a Journal cheksum type. A naplózás ellenőrző összegek használatával biztosítja, hogy a sérült naplóbejegyzéseket észrevegye.
root@server:~# debugfs -R 'logdump -S' /dev/mapper/ubuntu--vg-ubuntu--lv
debugfs 1.46.5 (30-Dec-2021)
Journal features: journal_incompat_revoke journal_64bit journal_checksum_v3
Total journal size: 64M
Total journal blocks: 16384
Max transaction length: 16384
Fast commit length: 0
Journal sequence: 0x0000253a
Journal start: 1
Journal checksum type: crc32c
Journal checksum: 0x8d27bdec
Journal starts at block 1, transaction 9530
Found expected sequence 9530, type 1 (descriptor block) at block 1
Found expected sequence 9530, type 2 (commit block) at block 18
Found expected sequence 9531, type 1 (descriptor block) at block 19
Found expected sequence 9531, type 2 (commit block) at block 22
...
Fontos megjegyezni, hogy az ext4 naplózási funkciója nem képes garantálni, hogy a lemezre írt adatok érvényesek. Ha valamilyen hardverhiba miatt az adathordozón (legyen az merevlemez vagy SSD) megsérülnek az adatok, az ext4 ezt nem képes jelezni. A naplózás csupán az egyes fájlkezelő műveletek megszakadás után a lemez inkonzisztenciáját képes helyreállítani.
Küszöbértékek
Root számára lefoglal terület
Az ext4 a tárterület 5%-át a root számára lefoglalja. Miért érdemes a root számára extra tárhelyet fenntartani? Azért, mert a fájlrendszer más felhasználók (vagy más felhasználók által futó folyamatok) miatt telítődne, a root számára még marad hely, hogy mentse a helyzetet. (Feltéve ha nem miatta telítődött. Ha például az error.log fájlt hagyjuk kontrollálatlanul nőni, akkor ez a tartalék hely is enyészetté válik.) Érdemes-e 5%-ot tartalékolni? Amikor a háttértárak átlagos mérete pár 100 GB volt, akkor ez még talán elfogadható volt, ma már viszont túlságosan nagy, így érdemes csökkenteni. Ráadásul nem minden köteten feltétlenül szükséges tartalékolni. Először nézzük meg a /dev/sdd1 teljes méretét:
root@server:~# lsblk /dev/sdd1
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdd1 8:49 0 40G 0 part
Majd nézzük meg a root számára lefoglalt blokkok számát a tune2fs paranccsal:
root@server:~# tune2fs -l /dev/sdd1 | grep "Reserved block count"
Reserved block count: 524275
Az 524275 blokk összesen 2GB-ot fed le (524275x4kbyte=2GB), ami a 40GB-nak pont az 5%-a. Változtassuk meg most ezt 1%-ra. Ismét a tune2fs-t használhatjuk. (Ha nem lenne tartalék területre szükség, akár 0%-ra is beállíthatjuk.)
root@server:~# tune2fs -m 1 /dev/sdd1
tune2fs 1.46.5 (30-Dec-2021)
Setting reserved blocks percentage to 1% (104855 blocks)
És le is ellenőrizhetjük, hogy megváltozott:
root@server:~# tune2fs -l /dev/sdd1 | grep "Reserved block count"
Reserved block count: 104855
Maximális csatolások száma (Maximum mount count)
A rendszer, amikor felcsatol egy fájlrendszert, automatikusan leellenőrzi. Erre nincsen mindig szükség. A maximum mount count küszöbérték beállításával azt határozhatjuk meg, hogy hány csatolásonként ellenőrizze le a fájlrendszert.
Kérdezzük le az értékét. A -1 azt jelenti, hogy minden csatolásnál történjen ellenőrzés.
root@server:~# tune2fs -l /dev/sdd1 | grep "Maximum mount count"
Maximum mount count: -1
Ha ez túl gyakori lenne, átállíthatjuk a tune2fs paranccsal. Konfiguráljuk úgy, hogy minden 5. csatoláskor ellenőrizzen csak:
root@server:~# tune2fs -c 5 /dev/sdd1
tune2fs 1.46.5 (30-Dec-2021)
Setting maximal mount count to 5
Maximum mount interval
Ha nem a felcsatolások száma szerint akarjuk előírni az ellenőrzéseket, hanem úgy, hogy mennyi időnként történjenek, akkor így járjunk el:
root@server:~# tune2fs -i 10d /dev/sdd1
tune2fs 1.46.5 (30-Dec-2021)
Setting interval between checks to 864000 seconds
Kérdezzük le, sikerült-e a beállítás. (A -1 jelentené, hogy nincsen megadva intervallum.)
root@server:~# tune2fs -l /dev/sdd1 | grep "Check interval"
Check interval: 432000 (5 days)
Ezen felül lekérdezhető még, hogy mikor történt a legutóbbi ellenőrzés, és mikor várható a következő:
root@server:~# tune2fs -l /dev/sdd1 | grep "Last checked"
Last checked: Sun Jul 16 08:48:10 2023
root@server:~# tune2fs -l /dev/sdd1 | grep "Next check"
Next check after: Fri Jul 21 08:48:10 2023
