Något om inode

Periodiskt, för att flytta till CRS, intervjuar jag i olika stora företag, främst i St. Petersburg och Moskva för rollen som DevOps. Jag har lagt märke till att många företag (många bra företag, till exempel Yandex) ställer två liknande frågor:

• vad är en inode;
• av vilka skäl kan man få ett skrivfel på disken (eller till exempel: varför kan det ta slut på utrymme på disken, essensen är densamma).

Som det ofta är, var jag säker på att jag kände till detta ämne väl, men så fort jag började förklara — började kunskapsluckor att visa sig. För att systematisera min kunskap, fylla i luckorna och inte skämma ut mig igen, skriver jag denna artikel, kanske någon annan har nytta av den.

Jag börjar "från botten", det vill säga med hårddisken (usb-minnen, SSD och andra moderna enheter lämnar vi bort, för exemplet tar vi vilken gammal disk som helst på 20 eller 80 gigabyte, eftersom blockstorleken där är 512 byte).

Hårddisken kan inte adressera sitt utrymme byte för byte, det är i grova drag uppdelat i block. Blocknumreringen börjar från 0. (detta kallas LBA, detaljer här: ru.wikipedia.org/wiki/LBA)

Som man kan se från bilden, har jag markerat LBA-blocken som nivån på HDD. För att ta reda på vilken blockstorlek din disk har kan man göra så här:

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

Ovanför är partitionen markerad, en för hela disken (återigen för enkelhetens skull). Oftast används två typer av partitionering: msdos och gpt. Därmed är msdos ett gammalt format som stöder diskar upp till 2TB, medan gpt är ett nytt format som kan adressera upp till 1 zettabyte 512-byte block. I vårt fall har vi en partition av typen msdos, som man kan se från bilden, börjar partitionen från block nr 1, medan den nollte används för MBR.

I den första partitionen skapade jag ett ext2 filsystem, med standard blockstorlek på 4096 byte, vilket också återspeglas på bilden. För att se blockstorleken på filsystemet kan man göra så här:

root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filsystemvolymnamn:   
Senast monterad på:          
Filssystem UUID:          a600bf40-f660-41f6-a3e6-96c303995479
Filssystem magisk nummer:  0xEF53
Filssystem revision #:    1 (dynamisk)
Filssystemfunktioner:      ext_attr resize_inode dir_index filetype sparse_super large_file
Filssystemflaggor:         signed_directory_hash
Standardmonteringsalternativ:    user_xattr acl
Filssystemtillstånd:         rent
Felhantering:          Fortsätt
Filssystemets operativsystemstyp:       Linux
Inodeantal:              65536
Blockantal:              261888
Reserverat blockantal:     13094
Fria block:              257445
Fria inoder:              65525
Första block:              0
Blockstorlek:               4096
Fragmentstorlek:            4096
Reserverade GDT-block:      63
Block per grupp:         32768
Fragment per grupp:      32768
Inoder per grupp:         8192
Inode-block per grupp:   512
Filssystem skapat:       fre 2 aug 15:02:13 2019
Senaste monterad tid:          n/a
Senaste skrivtid:          fre 2 aug 15:02:14 2019
Monteringsantal:              0
Max monteringsantal:      -1
Senast kontrollerad:             fre 2 aug 15:02:13 2019
Kontrollintervall:           0 ()
Reserverade block uid:      0 (användare root)
Reserverade block gid:      0 (grupp root)
Första inode:              11
Inode-storlek:               256
Krävd extra isize:     28
Önskad extra isize:      28
Standardkataloghash:   half_md4
Katalog Hash Seed:      c0155456-ad7d-421f-afd1-c898746ccd76

Den parameter vi behöver är "Blockstorlek".

Nu blir det intressant, hur läser man filen /home/serp/testfile? Filen består av en eller flera block i filsystemet där dess data lagras. Med filnamnet, hur hittar man den? Vilka block ska läsas?

Här kommer inoder väl till pass. I filsystemet ext2fs finns en "tabell" som innehåller information om alla inoder. Antalet inoder i fallet med ext2fs fastställs vid skapandet av filsystemet. De siffror vi behöver ser vi i parametern "Inodeantal" i utskriften av tune2fs, vi har 65536 stycken. I inoden finns den information vi behöver: listan över filsystemblock för den fil som söks. Hur hittar man inode-nummer för den angivna filen?

Överensstämmelsen mellan namn och inode-nummer finns i katalogen, och en katalog i ext2fs är en speciell typ av fil, dvs den har också sitt eget inode-nummer. För att bryta denna onda cirkel har den rotkatalogen tilldelats ett "fast" inode-nummer, nämligen "2". Låt oss se innehållet i inode nummer 2:

root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
debugfs:  stat 

Inode: 2   Typ: katalog    Läge:  0755   Flaggor: 0x0
Generation: 0    Version: 0x00000000:00000002
Användare:     0   Grupp:     0   Storlek: 4096
Fil ACL: 0    Katalog ACL: 0
Länkar: 3   Blockantal: 8
Fragment:  Adress: 0    Nummer: 0    Storlek: 0
 ctime: 0x5d43cb51:16b61bcc -- fre 2 aug 16:34:09 2019
 atime: 0x5d43c247:b704301c -- fre 2 aug 15:55:35 2019
 mtime: 0x5d43cb51:16b61bcc -- fre 2 aug 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- fre 2 aug 15:02:14 2019
Storlek på extra inode-fält: 28
BLOCKS:
(0):579
TOTAL: 1

Som man kan se, finns den nödvändiga katalogen i blocket med numret 579. Där hittar vi nodnumret för mappen home, och så vidare i kedjan, tills vi i katalogen serp ser nodnumret för den begärda filen. Om någon vill kontrollera om numret är korrekt och om det finns nödvändig information där, är det inte svårt. Gör så här:

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

I utskriften kan man läsa filnamn i katalogen.

Här kommer jag till huvudfrågan: "av vilka skäl kan det uppstå ett skrivfel"?

Det är uppenbart att detta kan hända om det inte finns några lediga block i filsystemet. Vad kan man göra i detta fall? Förutom det uppenbara "ta bort något onödigt" bör man minnas att i ext2, 3 och 4 filsystem finns något som kallas "Reserved block count". Om vi tittar på utskriften ovan har vi sådana block "13094". Dessa block är endast tillgängliga för skrivande av användaren root. Men om man snabbt vill lösa problemet kan man göra dem tillgängliga för alla, vilket resulterar i lite ledigt utrymme:

root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Sätter reservblockens procentandel till 0% (0 block)

Det vill säga, som standard är 5% av diskrymden inte tillgänglig för skrivning, och med tanke på storleken på moderna diskar kan detta handla om hundratals gigabyte.

Vad mer kan det vara? En annan möjlig situation är att det finns lediga block, men nodernas utrymme är slut. Detta händer vanligtvis om du har ett stort antal filer i filsystemet vars storlek är mindre än blockstorleken för filsystemet. Med tanke på att 1 inode används per fil eller katalog och vi totalt har (för detta filsystem) 65536 — en sådan situation är mer än verklig. Detta kan tydligt ses från utskriften av kommandot df:

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

Som bra syns i partitionen /var/www, varierar antalet lediga block i filsystemet och antalet lediga inoder kraftigt.

Om inoderna tar slut, kan jag tyvärr inte ge några tips, eftersom det inte finns några (hör av dig om jag har fel). Så när det kommer till partitioner där små filer produceras måste filsystemet väljas noggrant. Till exempel kan inoder i btrfs inte ta slut, eftersom nya skapas dynamiskt vid behov.

Källa: habr.com