Periodyk, om te ferhúzjen nei it Sintraal Distribúsjesintrum, ynterviewje ik by ferskate grutte bedriuwen, benammen yn Sint-Petersburch en Moskou, foar in DevOps-posysje. Ik fernaam dat in protte bedriuwen (in protte goede bedriuwen, bygelyks Yandex) twa ferlykbere fragen stelle:
- wat is inode;
- om hokker redenen kinne jo krije in skiif skriuw flater (of bygelyks: wêrom jo miskien rinne út skiif romte, de essinsje is itselde).
Lykas faaks bart, wie ik der wis fan dat ik dit ûnderwerp goed koe, mar sa gau as ik begon te ferklearjen, waarden hiaten yn kennis dúdlik. Om myn kennis te systematisearjen, de gatten yn te foljen en mysels net mear te ferlegen, skriuw ik dit artikel, miskien sil it nuttich wêze foar in oar.
Ik sil fan ûnderen begjinne, d.w.s. fan in hurde skiif (wy sille flash-skiven, SSD's en oare moderne dingen wegerje; Litte wy bygelyks elke 20 of 80 gig âlde skiif beskôgje, om't de blokgrutte d'r 512 bytes is).
De hurde skiif wit net hoe't er syn romte byte foar byte oanpakke moat; it is betingst ferdield yn blokken. Bloknûmering begjint fan 0. (Dit wurdt LBA neamd, details hjir: )
As kin sjoen wurde út de figuer, Ik oanwiisd LBA blokken as de HDD nivo. Trouwens, jo kinne sjen hokker blokgrutte jo skiif hat sa:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512It nivo boppe is in partysje, ien foar de hiele skiif (wer foar ienfâld). Meastentiids wurde twa soarten partition markup brûkt: msdos en gpt. Dêrtroch is msdos in âld formaat dat skiven oant 2Tb stipet, gpt is in nij formaat dat by steat is om oant 1 zettabyte fan 512 byteblokken oan te pakken. Yn ús gefal hawwe wy in partysje fan it type msdos, lykas út 'e figuer te sjen is, begjint de partysje mei blok nûmer 1, wylst nul brûkt wurdt foar de MBR.
Yn 'e earste partysje haw ik in ext2-bestânsysteem makke, de standertblokgrutte is 4096 bytes, wat ek yn' e figuer reflektearre is. Jo kinne de blokgrutte fan it bestânsysteem sa besjen:
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-c898746ccd76De parameter dy't wy nedich binne is "Blokgrutte".
No is it nijsgjirrige diel hoe't jo it /home/serp/testfile-bestân lêze? In bestân bestiet út ien of mear bestânsysteemblokken wêryn syn gegevens wurde opslein. Wittende de triemnamme, hoe te finen it? Hokker blokken moat ik lêze?
Dit is wêr't ynodes fan pas komme. It ext2fs-bestânsysteem hat in "tabel" dy't ynformaasje befettet foar alle ynoden. It oantal ynoden yn it gefal fan ext2fs wurdt ynsteld by it meitsjen fan it bestânsysteem. Wy sjogge nei de fereaske nûmers yn 'e parameter "Inode count" fan 'e tune2fs-útfier, d.w.s. wy hawwe 65536 stikken. De inode befettet de ynformaasje dy't wy nedich binne: in list mei triemsysteemblokken foar it bestân dat wy sykje. Hoe kinne jo it inode-nûmer fine foar in opjûne triem?
De korrespondearjende namme en it ynodenûmer binne yn 'e map opnommen, en in map yn ext2fs is in spesjaal type triem, d.w.s. hat ek in eigen inode nûmer. Om dizze vicieuze sirkel te brekken, waard in "fêst" ynode nûmer "2" tawiisd oan 'e root-map. Litte wy nei de ynhâld fan inode nûmer 2 sjen:
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: 1Sa't jo sjen kinne, is de map dy't wy nedich binne befette yn bloknûmer 579. Dêryn sille wy it knooppuntnûmer fine foar de thúsmap, en sa fierder yn 'e keatling oant yn' e serp-map wy it knooppuntnûmer foar it frege bestân sjogge. As immen ynienen kontrolearje wol oft it nûmer kloppet en oft de nedige ynformaasje der is, is dat net dreech. Wy dogge:
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_imageYn 'e útfier kinne jo de nammen fan' e bestannen yn 'e map lêze.
Dat ik kom by de haadfraach: "om hokker redenen kin in opnameflater foarkomme?"
Natuerlik sil dit barre as d'r gjin frije blokken oer binne yn it bestânsysteem. Wat kin dien wurde yn dit gefal? Neist de fanselssprekkende "wiskje alles wat net nedich is", moatte jo betinke dat yn ext2,3 en 4 bestânsystemen sa'n ding is as "Reserved block count". As jo nei de boppesteande list sjogge, hawwe wy sokke blokken "13094". Dit binne blokken dy't allinich skriuwe kinne troch de root-brûker. mar as jo it probleem fluch moatte oplosse, kinne jo se as tydlike oplossing foar elkenien beskikber stelle, wat resulteart yn wat frije romte:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Dy. standert, do hast 5% fan de skiif romte net beskikber foar skriuwen, en jûn it folume fan moderne skiven, dit kin wêze hûnderten gigabytes.
Wat koe it oars wêze? It is ek mooglik dat der frije blokken, mar der binne gjin knooppunten mear. Dit bart normaal as jo in bosk bestannen op jo bestânsysteem hawwe dy't lytser binne dan de blokgrutte fan it bestânsysteem. Yn betinken nommen dat 1 inode wurdt bestege oan 1 triem of map, en yn totaal hawwe wy (foar in opjûne triem systeem) 65536 - de situaasje is mear as realistysk. Dit kin dúdlik sjoen wurde fan 'e útfier fan it kommando df:
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/wwwLykas dúdlik te sjen is op 'e /var/www-partysje, ferskille it oantal fergese blokken yn it bestânsysteem en it oantal frije knopen sterk.
Yn it gefal dat jo gjin inodes hawwe, sil ik jo gjin spreuken fertelle, om't ... der binne gjin (as ik bin ferkeard, lit it my witte). Dus foar partysjes wêryn lytse bestannen fermannichfâldigje, moatte jo it bestânsysteem wiis kieze. Bygelyks, btrfs inodes kin net einigje, omdat Nije wurde dynamysk oanmakke as it nedich is.
Boarne: www.habr.com