Periode, por translokiĝi al la Centra Distribua Centro, mi intervjuas ĉe diversaj grandaj kompanioj, ĉefe en Sankt-Peterburgo kaj Moskvo, por posteno de DevOps. Mi rimarkis, ke multaj kompanioj (multaj bonaj kompanioj, ekzemple Yandex) faras du similajn demandojn:
- kio estas inodo;
- pro kiaj kialoj vi povas ricevi eraron pri diskskribado (aŭ ekzemple: kial vi eble elĉerpas diskospacon, la esenco estas la sama).
Kiel ofte okazas, mi estis certa, ke mi bone konas ĉi tiun temon, sed tuj kiam mi komencis klarigi, evidentiĝis mankoj en scio. Por sistemigi miajn sciojn, plenigi la mankojn kaj ne plu embarasi min, mi skribas ĉi tiun artikolon, eble ĝi utilos al iu alia.
Mi komencos de malsupre, t.e. de malmola disko (ni forĵetos poŝmemorojn, SSD-ojn kaj aliajn modernajn aferojn; ekzemple, ni konsideru ajnan malnovan diskon de 20 aŭ 80 giga, ĉar la bloka grandeco estas 512 bajtoj).
La malmola disko ne scias kiel trakti sian spacan bajton post bajto; ĝi estas kondiĉe dividita en blokojn. Bloknumerado komenciĝas de 0. (Ĉi tio nomiĝas LBA, detaloj ĉi tie: )
Kiel videblas de la figuro, mi nomumis LBA-blokojn kiel la HDD-nivelon. Cetere, vi povas vidi kian blokgrandecon via disko havas jene:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512La supra nivelo estas sekcio, unu por la tuta disko (denove por simpleco). Plej ofte oni uzas du specojn de diskmarkado: msdos kaj gpt. Sekve, msdos estas malnova formato kiu subtenas diskojn ĝis 2Tb, gpt estas nova formato kapabla trakti ĝis 1 zettabajto de 512 bajtaj blokoj. En nia kazo, ni havas vando de tipo msdos, kiel videblas de la figuro, la subdisko komenciĝas per bloko n-ro 1, dum nulo estas uzata por la MBR.
En la unua sekcio mi kreis dosiersistemon ext2, ĝia defaŭlta blokgrandeco estas 4096 bajtoj, kio ankaŭ estas reflektita en la figuro. Vi povas vidi la dosiersisteman blokgrandecon jene:
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-c898746ccd76La parametro, kiun ni bezonas, estas "Bloka grandeco".
Nun la interesa parto estas kiel legi la dosieron /home/serp/testfile? Dosiero konsistas el unu aŭ pluraj dosiersistemblokoj en kiuj ĝiaj datenoj estas stokitaj. Sciante la dosiernomon, kiel trovi ĝin? Kiujn blokojn mi devas legi?
Jen kie inodoj utilas. La dosiersistemo ext2fs havas "tabelon" kiu enhavas informojn por ĉiuj inodoj. La nombro da inodoj en la kazo de ext2fs estas agordita dum kreado de la dosiersistemo. Ni rigardas la postulatajn nombrojn en la parametro "Inode count" de la eligo tune2fs, t.e. ni havas 65536 pecojn. La inodo enhavas la informojn, kiujn ni bezonas: listo de dosiersistemaj blokoj por la dosiero, kiun ni serĉas. Kiel trovi la inodan nombron por donita dosiero?
La responda nomo kaj inodo nombro estas enhavitaj en la dosierujo, kaj dosierujo en ext2fs estas speciala speco de dosiero, t.e. ankaŭ havas sian propran inodan nombron. Por rompi ĉi tiun malvirtan cirklon, "fiksita" inoda numero "2" estis asignita al la radika dosierujo. Ni rigardu la enhavon de la inodo numero 2:
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: 1Kiel vi povas vidi, la dosierujo, kiun ni bezonas, estas enhavita en bloko numero 579. En ĝi ni trovos la nodan numeron por la hejma dosierujo, kaj tiel plu laŭ la ĉeno ĝis en la serp-dosierujo ni vidos la nodan numeron por la petita dosiero. Se subite iu volas kontroli ĉu la nombro estas ĝusta kaj ĉu la necesaj informoj estas tie, tio ne estas malfacila. Ni faras:
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_imageEn la eligo vi povas legi la nomojn de la dosieroj en la dosierujo.
Do mi venas al la ĉefa demando: "pro kiaj kialoj povas okazi registra eraro?"
Kompreneble, ĉi tio okazos se ne restas liberaj blokoj en la dosiersistemo. Kion oni povas fari en ĉi tiu kazo? Krom la evidenta "forigi ion nenecesan", vi devas memori, ke en ext2,3 kaj 4 dosiersistemoj ekzistas tia afero kiel "Rezervataj blokkalkuloj". Se vi rigardas la supran liston, ni havas "13094" tiajn blokojn. Ĉi tiuj estas blokoj skribeblaj nur de la radika uzanto. sed se vi bezonas rapide solvi la problemon, kiel provizora solvo vi povas disponigi ilin al ĉiuj, rezultigante iom da libera spaco:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Tiuj. defaŭlte, vi havas 5% de la diskospaco ne disponebla por skribado, kaj laŭ la volumeno de modernaj diskoj, tio povas esti centoj da gigabajtoj.
Kio alia povus esti? Ankaŭ eblas, ke ekzistas liberaj blokoj, sed ne plu ekzistas nodoj. Ĉi tio kutime okazas se vi havas amason da dosieroj en via dosiersistemo, kiuj estas pli malgrandaj ol la dosiersistema blokgrandeco. Konsiderante ke 1 inodo estas elspezita por 1 dosiero aŭ dosierujo, kaj entute ni havas (por difinita dosiersistemo) 65536 - la situacio estas pli ol realisma. Ĉi tio povas esti klare vidita de la eligo de la df-komando:
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/wwwKiel klare videblas sur la /var/www-sekcio, la nombro da liberaj blokoj en la dosiersistemo kaj la nombro da liberaj nodoj multe varias.
Se vi elĉerpas inodojn, mi diros al vi neniujn sorĉojn, ĉar... estas neniuj (se mi eraras, sciigu min). Do por sekcioj en kiuj malgrandaj dosieroj multiĝas, vi devus elekti la dosiersistemon saĝe. Ekzemple, btrfs inodoj ne povas finiĝi, ĉar Novaj estas dinamike kreitaj se necese.
fonto: www.habr.com