Periodiek voer ik sollicitatiegesprekken bij verschillende grote bedrijven in St. Petersburg en Moskou voor de functie van DevOps. Ik viel op dat veel bedrijven (meer specifiek, goede bedrijven zoals Yandex) twee vergelijkbare vragen stellen:
- wat is een inode;
- om welke redenen kun je een schrijf fout op de schijf krijgen (of bijvoorbeeld: waarom kan de schijfruimte opraken, de essentie is dezelfde).
Zoals vaak het geval is, was ik ervan overtuigd dat ik deze materie goed begreep, maar zodra ik begon uit te leggen, kwamen er gaten in mijn kennis aan het licht. Om mijn kennis te systematiseren, de hiaten op te vullen en niet langer voor schut te staan, schrijf ik dit artikel, hopelijk heeft iemand er ook iets aan.
Ik begin āonderaanā, dat wil zeggen bij de harde schijf (we laten USB-sticks, SSD's en andere moderne technologieĆ«n buiten beschouwing en bekijken een oude schijf van 20 of 80 gigabyte, aangezien daar de blokgrootte 512 byte is).
Een harde schijf kan zijn ruimte niet byte voor byte adresseren; deze is opgedeeld in blokken. De nummering van de blokken begint bij 0. (dit wordt LBA genoemd, voor meer details zie: )
Zoals uit de afbeelding blijkt, heb ik de LBA-blokken aangeduid als het HDD-niveau. Daarnaast kun je op deze manier controleren wat de blokgrootte van jouw schijf is:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Een niveau hoger is de partitie, Ć©Ć©n voor de hele schijf (ook hier ter vereenvoudiging). Meestal worden er twee types partitie-indelingen gebruikt: msdos en gpt. Respectievelijk is msdos een oud formaat dat schijven tot 2TB ondersteunt, en gpt is een nieuw formaat dat tot 1 zettabyte van 512 byte blokken kan adresseren. In ons geval hebben we een msdos-partitie, zoals te zien is op de afbeelding, die begint met blok ā1, terwijl blok nul wordt gebruikt voor MBR.
In de eerste partitie heb ik een ext2-bestandssysteem gemaakt, met een standaard blokgrootte van 4096 bytes, wat ook op de afbeelding is weergegeven. Je kunt de blokgrootte van het bestandssysteem zo controleren:
root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-feb-2014)
Bestandsvolume naam:
Laatst gemonteerd op:
Bestandsysteem UUID: a600bf40-f660-41f6-a3e6-96c303995479
Bestandsysteem magisch nummer: 0xEF53
Bestandsysteem revisie #: 1 (dynamisch)
Bestandsysteem functies: ext_attr resize_inode dir_index filetype sparse_super large_file
Bestandsysteem vlaggen: signed_directory_hash
Standaard montage opties: user_xattr acl
Bestandsysteem staat: schoon
Fouten in gedrag: Door gaan
Bestandsysteem OS-type: Linux
Inode-aantal: 65536
Blok-aantal: 261888
Gereseveerde blokken-aantal: 13094
Vrije blokken: 257445
Vrije inodes: 65525
Eerste blok: 0
Blokgrootte: 4096
Fragmentgrootte: 4096
Gereseveerde GDT blokken: 63
Blokken per groep: 32768
Fragmenten per groep: 32768
Inodes per groep: 8192
Inode blokken per groep: 512
Bestandsysteem aangemaakt: Vrijdag 2 aug. 15:02:13 2019
Laatst gemonteerd tijd: n/a
Laatst schrijf tijd: Vrijdag 2 aug. 15:02:14 2019
Montage-aantal: 0
Maximaal montage-aantal: -1
Laatst gecontroleerd: Vrijdag 2 aug. 15:02:13 2019
Controle interval: 0 ()
Gereseveerde blokken uid: 0 (gebruiker root)
Gereseveerde blokken gid: 0 (groep root)
Eerste inode: 11
Inode grootte: 256
Vereiste extra isize: 28
Gewenste extra isize: 28
Standaard directory hash: half_md4
Directory Hash Seed: c0155456-ad7d-421f-afd1-c898746ccd76De parameter die we nodig hebben is "Block size".
Nu het interessante deel, hoe lezen we het bestand /home/serp/testfile? Het bestand bestaat uit een of meerdere blokken van het bestandsysteem waarin zijn gegevens zijn opgeslagen. Hoe vind je het, wetende dat je de bestandsnaam hebt? Welke blokken moeten we lezen?
Hier komen inodes in het spel. In het ext2fs-bestandssysteem is er een "tabel" die informatie bevat over alle inodes. Het aantal inodes wordt bepaald bij het aanmaken van het bestandsysteem. De benodigde cijfers vinden we in de parameter "Inode count" van de tune2fs-uitvoer, dat wil zeggen, er zijn 65536 van deze. In de inode staat de informatie die we nodig hebben: een lijst van blokken van het bestandsysteem voor het zoeker bestand. Hoe vind je het inode-nummer voor het opgegeven bestand?
De koppeling tussen de naam en het inode-nummer bevindt zich in de directory, en een directory in ext2fs is een bestand van een speciaal type, dat wil zeggen, het heeft ook zijn eigen inode-nummer. Om deze vicieuze cirkel te doorbreken, kreeg de rootdirectory een "vaste" inode-nummer "2" toegewezen. Laten we de inhoud van inode nummer 2 bekijken:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-feb-2014)
debugfs: stat
Inode: 2 Type: directory Mode: 0755 Flags: 0x0
Generatie: 0 Versie: 0x00000000:00000002
Gebruiker: 0 Groep: 0 Grootte: 4096
Bestand ACL: 0 Directory ACL: 0
Links: 3 Blockcount: 8
Fragment: Adres: 0 Aantal: 0 Grootte: 0
ctime: 0x5d43cb51:16b61bcc -- Vrijdag 2 aug. 16:34:09 2019
atime: 0x5d43c247:b704301c -- Vrijdag 2 aug. 15:55:35 2019
mtime: 0x5d43cb51:16b61bcc -- Vrijdag 2 aug. 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- Vrijdag 2 aug. 15:02:14 2019
Grootte van extra inode-velden: 28
BLOCKS:
(0):579
TOTAAL: 1Zoals te zien is, bevindt de directory die we nodig hebben zich in het blok met nummer 579. Daarin vinden we het node-nummer voor de map home, en zo verder in de keten, totdat we in de directory serp het node-nummer voor het opgevraagde bestand zien. Als iemand wil controleren of het nummer correct is en of de benodigde informatie daar is, is dat eenvoudig. Laten we:
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) gekopieerd, 0,000184088 s, 22,3 MB/s
root@ubuntu:~# hexdump -c /home/serp/dd_imageIn de output kunnen de bestandsnamen in de directory worden gelezen.
Hier kom ik bij de belangrijkste vraag: "om welke redenen kan een schrijf-fout optreden"?
Natuurlijk zal dat gebeuren als er geen vrije blokken zijn in het bestandssysteem. Wat kan in dat geval gedaan worden? Naast de voor de hand liggende "verwijder iets onnodigs", moet worden opgemerkt dat er in de bestandssystemen ext2, 3 en 4 zoiets als "Reserved block count" is. Als we naar de afdruk hierboven kijken, dan hebben we er "13094". Dit zijn blokken die alleen toegankelijk zijn voor de root-gebruiker. Maar als er snel een oplossing nodig is, kunnen we ze tijdelijk toegankelijk maken voor iedereen, waardoor er een beetje vrije ruimte ontstaat:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Het reserveren van blokpercentage is ingesteld op 0% (0 blokken)Dat wil zeggen, standaard is 5% van de schijfruimte niet beschikbaar voor schrijven, en gezien de grootte van moderne schijven kan dat honderden gigabytes zijn.
Wat kan er nog meer zijn? Een andere mogelijkheid is dat er vrije blokken zijn, maar de inodes zijn op. Dit gebeurt meestal als je in je bestandssysteem veel bestanden hebt die kleiner zijn dan de grootte van een blok in het bestandssysteem. Aangezien er 1 inode per bestand of directory wordt gebruikt, en we in totaal (voor dit bestandssysteem) 65536 inodes hebben, is de situatie meer dan reƫel. Dit is duidelijk zichtbaar in de output van de df-opdracht:
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\/wwwZoals goed te zien is in de sectie \/var\/www, verschilt het aantal vrije blokken in het bestandssysteem en het aantal vrije inodes sterk.
In het geval dat de inodes op zijn, kan ik geen tips geven, omdat ze niet bestaan (laat het me weten als ik het mis heb). Dus, voor partities waar kleine bestanden zich ophopen, moet je zorgvuldig het bestandssysteem kiezen. Bijvoorbeeld, in btrfs kunnen inodes niet opraken, omdat nieuwe dynamisch worden aangemaakt indien nodig.
Bron: habr.com
