Van tyd tot tyd, om na die CRS te skuif, voer ek onderhoude in verskeie groot maatskappye, hoofsaaklik in St. Petersburg en Moskou, vir die posisie van DevOps. Ek het opgemerk dat baie maatskappye (baie goeie maatskappye, byvoorbeeld Yandex) twee soortgelyke vrae vra:
- wat is 'n inode
- om watter redes jy 'n skyfskryffout kan kry (of byvoorbeeld: hoekom skyfspasie kan opraak, die essensie is dieselfde).
Soos dikwels gebeur, was ek seker dat ek hierdie onderwerp goed ken, maar sodra ek begin verduidelik het, was daar leemtes in kennis. Om my kennis te sistematiseer, die leemtes aan te vul en nie meer oneer te maak nie, skryf ek hierdie artikel, miskien sal dit iemand anders handig te pas kom.
Ek sal "van onder" begin, m.a.w. vanaf 'n hardeskyf (ons sal flash drives, SSD's en ander moderne dinge weggooi, oorweeg byvoorbeeld enige 20 of 80 gigagreep ou skyf, want daar is die blokgrootte 512 grepe).
'n Hardeskyf kan nie sy spasie greep vir greep aanspreek nie; dit word voorwaardelik in blokke verdeel. Bloknommering begin vanaf 0. (Dit word LBA genoem, besonderhede hier: )
Soos u uit die figuur kan sien, het ek die LBA-blokke as die HDD-vlak aangewys. Terloops, jy kan so sien watter blokgrootte jou skyf het:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Die vlak hierbo merk die partisie, een vir die hele skyf (weereens, vir eenvoud). Dikwels word twee tipes partisionering gebruik: msdos en gpt. Gevolglik is msdos 'n ou formaat wat skywe tot 2Tb ondersteun, gpt is 'n nuwe formaat wat tot 1 zettagreep van 512 greepblokke kan adresseer. In ons geval het ons 'n partisie van die msdos-tipe, soos uit die figuur gesien kan word, terwyl die partisie met blok nr. 1 begin, terwyl nul vir die MBR gebruik word.
In die eerste afdeling het ek 'n ext2-lêerstelsel geskep, wat 'n verstekblokgrootte van 4096 grepe het, wat ook in die figuur getoon word. U kan die blokgrootte van die lêerstelsel soos volg sien:
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-c898746ccd76Die parameter wat ons benodig is "Blokgrootte".
Nou die prettige deel, hoe om die lêer /home/serp/testfile te lees? 'n Lêer bestaan uit een of meer lêerstelselblokke wat sy data stoor. Om die lêernaam te ken, hoe om dit te vind? Watter blokke om te lees?
Dit is waar inodes handig te pas kom. Die ext2fs-lêerstelsel het 'n "tabel" wat inligting oor alle inodes bevat. Die aantal inodes in die geval van ext2fs word gestel wanneer die lêerstelsel geskep word. Ons kyk na die nodige getalle in die "Inode count" parameter van die tune2fs uitset, m.a.w. ons het 65536 stukke. Die inode bevat die inligting wat ons benodig: 'n lys lêerstelselblokke vir die lêer waarna ons soek. Hoe om die inodenommer vir 'n gegewe lêer te vind?
Die ooreenstemmende naam en inodenommer is in 'n gids vervat, en 'n gids in ext2fs is 'n spesiale tipe lêer, m.a.w. het ook sy eie inodenommer. Om hierdie bose kringloop te breek, is 'n "vaste" inodenommer van "2" aan die wortelgids toegeken. Ons kyk na die inhoud van inode nommer 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: 1Soos u kan sien, is die gids wat ons benodig vervat in blok nommer 579. Daarin sal ons die nodusnommer vir die tuislêergids vind, ensovoorts langs die ketting totdat ons die nodusnommer vir die versoekte lêer in die serp-gids sien . As iemand skielik wil kyk of die nommer korrek is en of daar die nodige inligting daar is, is dit nie moeilik nie. Ons doen:
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_imageIn die uitvoer kan jy die name van die lêers in die gids lees.
So kom ek by die hoofvraag: "om watter redes kan 'n skryffout voorkom"?
Dit sal natuurlik gebeur as daar geen gratis blokke van die lêerstelsel oor is nie. Wat kan in hierdie geval gedoen word? Benewens die ooglopende "vee iets onnodig uit", moet onthou word dat daar in die ext2,3 en 4 lêerstelsels iets soos "Reserved block count" is. As jy in die lys hierbo kyk, dan het ons sulke blokke "13094". Dit is blokke wat slegs deur die wortelgebruiker geskryf kan word. maar as u die probleem vinnig moet oplos, kan u dit as 'n tydelike oplossing aan almal beskikbaar stel, wat 'n bietjie vrye spasie tot gevolg het:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Dié. By verstek is 5% van jou skyfspasie onskryfbaar, en gegewe die grootte van moderne skywe, kan dit honderde gigagrepe wees.
Wat anders kan wees? Dit is ook moontlik dat daar vrye blokke is, maar die nodusse het opgeraak. Dit gebeur gewoonlik as jy 'n klomp lêers in jou lêerstelsel het wat kleiner is as die blokgrootte van die lêerstelsel. As in ag geneem word dat 1 inode op 1 lêer of gids bestee word, en in totaal het ons 65536 van hulle (vir 'n gegewe lêerstelsel), is die situasie meer as werklik. Dit kan duidelik gesien word uit die uitvoer van die df-opdrag:
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/wwwSoos duidelik gesien kan word op die /var/www partisie, verskil die aantal gratis lêerstelselblokke en die aantal gratis nodusse baie.
As jy uit inodes raak, sal ek jou nie towerspreuke vertel nie, want hulle is nie (indien nie reg nie, laat weet my). Dus vir partisies waarin klein lêers broei, moet jy die lêerstelsel korrek kies. Byvoorbeeld, btrfs inodes kan nie opraak nie, want nuwes word dinamies geskep soos nodig.
Bron: will.com