Annak érdekében, hogy a Központi Elosztó Központba kerüljek, rendszeres időközönként interjúkat készítek különböző nagyvállalatoknál, főleg Szentpéterváron és Moszkvában, egy DevOps pozícióra. Észrevettem, hogy sok cég (sok jó cég, például a Yandex) két hasonló kérdést tesz fel:
- mi az inode;
- milyen okok miatt kaphat lemezírási hibát (vagy pl.: miért fogyhat el a lemezterület, a lényeg ugyanaz).
Ahogy az lenni szokott, biztos voltam benne, hogy jól ismerem ezt a témát, de amint elkezdtem magyarázni, nyilvánvalóvá váltak az ismeretek hiányosságai. Tudásom rendszerezésére, hiánypótlásra, és többé ne szégyelljem magam, írom ezt a cikket, hátha másnak is hasznos lesz.
Kezdem alulról, pl. merevlemezről (eldobjuk a pendrive-okat, SSD-ket és egyéb modern dolgokat; például vegyünk egy tetszőleges 20 vagy 80 giga régi meghajtót, hiszen ott 512 bájt a blokkméret).
A merevlemez nem tudja, hogyan kell bájtonként megcímezni a terét, feltételesen blokkokra van osztva. A blokkszámozás 0-tól kezdődik. (Ezt LBA-nak hívják, részletek itt: )
Amint az ábrán látható, az LBA blokkokat jelöltem meg HDD szintnek. Egyébként így láthatod, hogy mekkora blokkmérettel rendelkezik a lemezed:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512A fenti szint egy partíció, egy az egész lemezhez (ismét az egyszerűség kedvéért). Leggyakrabban kétféle partíciójelölést használnak: msdos és gpt. Ennek megfelelően az msdos egy régi formátum, amely 2Tb-ig támogatja a lemezeket, a gpt pedig egy új formátum, amely 1 bájtos blokkokból 512 zettabájtig képes megcímezni. Esetünkben van egy msdos típusú partíció, amint az ábrán látható, a partíció az 1-es blokkkal kezdődik, míg az MBR-hez nullát használunk.
Az első partícióban létrehoztam egy ext2 fájlrendszert, melynek alapértelmezett blokkmérete 4096 bájt, amit az ábra is tükröz. A fájlrendszer blokkméretét így tekintheti meg:
root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: <not available>
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: Fri Aug 2 15:02:13 2019
Last mount time: n/a
Last write time: Fri Aug 2 15:02:14 2019
Mount count: 0
Maximum mount count: -1
Last checked: Fri Aug 2 15:02:13 2019
Check interval: 0 (<none>)
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 „Blokkméret”.
Az érdekes rész az, hogy hogyan kell olvasni a /home/serp/testfile fájlt? Egy fájl egy vagy több fájlrendszer-blokkból áll, amelyekben az adatait tárolják. Ismerve a fájl nevét, hogyan lehet megtalálni? Mely blokkokat érdemes elolvasnom?
Itt jönnek jól az inodes-ok. Az ext2fs fájlrendszernek van egy "táblázata", amely az összes inode-ra vonatkozó információkat tartalmaz. Az ext2fs esetén az inodok számát a fájlrendszer létrehozásakor állítjuk be. A tune2fs kimenet „Inode count” paraméterében megnézzük a szükséges számokat, pl. 65536 darabunk van. Az inode tartalmazza a szükséges információkat: a keresett fájl fájlrendszer-blokkjainak listáját. Hogyan lehet megtalálni az inode számát egy adott fájlhoz?
A megfelelő név és inode szám a könyvtárban található, az ext2fs-ben lévő könyvtár pedig egy speciális fájltípus, pl. saját inode száma is van. Ennek az ördögi körnek a megtörésére a gyökérkönyvtárhoz egy „fix” „2” inode számot rendeltek. Nézzük a 2-es számú inode tartalmát:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
debugfs: stat <2>
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 -- Fri Aug 2 16:34:09 2019
atime: 0x5d43c247:b704301c -- Fri Aug 2 15:55:35 2019
mtime: 0x5d43cb51:16b61bcc -- Fri Aug 2 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- Fri Aug 2 15:02:14 2019
Size of extra inode fields: 28
BLOCKS:
(0):579
TOTAL: 1Amint látja, a szükséges könyvtár az 579-es blokkban található. Ebben megtaláljuk a home mappa csomópontszá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 csomópontszámát. Ha hirtelen valaki ellenőrizni akarja, hogy a szám helyes-e, és megvan-e a szükséges információ, az nem nehéz. Mi csináljuk:
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 kimenetben a könyvtárban lévő fájlok neveit olvashatjuk.
Tehát eljutok a fő kérdéshez: "milyen okok miatt fordulhat elő a felvételi hiba?"
Természetesen ez akkor történik meg, ha a fájlrendszerben nem marad szabad blokk. Mit lehet tenni ebben az esetben? A nyilvánvaló „törölje ki a szükségtelent” mellett, ne feledje, hogy az ext2,3, 4 és 13094 fájlrendszerekben létezik egy olyan dolog, mint a „Fenntartott blokkok száma”. Ha megnézi a fenti listát, akkor „XNUMX” ilyen blokkjaink vannak. Ezek olyan blokkok, amelyeket csak a root felhasználó írhat. de ha gyorsan meg kell oldania a problémát, ideiglenes megoldásként mindenki számára elérhetővé teheti őket, ami szabad helyet eredményez:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Azok. alapértelmezés szerint a lemezterület 5%-a nem áll rendelkezésre írásra, és a modern lemezek térfogatát figyelembe véve ez több száz gigabájt is lehet.
Mi más lehetne? Az is lehetséges, hogy vannak szabad blokkok, de nincs több csomópont. Ez általában akkor fordul elő, ha a fájlrendszerben egy csomó olyan fájl található, amelyek kisebbek a fájlrendszer blokkméreténél. Figyelembe véve, hogy 1 inode-ot 1 fájlra vagy könyvtárra költenek, és összesen (adott fájlrendszerre) 65536-unk van - a helyzet több mint reális. Ez jól látható a df parancs kimenetéből:
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/wwwAmint a /var/www partíción jól látható, a fájlrendszerben lévő szabad blokkok száma és a szabad csomópontok száma nagymértékben változik.
Ha kifogyna az inode-ból, nem mondok el semmilyen varázslatot, mert... nincsenek (ha tévedek, szóljatok). Tehát azoknál a partícióknál, amelyekben kisméretű fájlok szaporodnak, bölcsen kell megválasztani a fájlrendszert. Például a btrfs inodes nem érhet véget, mert Szükség esetén dinamikusan újak jönnek létre.
Forrás: will.com