Siirtyäkseni keskusjakelukeskukseen haastan ajoittain useissa suurissa yrityksissä, pääasiassa Pietarissa ja Moskovassa, DevOps-virkaa varten. Huomasin, että monet yritykset (monet hyvät yritykset, esimerkiksi Yandex) esittävät kaksi samanlaista kysymystä:
- mikä on inode;
- mistä syistä voit saada levyn kirjoitusvirheen (tai esimerkiksi: miksi levytila saattaa loppua, olemus on sama).
Kuten usein tapahtuu, olin varma, että tunsin tämän aiheen hyvin, mutta heti kun aloin selittää, tiedossa ilmeni aukkoja. Kirjoitan tätä artikkelia tietoni systematisoimiseksi, aukkojen täyttämiseksi enkä enää nolaa itseäni, ehkä siitä on hyötyä jollekin toiselle.
Aloitan alhaalta, ts. kiintolevyltä (hylkäämme flash-asemat, SSD-levyt ja muut nykyaikaiset asiat; otetaan esimerkiksi mikä tahansa 20 tai 80 keikan vanha asema, koska lohkon koko on siellä 512 tavua).
Kiintolevy ei osaa osoittaa tilaansa tavu tavulta, se on ehdollisesti jaettu lohkoihin. Lohkojen numerointi alkaa nollasta. (Tätä kutsutaan LBA:ksi, lisätietoja täältä: )
Kuten kuvasta näkyy, määritin LBA-lohkot kiintolevytasoksi. Muuten, voit nähdä levyn lohkokoon seuraavasti:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Yllä oleva taso on osio, yksi koko levylle (jälleen yksinkertaisuuden vuoksi). Useimmiten käytetään kahden tyyppisiä osion merkintöjä: msdos ja gpt. Vastaavasti msdos on vanha muoto, joka tukee jopa 2 Tb:n levyjä, ja gpt on uusi muoto, joka pystyy käsittelemään jopa 1 zettatavun 512 tavun lohkoista. Meidän tapauksessamme osio on tyyppiä msdos, kuten kuvasta näkyy, osio alkaa lohkosta nro 1, kun taas nollaa käytetään MBR:lle.
Ensimmäiseen osioon loin ext2-tiedostojärjestelmän, jonka oletuslohkokoko on 4096 tavua, mikä näkyy myös kuvassa. Voit tarkastella tiedostojärjestelmän lohkon kokoa seuraavasti:
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-c898746ccd76Tarvitsemme parametrin "Block size".
Nyt kiinnostava osa on /home/serp/testfile-tiedoston lukeminen? Tiedosto koostuu yhdestä tai useammasta tiedostojärjestelmälohkosta, joihin sen tiedot on tallennettu. Kun tiedät tiedostonimen, miten se löytyy? Mitä lohkoja minun pitäisi lukea?
Tässä inodit ovat hyödyllisiä. Ext2fs-tiedostojärjestelmässä on "taulukko", joka sisältää tiedot kaikista inodeista. Inodien määrä ext2fs:n tapauksessa asetetaan tiedostojärjestelmää luotaessa. Katsomme tarvittavat numerot tune2fs-lähdön "Inode count" -parametrissa, ts. meillä on 65536 kappaletta. Inode sisältää tarvitsemamme tiedot: luettelon etsimämme tiedoston tiedostojärjestelmälohkoista. Kuinka löytää inode-numero tietylle tiedostolle?
Hakemistossa on vastaava nimi ja inodien numero, ja ext2fs-hakemisto on erityinen tiedostotyyppi, ts. on myös oma inodinumeronsa. Tämän noidankehän katkaisemiseksi juurihakemistoon määritettiin "kiinteä" inodinumero "2". Katsotaanpa inodin numero 2 sisältöä:
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: 1Kuten näette, tarvitsemamme hakemisto on lohkossa 579. Siitä löydämme kotikansion solmun numeron ja niin edelleen ketjussa, kunnes serp-hakemistossa näemme pyydetyn tiedoston solmun numeron. Jos joku yhtäkkiä haluaa tarkistaa, onko numero oikein ja onko siellä tarvittavat tiedot, se ei ole vaikeaa. Me teemme:
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_imageTulosteessa voit lukea hakemistossa olevien tiedostojen nimet.
Joten tulen pääkysymykseen: "Mistä syistä tallennusvirhe voi tapahtua?"
Luonnollisesti tämä tapahtuu, jos tiedostojärjestelmässä ei ole vapaita lohkoja. Mitä tässä tapauksessa voidaan tehdä? Ilmeisen "poista kaikki tarpeeton" lisäksi sinun tulee muistaa, että ext2,3-, 4- ja 13094-tiedostojärjestelmissä on sellainen asia kuin "Varattujen lohkojen määrä". Jos katsot yllä olevaa luetteloa, meillä on "XNUMX" tällaisia lohkoja. Nämä ovat lohkoja, jotka vain pääkäyttäjä voi kirjoittaa. mutta jos sinun on ratkaistava ongelma nopeasti, voit tilapäisenä ratkaisuna asettaa ne kaikkien saataville, jolloin saadaan vapaata tilaa:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Nuo. oletusarvoisesti sinulla on 5 % levytilasta, joka ei ole käytettävissä kirjoittamista varten, ja nykyaikaisten levyjen tilavuuden vuoksi tämä voi olla satoja gigatavuja.
Mitä muuta se voisi olla? On myös mahdollista, että vapaita lohkoja on, mutta solmuja ei ole enää. Näin tapahtuu yleensä, jos tiedostojärjestelmässäsi on joukko tiedostoja, jotka ovat pienempiä kuin tiedostojärjestelmän lohkokoko. Ottaen huomioon, että 1 inode kuluu 1 tiedostoon tai hakemistoon, ja meillä on yhteensä (tietylle tiedostojärjestelmälle) 65536 - tilanne on enemmän kuin realistinen. Tämä näkyy selvästi df-komennon lähdöstä:
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/wwwKuten /var/www-osiosta selvästi näkyy, tiedostojärjestelmän vapaiden lohkojen määrä ja vapaiden solmujen määrä vaihtelevat suuresti.
Jos inodit loppuvat, en kerro sinulle loitsuja, koska... niitä ei ole (jos olen väärässä, kerro minulle). Joten osioiden, joissa pienet tiedostot lisääntyvät, tiedostojärjestelmä kannattaa valita viisaasti. Esimerkiksi btrfs-inodes ei voi päättyä, koska Uusia luodaan tarvittaessa dynaamisesti.
Lähde: will.com