8.9 Fájlrendszer és lemezkezelés

Az operációs rendszer olyan, mint egy automatizált logisztikai központ, a hardvered (különösen a háttértárad) pedig maga a fizikai raktárépület. Hiába gyors a processzorod és hiába van rengeteg memóriád, ha a raktárad megtelik, megsérül, vagy az operációs rendszer elveszíti a térképét ahhoz, hogy mit hol talál, az egész gépezet azonnal leáll.

Legyen szó egy újonnan épített, vagy használt alkatrészekből összerakott gépről (ahol egy NVMe SSD-t és több hagyományos merevlemezt kell zökkenőmentesen összehangolni), gigászi méretű, helyben futtatott mesterséges intelligencia modellek (például egy Qwen 3.6-os architektúra) fájljainak tárolásáról, vagy egy kiterjedt Steam játékkönyvtár kezeléséről, a lemezkezelés tudománya az egyik legértékesebb rendszergazdai képesség.

Ebben a terjedelmes fejezetben a Linux fájlrendszer-kezelésének legmélyére ásunk. Megtanuljuk felkutatni a rejtett helyrablókat, megértjük a partíciók csatolásának elméletét és gyakorlatát, stabilizáljuk a rendszert az automatikus csatolásokkal, és felkészülünk a legrosszabbra: a sérült fájlrendszerek újraélesztésére.

8.9.1 A tárhely térképe: a Disk Free parancs és az Inode-ok

Amikor a rendszer lassulni kezd, vagy egy letöltés hibaüzenettel megszakad, az első és legfontosabb kérdés: Van egyáltalán elég helyünk? Erre a kérdésre a df (Disk Free) parancs adja meg a választ. A df nem a fájlokat vizsgálja egyesével, hanem magát a fájlrendszert kérdezi le, így az eredmény azonnali.

Ha csak simán beütöd a df parancsot, egy szinte olvashatatlan listát kapsz, ahol a méretek 1 KiloBájtos blokkokban (pl. 24567892) szerepelnek. Ezt a mindennapokban sosem használjuk így. A kötelező kapcsoló a -h (human-readable), amely Gigabájtokban (GB) és Megabájtokban (MB) jeleníti meg az értékeket.

df -h

Tipikus kimenet egy modern Linux rendszeren:

Fájlrendszer   Méret Fogl. Szab. Fo.% Csatol. pont
/dev/sda3       101G   70G   31G  70% /
devtmpfs         40G     0   40G   0% /dev
tmpfs            40G  8,0K   40G   1% /dev/shm
efivarfs        128K   13K  111K  10% /sys/firmware/efi/efivars
tmpfs            16G  2,1M   16G   1% /run
tmpfs           1,0M     0  1,0M   0% /run/credentials/systemd-journald.service
/dev/nvme0n1p1  1,9T  506G  1,4T  28% /mnt/gaming
/dev/sda3       101G   70G   31G  70% /home
tmpfs            40G  964K   40G   1% /tmp
/dev/sda2       2,0G  748M  1,1G  41% /boot
/dev/sda1       599M   20M  580M   4% /boot/efi
tmpfs           1,0M     0  1,0M   0% /run/credentials/systemd-resolved.service
tmpfs           7,9G  206M  7,7G   3% /run/user/1000
/dev/sdb1       1,9T  891G  972G  48% /mnt/crucial
tmpfs           1,0M     0  1,0M   0% /run/credentials/getty@tty4.service
tmpfs           1,0M     0  1,0M   0% /run/credentials/getty@tty6.service
tmpfs           7,9G   60K  7,9G   1% /run/user/0

Mit látunk itt?

Fájlrendszer: A fizikai partíció (pl. /dev/nvme0n1p1) vagy a memóriába töltött virtuális fájlrendszer (pl. tmpfs) neve.
Méret / Fogl / Szab.: Teljes méret, foglalt terület, és a még szabadon felhasználható terület.
Fo%: Százalékos telítettség. 90% felett érdemes elkezdeni a takarítást, 98% felett a Linux grafikus felülete már instabillá válhat.
Csatol. pont: Megmutatja, hogy a fájlrendszer faszerkezete hol kapcsolódik be az operációs rendszer mappastruktúrájába. (Például a 2 terabájtos SDD a /mnt/gaming mappaként érhető el).

Gyakran érdemes kiegészíteni a parancsot a -T kapcsolóval, ami egy új oszlopot ad a kimenethez: a fájlrendszer típusát (pl. ext4, btrfs, vfat, tmpfs).

df -hT

Fantomtelítettség: Amikor van hely, de mégsincs

Létezik egy alattomos hiba, amivel haladó rendszergazdák és webfejlesztők gyakran találkoznak, de a kezdőket az őrületbe kergeti. Képzeld el a következő szituációt: A szerver hibát dob: "No space left on device" (Nincs több hely az eszközön). Lefuttatod a df -h parancsot, és azt látod, hogy a 100 GB-os lemezből még 40 GB teljesen üres. Hogyan lehetséges ez?

A válasz az Inode-okban (Index Node) rejlik. A Linux fájlrendszere (például az ext4) két részből áll: az adatblokkokból (ahol maguk a fájlok bájtjai vannak), és az inode-táblából. Minden egyes fájlhoz (legyen az egy 50 GB-os videó vagy egy 1 bájtos szövegfájl) tartozik pontosan egy darab Inode. Ez a "címke" tartalmazza a fájl metaadatait: ki a tulajdonos, mik a jogosultságok, és fizikailag hol található a lemezen.

A probléma az, hogy a fájlrendszer formázásakor az Inode-ok száma fix. Képzelj el egy gigantikus nagykereskedelmi raktárt, amely kizárólag apró karkötők millióit tárolja. Hiába van még rengeteg légköbméter (szabad Gigabájt) a raktárban, ha a raklapokhoz és dobozokhoz kiadható azonosító vonalkódok (Inode-ok) elfogynak, egyetlen újabb apró porcelánt sem tudsz raktárra venni!

Ez a hiba tipikusan olyan rendszereken fordul elő, amelyek milliószámra generálnak apró fájlokat (például webáruházak PHP session fájljai, óriási node_modules mappák egyedi JavaScript projekteknél, vagy apró gyorsítótár-fájlok).

Ennek ellenőrzésére használd a -i kapcsolót:

df -i

:~$ df -ihT
Fájlrendszer   Típ.     Inode-ok IFogl ISzab. IFo.% Csatol. pont
/dev/sda3      btrfs           0     0      0     - /
devtmpfs       devtmpfs     9,8M   862   9,8M    1% /dev
tmpfs          tmpfs        9,9M     3   9,9M    1% /dev/shm
efivarfs       efivarfs        0     0      0     - /sys/firmware/efi/efivars

Ha az IFo% (Inode foglalási százalék) oszlopban 100%-ot látsz, miközben Gigabájtok vannak szabadon, meg is találtad a hibát. Ilyenkor a rengeteg apró fájlt tartalmazó könyvtárakat kell felkutatni és törölni.

8.9.2 A helyrablók felkutatása: a Disk Usage parancs

Míg a df megmondja, mennyi helyed van összesen, a du (Disk Usage) megmondja, mi foglalja el azt. A du úgy működik, hogy bemászik az általad megadott mappába, és rekurzívan (mappáról mappára haladva) összeadja minden egyes fájl méretét. Mivel ehhez aktívan olvasnia kell a lemezt, nagy mappák (pl. a teljes / gyökérkönyvtár) elemzése másodpercekbe vagy percekbe is telhet.

Alapvető mappaméret lekérdezés

Ha egy adott mappa méretére vagy kíváncsi emberi nyelven olvasható formában (itt is -h), kiegészítve a -s (summarize - összegzés) kapcsolóval, ami megakadályozza, hogy a parancs a mappa több tízezer belső fájlját is kilistázza a képernyőre, csak a végeredményt adja vissza:

du -sh /var/log/

Kimenet: 4.2G /var/log/

A lemez porszívózása: Mi foglalja a legtöbb helyet?

Amikor elfogy a hely, meg kell találnunk a legnagyobb kiterjedésű fájlokat vagy mappákat. A rendszergazdák leggyakoribb kombója a du és a sort (rendező) parancs összekapcsolása (|).

Tegyük fel, hogy a saját felhasználói mappádat (~/) akarod analizálni. Kíváncsi vagy a benne lévő összes főkönyvtár méretére, csökkenő sorrendben.

A -d 1 (depth 1) kapcsoló megmondja a du-nak, hogy csak az első szintű mappákat összegezze (ne menjen bele a mappák mappáiba a listázáskor), a kimenetet pedig átadjuk a sort -rh parancsnak, ami csökkenő (reverse) és emberileg olvasható (human) módon rendezi a számokat.

du -h -d 1 ~/ | sort -rh | head -n 10

Példa kimenet egy aktív Power User gépén:

380G    /home/laszlo/
210G    /home/laszlo/.local/share/Steam
95G     /home/laszlo/LLM_Models
50G     /home/laszlo/Letöltések
45G     /home/laszlo/Dokumentumok
12G     /home/laszlo/.cache
1.5G    /home/laszlo/Projektek
...

Ebből azonnal látszik, hol kell takarítani. Ha belépsz az LLM_Models mappába, és újra lefuttatod a keresést sima fájlokra is kiterjesztve (du -sh * | sort -rh), pillanatok alatt megtalálod azokat az 50-60 Gigabájtos .gguf kiterjesztésű mesterséges intelligencia modelleket vagy régi virtuális gépeket, amiket már hónapok óta nem használtál, és bátran törölhetsz.

Tipp az Engedély Megtagadva (Permission Denied) hibákhoz: > Amikor a teljes / (gyökér) meghajtón keresel helyrablókat, a rendszer tucatnyi hibaüzenetet fog dobni, mert normál felhasználóként nem olvashatod a rendszermappákat. Vagy használd a sudo-t a parancs előtt, vagy irányítsd át a hibaüzeneteket a semmibe a 2>/dev/null varázsigével: du -h -d 1 / 2>/dev/null | sort -rh | head -n 10

Pro tipp: Ha grafikus felületen dolgozol, a Filelight nevű alkalmazás kényelmesebben listázza ki a könyvtáraid helyfoglalását. Ezt a legtöbb disztró alapban tartalmazza, vagy ha nem találod, telepítsd Flatpakból.

8.9.3 Lemezek és Partíciók felépítése Linuxban

Mielőtt továbblépnénk a csatolások (mountolás) világába, tisztáznunk kell, hogyan is nevezi a Linux a hardvereket. A Linux filozófiája szerint "minden fájl". A merevlemezek, az SSD-k, és még az USB pendrive-ok is egyszerű fájlokként jelennek meg a /dev (devices) könyvtárban.

Az azonosításuk megértéséhez az lsblk (List Block Devices) parancs a legjobb barátod. Ez kilistázza a gépbe dugott összes adathordozót, fastruktúrában megmutatva a partícióikat.

lsblk

:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 111,8G  0 disk 
├─sda1        8:1    0   600M  0 part /boot/efi
├─sda2        8:2    0     2G  0 part /boot
├─sda3        8:3    0 100,4G  0 part /home
│                                     /
└─sda4        8:4    0   8,8G  0 part [SWAP]
sdb           8:16   0   1,8T  0 disk 
└─sdb1        8:17   0   1,8T  0 part /mnt/crucial
sr0          11:0    1  1024M  0 rom  
zram0       253:0    0     8G  0 disk [SWAP]
nvme0n1     259:0    0   1,8T  0 disk 
├─nvme0n1p1 259:1    0   1,8T  0 part /mnt/gaming
└─nvme0n1p2 259:2    0   8,8G  0 part

Az elnevezési konvenciók 2026-ban:

SATA meghajtók (hagyományos HDD-k vagy 2.5" SSD-k): sda, sdb, sdc. A meghajtón lévő partíciókat számok jelölik: /dev/sda1, /dev/sda2. (Például az sdb1 a második SATA kábelre kötött lemez első partíciója).
NVMe meghajtók (M.2 PCIe SSD-k): Mivel ezek közvetlenül a PCIe buszra csatlakoznak, saját névterük van: nvme0n1, nvme1n1. A partícióikat egy p betű és egy szám jelöli: /dev/nvme0n1p1, /dev/nvme0n1p2.
USB pendrive-ok: Általában a SATA meghajtók sémáját követik, így a rendszerbe dugva a legközelebbi szabad sd* betűt kapják (pl. /dev/sdc).
MicroSD kártyák (pl. Steam Deckben): Gyakran az mmcblk0 nevet kapják, a partíciójuk pedig az mmcblk0p1.

Ha látsz egy eszközt a lsblk kimenetében, az azt jelenti, hogy a Linux magja (a kernel) elektronikusan felismerte a hardvert. Ahhoz azonban, hogy bele is tudj lépni és fájlokat tudj rá másolni, csatolnod kell.

8.9.4 Csatolás és leválasztás: `mount` és `umount`

A Windows operációs rendszerhez szokott felhasználóknak a "C: meghajtó" és "D: meghajtó" koncepciója a természetes. A Linux (és minden UNIX alapú rendszer) azonban nem használ betűjeleket.

A Linux egyetlen, gigantikus, egységes hierarchikus fát épít fel, amely a / (gyökér vagy root) könyvtárból indul ki. Bármilyen új fizikai eszközt (egy 4 terabájtos vadiúj HDD-t, egy hálózati meghajtót, vagy egy ISO képfájlt) be lehet illeszteni – szaknyelven csatolni (mountolni) – ennek a fának bármelyik ágára, egy teljesen hétköznapi, üres mappába. Ezt az üres mappát csatolási pontnak (mount point) nevezzük.

Egy partíció kézi csatolása

Tegyük fel, hogy betettél a gépbe egy új SSD-t, amit az lsblk alapján a rendszer /dev/sdb1-ként ismert fel. Szeretnéd ezt az adattárat elérni.

1. Hozzunk létre egy csatolási pontot (egy üres mappát): Ez tipikusan a /mnt vagy a /media mappák alatt történik, de akár a saját letöltések mappádban is csinálhatsz egyet.

sudo mkdir -p /mnt/Uj_Adattar

2. Adjuk ki a mount parancsot: A szintaxis egyszerű: mount [forrás_eszköz] [cél_mappa]. (Mivel hardverhez nyúlunk, kötelező a sudo).

sudo mount /dev/sdb1 /mnt/Uj_Adattar

Kész. Ha most kiadod az ls /mnt/Uj_Adattar parancsot, már az új merevlemezed fájljait látod. Bármit, amit ebbe a mappába másolsz, fizikailag az sdb lemezre fog kerülni. A mount parancs elképesztően intelligens: az esetek 99%-ában automatikusan felismeri a fájlrendszert (legyen az ext4, btrfs, ntfs, vagy vfat).

Ha valamiért mégis manuálisan kell megadnod a fájlrendszer típusát (például egy régi FAT32-es pendrive esetén), a -t (type) kapcsolót használhatod:

sudo mount -t vfat /dev/sdc1 /mnt/Pendrive

ISO képfájlok csatolása ("virtuális CD/DVD")

A mount nem csak fizikai hardverekkel, hanem fájlokkal is működik. Ha letöltöttél egy Linux disztribúciót, vagy egy régi játék CD-jének ISO képfájlját, egy speciális loop eszközként pillanatok alatt olvashatóvá teheted a tartalmát, mintha csak beletetted volna egy fizikai olvasóba:

sudo mount -o loop ~/Letöltések/linux_telepito.iso /mnt/Iso_Olvaso

A lemez biztonságos leválasztása: `umount`

Mielőtt kihúznál egy USB meghajtót, vagy kivennél egy lemezt, kötelező leválasztani azt az operációs rendszerről, hogy a memóriában lévő, még ki nem írt fájl-töredékek (cache) biztonságosan felkerüljenek a lemezre. Erre szolgál az umount parancs.

Megadhatod neki magát az eszközt, vagy a csatolási pontot is:

sudo umount /mnt/Uj_Adattar

vagy

sudo umount /dev/sdb1

A leggyakoribb rémálom: "Target is busy" (A célpont foglalt)

Mindenki találkozott már azzal, amikor az operációs rendszer megtagadja az USB meghajtó vagy a merevlemez kiadását, arra hivatkozva, hogy az eszköz foglalt (umount: /mnt/Uj_Adattar: target is busy).

Ezt az okozza, hogy egy program (vagy te magad) a háttérben még aktívan használja a lemezt. Lehet, hogy nyitva hagytál egy terminált, ahol épp abban a mappában tartózkodsz, vagy egy háttérben futó indexelő szolgáltatás olvas egy fájlt.

Ilyenkor soha ne rántsd ki az eszközt! Két professzionális parancs is a rendelkezésedre áll, hogy kiderítsd, ki tartja túszul a lemezt:

lsof +D [mappa] (List Open Files): Kilistázza az összes olyan folyamatot, ami a megadott mappán belül fájlt tart nyitva.

sudo lsof +D /mnt/Uj_Adattar

Kimenet: Látni fogod, hogy például a bash (terminál) vagy egy qemu folyamat használja. A kapott PID (Process ID) alapján kilőheted a programot a kill -9 PID paranccsal.

A "Lusta" leválasztás (Lazy Unmount): Ha a rendszered lefagyott egy haldokló hálózati meghajtó (NFS) vagy egy hibás USB miatt, és az umount parancs is befagy, alkalmazhatod a -l (lazy) kapcsolót.

sudo umount -l /mnt/Akadozo_Halozat

Ez azonnal, erővel eltávolítja a csatolási pontot a mappafából, így a grafikus felületed és a programjaid fellélegeznek, magát a fizikai leválasztást pedig a kernel a háttérben, szépen lassan fejezi be, amint az erőforrások felszabadulnak.

8.9.5 Állandóság biztosítása: Az `/etc/fstab` rejtelmei

A mount paranccsal végzett csatolások ideiglenesek. Ha újraindítod a számítógéped, minden eltűnik, és az operációs rendszer kizárólag azt az egyetlen / (root) partíciót fogja automatikusan csatolni, amin maga a rendszer csücsül.

Ha te a vadiúj, játékokra és az AI fájlokra dedikált 2 TB-os NVMe meghajtódat állandóan, minden bootoláskor elérhetővé akarod tenni mondjuk a /mnt/gaming könyvtárban, akkor meg kell ismerkedned a Linux fájlrendszer-kezelésének Szent Gráljával: az /etc/fstab (File System Table) konfigurációs fájllal.

Rendszergazdai figyelmeztetés! Kérlek, figyelj oda! Az /etc/fstab a rendszer legkritikusabb fájlja. Ha elgépelsz benne egy karaktert, vagy egy nem létező lemezt kötelezőként írsz bele, a Linux nem fog tudni elindulni. Betöltés közben egy kernel panic-kal, vagy a hírhedt Emergency Mode (vészhelyzeti mód) termináljával fogad majd. Mielőtt bármit módosítasz benne, készíts róla egy biztonsági másolatot! sudo cp /etc/fstab /etc/fstab.backup

Fizikai nevek (sda1) helyett a UUID azonosítók

Az előző alfejezetben /dev/sdb1-ként hivatkoztunk a lemezre. Ezt soha, soha nem szabad beírni az fstab fájlba. Miért? Mert a Linux a hardverek indítási sorrendje alapján osztja ki az sda, sdb neveket. Ha holnap bedugsz egy új USB lemezt, vagy átdugod a SATA kábelt egy másik portba, az eddigi sdb1 hirtelen sdc1 lehet. A rendszer megpróbálja csatolni a régit, nem találja, és összeomlik.

A megoldás az UUID (Universally Unique Identifier), egy hosszú, véletlenszerű betű- és számsor, amit a partíció a formázásakor kap, és a lemez élete végéig, fizikai portoktól függetlenül rögzítve marad.

A lemezeid UUID-ját a blkid (Block ID) paranccsal tudod lekérdezni:

sudo blkid

Kimenet: /dev/nvme0n1p2: UUID="f3a5-b21a-4c8d-99f1-a1b2c3d4e5f6" BLOCK_SIZE="4096" TYPE="ext4"

Ezt a hosszú f3a5... kódot kell majd használnunk.

Az fstab felépítése: A 6 oszlop titka

Nyisd meg a fájlt szerkesztésre: sudo nano /etc/fstab. A fájlban soronként egy-egy csatolás szerepel, pontosan hat darab szóközökkel vagy tabulátorokkal elválasztott oszlopra bontva.

Lássuk, hogyan néz ki egy tökéletes sor a mi 2 TB-os belső NVMe játéktárolónk automatikus csatolásához:

# 1. oszlop               2. oszlop       3. oszlop   4. oszlop      5. oszlop   6. oszlop
UUID=f3a5-b21a-...        /mnt/gaming     ext4        defaults,noatime    0           2

Mit jelentenek az oszlopok?

Fájlrendszer (Kijelölés): Az eszköz azonosítója, kötelezően UUID=xxxx formátumban.
Csatolási pont: A könyvtár abszolút elérési útja (pl. /mnt/gaming). A mappának már léteznie kell a valóságban!
Fájlrendszer típusa: pl. ext4, btrfs, vfat, ntfs-3g.
Csatolási opciók: Ez a rész szabályozza, hogy a lemez írható-e, ki mountolhatja, stb. (Lásd lentebb).
Dump (Archiválás): Egy elavult biztonsági mentési programhoz tartozó jelző. A modern rendszereken ennek az értéke mindig 0.
Pass (fsck ellenőrzési sorrend): Megmondja, hogy bootoláskor a lemezellenőrző program milyen sorrendben vizsgálja át a meghajtót hiba után. A / (root) partíció mindig 1. Minden egyéb belső adatlemez 2. (A külső, vagy nem ext4/btrfs alapú hálózati lemezek, NTFS partíciók esetén legyen 0, hogy ne akadjon meg rajtuk a rendszer).

A leghasznosabb csatolási opciók (4. oszlop)

Az opciók határozzák meg a lemez teljesítményét és biztonságát. A legegyszerűbb beírni a defaults (alapértelmezések) szót, amely magában foglalja az olvasási-írási jogot (rw), és azt, hogy automatikusan mountolódjon bootkor. Azonban egy professzionális Power User (mint te) tovább hangolja a rendszert:

noatime (No Access Time): Ez az SSD-k (mind a SATA, mind az NVMe) élettartamának meghosszabbításának egyik legjobb eszköze. Alapértelmezés szerint a Linux minden egyes alkalommal, amikor csak megnyitsz egy fájlt olvasásra (például egy játék betöltésekor több ezer textúrafájlt), felírja a lemezre a pontos dátumot, hogy "utoljára olvasva ekkor". Ez napi több százezer felesleges írási műveletet jelent. A noatime ezt az időbélyeg-frissítést teljesen kikapcsolja, brutálisan felgyorsítva az IO (Input/Output) műveleteket és óvva a cellákat.
nofail (Életmentő kapcsoló): Ha egy olyan másodlagos belső merevlemezt, vagy egy fixen rádugott USB lemezt adsz hozzá az fstab-hoz, ami esetleg elromolhat, vagy néha ki van húzva, kötelező a nofail opció használata. Ha ez nincs ott, és a lemez valamiért nem elérhető bekapcsoláskor, a Linux kernel pánikba esik és megállíti a boot folyamatot! A nofail annyit tesz: "Próbáld meg csatolni. Ha nincs ott, sebaj, menj tovább, és indítsd el az operációs rendszert a fő meghajtóról."
ro (Read-Only): Csak olvasható módban csatolja a lemezt. Ideális fontos biztonsági archívumok védelmére.
discard=async (BTRFS esetén): Ha BTRFS fájlrendszert használsz (lásd 8.5-ös fejezet), ez az opció automatikusan és aszinkron módon végzi el a TRIM műveleteket az SSD-n, folyamatosan magasan tartva az írási sebességet.

Ha szerkesztetted és elmentetted az /etc/fstab fájlt, soha ne indítsd újra a gépet anélkül, hogy tesztelnéd! A teszteléshez add ki ezt a parancsot:

sudo mount -a

A mount -a utasítja a rendszert, hogy olvassa be az fstab fájlt, és csatoljon fel mindent, ami még nincs csatolva. Ha ez a parancs hibát dob a képernyőre, akkor elrontottál egy szintaxist. Menj vissza, és javítsd ki, mert ha újraindítod a gépet a hibával, nem fog elindulni a rendszer. Ha a mount -a szó nélkül (üres kimenettel) lefut, az fstab fájlod tökéletes, a következő újraindítás zökkenőmentes lesz.

8.9.6 Fájlrendszerek karbantartása és javítása: az fsck

A modern fájlrendszerek (mint az ext4) úgynevezett naplózó (journaling) fájlrendszerek. Ez azt jelenti, hogy mielőtt egy adatot fizikailag kiírnának a lemezre, feljegyzik a szándékot egy átmeneti naplóba. Ha áramszünet vagy egy fagyás miatt (például túlhúztad a Ryzen processzorodat) a gép váratlanul leáll, a következő újraindításkor a rendszer a napló alapján másodpercek alatt helyre tudja állítani a félbemaradt műveleteket.

Azonban vannak olyan hardveres hibák (hibás memóriamodul, elöregedő SSD kontroller, hibás szektorok egy régi HDD-n), amelyek fizikai meghibásodást okoznak a fájlrendszer struktúrájában. Ilyenkor a rendszer lezárja a lemezt (Read-Only módba teszi az adataid védelme érdekében), vagy a gép el sem indul.

Ekkor jön a képbe az fsck (File System Consistency Check - Fájlrendszer konzisztencia ellenőrző). Az fsck a lemez orvosa. Végigpásztázza az inode-táblákat, a blokkokat és a mappastruktúrát, megkeresi a szakadásokat, és (ha kéred) kijavítja őket.

A LEGFONTOSABB SZABÁLY: Soha ne futtass `fsck`-t felcsatolt fájlrendszeren!

Ha egy fájlrendszer él (csatolva van és a rendszer ír/olvas rajta), és te közben elindítasz egy fsck javítást, a program a te szemed láttára fogja szó szerint megsemmisíteni az adataidat, mivel az olvasás és a javítás aszinkron módon, egymásra írva történik.

Az fsck-t kizárólag leválasztott (unmounted) partíciókon szabad futtatni!

Kézi ellenőrzés (ext4 és hagyományos rendszerek)

Tegyük fel, hogy a /dev/sdb1 játékmeghajtód furcsa hibaüzeneteket dob olvasáskor.

Első lépés a leválasztás:

sudo umount /dev/sdb1

Az fsck futtatása. A -p (preen - automatikus javítás) kapcsoló a biztonságos, kisebb hibákat emberi beavatkozás nélkül kijavítja. A -f (force) kapcsoló akkor is kikényszeríti a mélyvizsgálatot, ha a napló szerint a lemez tiszta.

sudo fsck -pf /dev/sdb1

Ha komoly a baj, és ezernyi hibát talál, a rendszer minden egyes törött szektornál meg fogja kérdezni, hogy kijavítsa-e (Y/N). Ezt átugorhatod a -y (yes to all) kapcsolóval, ami mindenre igent mond (vigyázat, ez agresszív javítás, menthetetlenül eltávolíthat sérült fájlokat, de a fájlrendszer struktúráját helyreállítja): sudo fsck -y /dev/sdb1

A javítás után a elveszettnek hitt, de megmentett fájltöredékeket az fsck a meghajtó gyökerében lévő lost+found (elveszett és megtalált) rejtett mappába dobálja be.

Hogyan javítsuk meg a fő / (root) partíciót?

Mivel a gyökérpartíciót (/) soha nem lehet menet közben leválasztani (hiszen az maga az operációs rendszer), két módja van a javításának:

A Live USB módszer: Ez a legtisztább. Bebootolsz egy Ubuntu vagy Nobara pendrive-ról, kinyitod a terminált a Live környezetben, és mivel ott a te eredeti belső SSD-d még nincs felcsatolva, nyugodtan ráküldheted az fsck-t a /dev/nvme0n1p3 (vagy megfelelő) partíciódra.
Kikényszerítés bootoláskor: Régebbi Linuxokon elég volt kiadni a sudo touch /forcefsck parancsot. Modern systemd rendszereken a legegyszerűbb, ha a GRUB menüben a kernel paraméterek végére (ahol a quiet splash van) beírod a fsck.mode=force parancsot. Ekkor a következő bootoláskor a kernel azelőtt átvizsgálja a gyökérpartíciót, mielőtt teljesen felcsatolná írásra.

Kivétel a szabály alól: A BTRFS és a Scrub

Ha visszagondolsz a 8.5-ös fejezetre, ott BTRFS rendszert használtunk. Fontos tudni, hogy a BTRFS tervezése radikálisan eltér az ext4-től. BTRFS fájlrendszeren SOHA ne futtass hagyományos fsck javítást! (A rendszer eleve le fogja tiltani).

A BTRFS menet közben (online, csatolt állapotban!) végzi a hibajavítást egy scrub nevű művelettel. Mivel a BTRFS adatblokkjai és metaadatai folyamatos CRC32-es ellenőrzőösszeggel (checksum) vannak ellátva, a rendszer élőben tudja olvasni és javítani magát (különösen RAID konfigurációkban). Egy élő BTRFS meghajtó ellenőrzését és javítását menet közben indíthatod el:

sudo btrfs scrub start /

Az állapotát pedig a sudo btrfs scrub status / paranccsal követheted nyomon.

8.9.7 Haladó lemezkezelési tippek

A fejezet zárásaként nézzünk meg két olyan haladó koncepciót, amelyekkel az igazi profik teszik teljessé a hardver feletti uralmat.

1. A ritka fájlok (Sparse files) anomáliája

A ls -lh és a du -sh parancsok néha teljesen más méretet mutatnak ugyanarra a fájlra. Ez akkor fordul elő, ha egy virtuális gép (pl. KVM/QEMU) lemezképét, vagy egy hatalmas előre allokált adatbázis-fájlt vizsgálsz.

Ezek az úgynevezett ritka fájlok (sparse files). Létrehozhatsz egy 100 GB-os fájlt a rendszerben, ami az ls kimenetében 100 GB-nak látszik, de ha belül csak üres, nulla bájtokkal (zeroes) van tele, a fájlrendszer elég okos ahhoz, hogy ezt a valóságban ne írja ki a lemezre. A du -sh parancs ekkor a valódi fizikai helyfoglalást fogja mutatni (ami lehet, hogy csak 1 MB). Ezt mindig tartsd észben, ha hatalmas logfájlokkal vagy lemezképekkel zsonglőrködsz!

2. Egészségügyi diagnosztika: A S.M.A.R.T. rendszer

A fájlrendszer-ellenőrzés (fsck) csak a szoftveres logikát javítja. Nem tudja megjavítani a fizikailag elfüstölő SSD vezérlőt vagy a karcosodó HDD lemeztányért. A fizikai hardver állapotának ellenőrzésére a smartmontools csomagba tartozó smartctl eszközt kell használnod.

Bármelyik modern háttértár rendelkezik beépített ön-diagnosztikával. Ennek az egészségügyi jelentésnek a lekérdezése így történik:

sudo smartctl -a /dev/nvme0n1

A kimenet hosszú lesz, de NVMe meghajtóknál keresd az "Available Spare" (Még rendelkezésre álló tartalék cellák százaléka) és a "Percentage Used" (Elhasznált élettartam) sorokat. Hagyományos HDD-k esetén a "Reallocated Sector Count" (Újraallokált, azaz hibás és kizárt szektorok száma) értéke, ha elindul felfelé a nulláról, azt jelenti, hogy a lemez napjai meg vannak számlálva, és a fájlrendszer-ellenőrzések egyre gyakoribbá fognak válni.

‹ Előző Következő ›