Időnként, a CRS-be való költözés céljából különböző nagy cégeknél, főként Szentpéterváron és Moszkvában DevOps pozícióra interjút adok. Észrevettem, hogy sok cégnél (sok jó cégnél, például a Yandexnél) két hasonló kérdést tesznek fel:
- mi az az inode;
- milyen okok miatt lehet írási hiba a lemezen (vagy például: miért fogyhat el a lemezhely, lényegében ugyanaz).
Mint ahogy lenni szokott, biztos voltam benne, hogy ezt a témát jól ismerem, de amint elkezdtem magyarázni – tudásbeli hiányosságok mutatkoztak meg. Hogy rendszerezni tudjam a tudásomat, kitölteni a hiányosságokat, és hogy többé ne érezzem magam cikinek, írom ezt a cikket, hátha másnak is hasznára válik.
A "legalulról" kezdem, azaz a merevlemeznél (a pendrive-okat, SSD-ket és egyéb modern dolgokat most elhagyjuk, vegyünk például egy 20 vagy 80 gigás régi lemezt, mivel ott a blokk mérete 512 bájt).
A merevlemez nem tudja byte-onként címezni a területét, lényegében blokkokra van felosztva. A blokkok számozása a 0-val kezdődik. (ezt LBA-nak hívják, részletek itt: )
Ahogy a rajzon látható, az LBA blokkokat HDD szintként jelöltem meg. Egyébként meg lehet nézni, hogy a lemezének mekkora a blokk mérete így:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Egy szinttel fejjebb a partíció van megjelölve, ami egy az egész lemezen (ismét a egyszerűség kedvéért). A partíciók két típusa szokott gyakran előfordulni: msdos és gpt. Az msdos tehát a régi formátum, amely 2Tb-ig támogathat lemezeket, a gpt pedig az új formátum, amely akár 1 zettabájt 512 bájt méretű blokkot is címezni tud. Jelen esetben msdos típusú partíciónk van, ahogyan a rajzon is látszik, a partíció a 1-es blokktól kezdődik, a 0-ás pedig az MBR számára van fenntartva.
Az első partíción létrehoztam egy ext2 fájlrendszert, amelynek alapértelmezett blokk mérete 4096 bájt, amit a rajz is tükröz. A fájlrendszer blokk méretét így lehet megnézni:
root@ubuntu: /home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (2014. február 4.)
Filesystem volume name:
Last mounted on:
Filesystem UUID: a600bf40-f660-41f6-a3e6-96c303995479
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536
Block count: 261888
Reserved block count: 13094
Free blocks: 257445
Free inodes: 65525
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 63
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: 2019. augusztus 2. 15:02:13
Last mount time: n/a
Last write time: 2019. augusztus 2. 15:02:14
Mount count: 0
Maximum mount count: -1
Last checked: 2019. augusztus 2. 15:02:13
Check interval: 0 ()
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: half_md4
Directory Hash Seed: c0155456-ad7d-421f-afd1-c898746ccd76A szükséges paraméter a „Block size”.
Most jön a legérdekesebb rész: hogyan olvassuk el a fájlt /home/serp/testfile? A fájl egy vagy több fájlrendszer blokkot tartalmaz, amelyek a benne található adatokat tárolják. A fájl neve alapján hogyan találjuk meg? Mely blokkokat olvassuk?
Itt jönnek jól a inode-ok. Az ext2fs fájlrendszerben van egy „tábla”, amely az összes inode információit tartalmazza. Az inode-ok száma az ext2fs fájlrendszer létrehozásakor van meghatározva. A szükséges számokat a tune2fs kimenetének „Inode count” paraméterében látjuk, tehát 65536 darabot van. Az inode-ok tartalmazzák a szükséges információt: a keresett fájlhoz tartozó fájlrendszer blokkok listáját. Hogyan találjuk meg a megadott fájlhoz tartozó inode számot?
A név és az inode számának megfeleltetése a könyvtárban található, és a könyvtár az ext2fs-ben egy különleges típusú fájl, amelynek szintén van saját inode száma. Hogy megtörjük ezt a ördögi kört, a gyökérkönyvtárnak fixált inode számot, a „2”-t rendelték hozzá. Nézzük meg a 2-es számú inode tartalmát:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (2014. február 4.)
debugfs: stat
Inode: 2 Type: directory Mode: 0755 Flags: 0x0
Generation: 0 Version: 0x00000000:00000002
User: 0 Group: 0 Size: 4096
File ACL: 0 Directory ACL: 0
Links: 3 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5d43cb51:16b61bcc -- 2019. augusztus 2. 16:34:09
atime: 0x5d43c247:b704301c -- 2019. augusztus 2. 15:55:35
mtime: 0x5d43cb51:16b61bcc -- 2019. augusztus 2. 16:34:09
crtime: 0x5d43b5c6:00000000 -- 2019. augusztus 2. 15:02:14
Size of extra inode fields: 28
BLOCKS:
(0):579
TOTAL: 1Ahogy látható, a szükséges könyvtár a 579-es számú blokkban található. Itt megtaláljuk a home mappa node számát, és így tovább a láncon, amíg a serp könyvtárban meg nem látjuk a kért fájl node számát. Ha valakinek ellenőrizni szeretné, hogy a szám helyes-e, és van-e ott szükséges információ, ez nem bonyolult. Csináljunk:
root@ubuntu:/$ dd if=/dev/sdb1 of=/home/serp/dd_image bs=4096 count=1 skip=579
1+0 records in
1+0 records out
4096 bytes (4,1 kB) copied, 0,000184088 s, 22,3 MB/s
root@ubuntu:/$ hexdump -c /home/serp/dd_imageA kimenetből olvashatók a könyvtárban található fájlok nevei.
Tehát eljöttem a fő kérdéshez: "milyen okok miatt fordulhat elő írási hiba"?
Természetesen ez akkor fog megtörténni, ha nem marad szabad blokk a fájlrendszerben. Mit lehet tenni ilyen esetben? A nyilvánvalón kívül, miszerint "töröljünk valami feleslegeset", érdemes megjegyezni, hogy az ext2,3 és 4 fájlrendszerekben létezik egy úgynevezett "Reserved block count". Ha megnézzük a fenti listázást, akkor nekünk ilyen blokkokból "13094" van. Ezek a blokkok csak a root felhasználó számára elérhetők írásra. De ha sürgősen meg kell oldani a problémát, mint ideiglenes megoldás, elérhetővé tehetjük őket mindenki számára, aminek következtében kicsit több szabad hely keletkezik:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (2014. február 4.)
A fenntartott blokkok százalékát 0%-ra (0 blokk) állítottam.Tehát alapértelmezés szerint az Ön számára nem elérhető írásra a lemezterület 5%-a, és figyelembe véve a modern lemezek méretét, ez számos gigabájt is lehet.
Mi más lehet még? Egy másik lehetséges helyzet, amikor vannak szabad blokkok, de a node-ok elfogytak. Ez általában akkor fordul elő, ha rengeteg fájl található a fájlrendszerben, amelyek mérete kisebb, mint a fájlrendszer blokk mérete. Figyelembe véve, hogy 1 fájl vagy könyvtár 1 inode-ot igényel, és összesen (e fájlrendszer számára) 65536 van — ez a helyzet több mint reális. Ezt a df parancs kimenetéből is szemléletesen láthatjuk:
serp@ubuntu:~$ df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 493K 480 492K 1% /dev
tmpfs 493K 425 493K 1% /run
/dev/xvda1 512K 240K 273K 47% /
none 493K 2 493K 1% /sys/fs/cgroup
none 493K 2 493K 1% /run/lock
none 493K 1 493K 1% /run/shm
none 493K 2 493K 1% /run/user
/dev/xvdc1 320K 4,1K 316K 2% /var
/dev/xvdb1 64K 195 64K 1% /home
/dev/xvdh1 4,0M 3,1M 940K 78% /var/www
serp@ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 2,0G 4,0K 2,0G 1% /dev
tmpfs 395M 620K 394M 1% /run
/dev/xvda1 7,8G 2,9G 4,6G 39% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 2,0G 0 2,0G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/xvdc1 4,8G 2,6G 2,0G 57% /var
/dev/xvdb1 990M 4,0M 919M 1% /home
/dev/xvdh1 63G 35G 25G 59% /var/wwwAhogyan jól látható a /var/www partíción, a fájlrendszer szabad blokkjainak és inode-jainek száma jelentősen eltér.
Ha véget ér az inode, nem tudok tippeket adni, mert nincs (ha tévedek, szóljanak). Tehát az olyan partíciók esetén, ahol apró fájlok keletkeznek, érdemes megfelelő fájlrendszert választani. Például a btrfs inode-ok nem fogynak el, mert szükség esetén dinamikusan újakat hoznak létre.
Forrás: habr.com
