Iets over inode

Om naar het Centraal Distributiecentrum te kunnen verhuizen, voer ik periodiek sollicitatiegesprekken bij verschillende grote bedrijven, voornamelijk in St. Petersburg en Moskou, voor een DevOps-positie. Ik merkte dat veel bedrijven (veel goede bedrijven, bijvoorbeeld Yandex) twee soortgelijke vragen stellen:

  • wat is inode;
  • om welke redenen kunt u een schijfschrijffout krijgen (of bijvoorbeeld: waarom u onvoldoende schijfruimte heeft, de essentie is hetzelfde).

Zoals vaak het geval is, was ik er zeker van dat ik dit onderwerp goed kende, maar zodra ik het begon uit te leggen, werden er hiaten in de kennis zichtbaar. Om mijn kennis te systematiseren, de gaten op te vullen en mezelf niet langer in verlegenheid te brengen, schrijf ik dit artikel, misschien is het nuttig voor iemand anders.

Ik begin onderaan, d.w.z. vanaf een harde schijf (we gooien flashdrives, SSD's en andere moderne dingen weg; laten we bijvoorbeeld elke 20 of 80 gig oude schijf overwegen, aangezien de blokgrootte daar 512 bytes is).

De harde schijf weet niet hoe hij zijn ruimte byte voor byte moet aanspreken; hij is voorwaardelijk verdeeld in blokken. Bloknummering begint vanaf 0. (Dit wordt LBA genoemd, details hier: ru.wikipedia.org/wiki/LBA)

Iets over inode

Zoals je in de figuur kunt zien, heb ik LBA-blokken aangewezen als het HDD-niveau. Overigens kun je als volgt zien welke blokgrootte je schijf heeft:

root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512

Het niveau erboven is een partitie, één voor de hele schijf (opnieuw voor de eenvoud). Meestal worden twee soorten partitie-opmaak gebruikt: msdos en gpt. Dienovereenkomstig is msdos een oud formaat dat schijven tot 2Tb ondersteunt, gpt is een nieuw formaat dat maximaal 1 zettabyte van 512 byteblokken kan adresseren. In ons geval hebben we een partitie van het type msdos, zoals je kunt zien in de figuur, de partitie begint met blok nr. 1, terwijl nul wordt gebruikt voor de MBR.

In de eerste partitie heb ik een ext2-bestandssysteem gemaakt, de standaard blokgrootte is 4096 bytes, wat ook wordt weerspiegeld in de afbeelding. U kunt de blokgrootte van het bestandssysteem als volgt bekijken:

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-c898746ccd76

De parameter die we nodig hebben is “Blokgrootte”.

Het interessante deel is nu: hoe lees je het bestand /home/serp/testfile? Een bestand bestaat uit een of meer bestandssysteemblokken waarin de gegevens ervan zijn opgeslagen. Kent u de bestandsnaam, hoe kunt u deze vinden? Welke blokken moet ik lezen?

Dit is waar inodes van pas komen. Het ext2fs-bestandssysteem heeft een "tabel" die informatie bevat voor alle inodes. Het aantal inodes in het geval van ext2fs wordt ingesteld bij het aanmaken van het bestandssysteem. We kijken naar de vereiste getallen in de parameter “Inode count” van de tune2fs-uitvoer, d.w.z. we hebben 65536 stuks. De inode bevat de informatie die we nodig hebben: een lijst met bestandssysteemblokken voor het bestand dat we zoeken. Hoe vind ik het inodenummer voor een bepaald bestand?

De corresponderende naam en het inodenummer bevinden zich in de directory, en een directory in ext2fs is een speciaal type bestand, d.w.z. heeft ook een eigen inodenummer. Om deze vicieuze cirkel te doorbreken werd een “vast” inodenummer “2” toegewezen aan de hoofdmap. Laten we eens kijken naar de inhoud van inode nummer 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: 1

Zoals je kunt zien, bevindt de directory die we nodig hebben zich in bloknummer 579. Daarin vinden we het knooppuntnummer voor de thuismap, enzovoort in de keten totdat we in de serp-directory het knooppuntnummer voor het opgevraagde bestand zien. Als iemand ineens wil controleren of het nummer klopt en of de benodigde gegevens aanwezig zijn, is dat niet moeilijk. Wij 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_image

In de uitvoer kunt u de namen van de bestanden in de directory lezen.

Zo kom ik bij de hoofdvraag: “om welke redenen kan er een opnamefout optreden?”

Uiteraard zal dit gebeuren als er geen vrije blokken meer in het bestandssysteem aanwezig zijn. Wat kan in dit geval worden gedaan? Naast het voor de hand liggende “verwijder alles wat onnodig is”, moet je onthouden dat er in ext2,3 en 4 bestandssystemen zoiets bestaat als “Gereserveerd aantal blokken”. Als je naar de bovenstaande lijst kijkt, hebben we dergelijke blokken "13094". Dit zijn blokken die alleen door de rootgebruiker kunnen worden geschreven. maar als u het probleem snel wilt oplossen, kunt u ze als tijdelijke oplossing voor iedereen beschikbaar maken, waardoor er wat vrije ruimte ontstaat:

root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)

Die. standaard is 5% van de schijfruimte niet beschikbaar voor schrijven, en gezien het volume van moderne schijven kan dit honderden gigabytes zijn.

Wat zou het nog meer kunnen zijn? Het kan ook zijn dat er wel vrije blokken zijn, maar dat er geen knooppunten meer zijn. Dit gebeurt meestal als uw bestandssysteem een ​​aantal bestanden heeft die kleiner zijn dan de blokgrootte van het bestandssysteem. Gezien het feit dat 1 inode wordt besteed aan 1 bestand of map, en in totaal hebben we (voor een bepaald bestandssysteem) 65536 - de situatie is meer dan realistisch. Dit is duidelijk te zien aan de uitvoer van het df-commando:

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/www

Zoals duidelijk zichtbaar is op de /var/www partitie, variëren het aantal vrije blokken in het bestandssysteem en het aantal vrije knooppunten enorm.

Als je geen inodes meer hebt, zal ik je geen spreuken vertellen, omdat... die zijn er niet (als ik het mis heb, laat het me weten). Dus voor partities waarin kleine bestanden zich vermenigvuldigen, moet u het bestandssysteem verstandig kiezen. Btrfs-inodes kunnen bijvoorbeeld niet eindigen, omdat Indien nodig worden er dynamisch nieuwe aangemaakt.

Bron: www.habr.com

Voeg een reactie