Aeg-ajalt, et üleviimine CRSi, olen intervjueerinud erinevates suurtes ettevõtetes, peamiselt Peterburis ja Moskvas, DevOps ametikoha peale. Olen tähele pannud, et paljudes ettevõtetes (paljudes heades ettevõtetes, näiteks Yandexis) esitatakse kaks sarnast küsimust:
- mis on inode;
- millistel põhjustel võib tekkida viga ketta kirjutamisel (või näiteks: miks võib ketas täis saada, sisu on sama).
Nagu sageli juhtub, olin kindel, et teema on mul hästi selge, kuid kui hakkasin selgitama, siis ilmnesid teadmisteaugud. Et oma teadmisi süsteemsemalt korraldada, lünkasid täita ja enam mitte piinlikkust tunda, kirjutan selle artikli, ehk on see kellelegi veel kasulik.
Alustan „alt“, st kõvakettast (väikesed mälupulgad, SSD ja muud kaasaegsed vidinad jäetakse kõrvale, vaatleme igasugust 20 või 80 gigabaidist vana ketast, kuna seal on ploki suurus 512 baiti).
Kõvaketas ei oska adresseerida oma ruumi baitide kaupa, see on tinglikult jagatud plokkideks. Plokkide nummerdamine algab 0-st. (seda nimetatakse LBA-ks, detailid siin: )
Nagu jooniselt näha, olen LBA plokid tähistanud kui HDD taset. Muide, vaadata, milline on teie ketta ploki suurus, saab niimoodi:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Ühe taseme võrra kõrgem on osakond, üks tervele kettale (taas lihtsuse huvides). Kõige sagedamini kasutatakse kaht tüüpi partitsioonihaldust: msdos ja gpt. Seega msdos on vana formaat, mis toetab kettasid kuni 2Tb, gpt on uus formaat, mis suudab adresseerida kuni 1 zettabaidi 512 baitiste plokkide. Meie juhul on osakonna tüüp msdos, nagu jooniselt näha, osakond algab ploki nr 1-st, nullkasutatakse aga MBR jaoks.
Esimeses osas lõin failisüsteemi ext2, mille ploki suurus on vaikimisi 4096 baiti, nagu jooniselt näha. Failisüsteemi ploki suurust saab vaadata niimoodi:
root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
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: 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 ()
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-c898746ccd76Meile vajalik parameeter on "Block size."
Nüüd on kõige huvitavam, kuidas lugeda faili /home/serp/testfile? Fail koosneb ühe või mitme failisüsteemi blokist, kus on talletatud selle andmed. Teades faili nime, kuidas seda leida? Milliseid blokke lugeda?
Siin tulevadki abiks inode'id. Failisüsteemil ext2fs on "tabel", kus on teave kõigi inode'ide kohta. Inode'ide arvu määrab ext2fs-i loomisel failisüsteem. Vajalikke arve vaatame parametrist "Inode count" tune2fs väljundis, st meil on 65536 tükki. Inode'ides on vajalik teave: failisüsteemi blokkide loetelu otsitava faili jaoks. Kuidas leida antud faili inode'i number?
Nime ja inode'i numberi vastavust hoitakse kataloogis ning kataloog ext2fs-is on erilise tüübi fail, st tal on samuti oma inode'i number. Selle nõiaringi katkestamiseks määrati juurkataloogile „fikseeritud“ inode'i number „2“. Vaatame inode'i sisu numbriga 2:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
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 -- 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: 1Nagu näha, sisaldub vajalik kaust plokis number 579. Sealt leiame kausta home nodenumbri ja jätkame järjestust, kuni kataloogis serp näeme nõutud faili nodenumbrit. Kui keegi soovib kontrollida, kas number on õige ja kas seal on vajalik teave, pole see keeruline. Teeme:
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_imageVäljundist võib lugeda kaustade nimesid.
Nüüd olen lähenenud peamisele küsimusele: „Millistel põhjustel võib tekkida kirjutamisviga“?
Loomulikult juhtub see siis, kui failisüsteemis ei jää vabu blokke. Mida saab sel juhul teha? Peale kõige ilmsema „kustuta midagi mittevajalikku“, tasub meeles pidada, et failisüsteemides ext2, 3 ja 4 on selline asi nagu „Reserved block count“. Kui vaadata eelnevat nimekirja, siis on meil neid blokee „13094“. Need blokid on kirjutamiseks saadaval ainult kasutajale root. Kuid kui on vaja küsimus kiiresti lahendada, siis saab ajutiselt teha need kõikidele kättesaadavaks, mille tulemusena ilmub veidi vaba ruumi:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Seades reserveeritud blokki protsendi 0% (0 blokki)See tähendab, et vaikimisi on teil kirjutamiseks kättesaadavad 5% ketasruumist, ja arvestades kaasaegsete ketaste mahtu, võivad need olla sada gigabaytti.
Mis veel võib juhtuda? Veel on võimalik olukord, kus vabad blokid on olemas, kuid nodid on otsas. See juhtub tavaliselt siis, kui teie failisüsteemis on palju faile, mis on väiksemad kui failisüsteemi bloki suurus. Arvestades, et iga faili või kausta puhul kulub 1 inode ja kokku on need (antud failisüsteemi jaoks) 65536 — olukord on enam kui reaalne. Selgelt on seda näha käsku df käitades:
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/wwwNagu hästi on märgata jaotises /var/www, on failisüsteemi vabad blokeerimise numbrid ja vabad noodid tugevalt erinevad.
Kui inode'id peaksid otsa lõppema, ei oska ma juhendada, kuna neid pole (kui ma eksin, andke teada). Seega, jaotistes, kus luuakse väikeseid faile, tuleb failisüsteemi valimisel olla hoolikas. Näiteks btrfs puhul ei saa inode'id otsa lõppeda, kuna neid luuakse vajadusel dünaamiliselt.
Allikas: habr.com
