Noe om inode

Av og til, for å flytte til et datasenter, har jeg intervjuer i ulike store selskaper, hovedsakelig i St. Petersburg og Moskva, for stillinger som DevOps. Jeg har lagt merke til at mange selskaper (mange gode selskaper, for eksempel Yandex) stiller to lignende spørsmål:

• Hva er inode;
• Hvilke grunner kan føre til skrivefeil på disken (eller for eksempel: hvorfor kan det bli fullt på disken, essensen er den samme).

Som det ofte skjer, var jeg sikker på at jeg kjente dette emnet godt, men så snart jeg begynte å forklare det — dukket kunnskapshullene opp. For å systematisere min kunnskap, fylle hullene og aldri mer skjemmes, skriver jeg denne artikkelen, kanskje den kan være nyttig for noen andre.

Jeg begynner «nedenfra», det vil si med harddisken (vi ser bort fra flashminner, SSD-er og andre moderne enheter, for eksempel tar vi hvilket som helst gammelt 20- eller 80-gigabytes disk, da blokkstørrelsen der er 512 byte).

Harddisken kan ikke adressere sitt rom byte for byte, det er betinget delt opp i blokker. Blokknummervingen starter fra 0. (dette kalles LBA, detaljer her: ru.wikipedia.org/wiki/LBA)

Som man kan se fra tegningen, har jeg markert LBA-blokkene som nivået til harddisken. For øvrig, for å se hvilken blokkstørrelse disken din har, kan du gjøre det slik:

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

Ovenfor er en partisjon merket, én for hele disken (igjen for enkelhets skyld). Vanligvis brukes partisjoneringsskjemaer av to typer: msdos og gpt. Hhv. er msdos — det gamle formatet, som støtter disker opp til 2Tb, gpt — det nye formatet, i stand til å adressere opp til 1 zettabyte 512-byte blokker. I vårt tilfelle har vi en msdos-partisjon, som kan sees fra tegningen, der partisjonen begynner ved blokk nr. 1, mens blokk 0 brukes til MBR.

I den første partisjonen opprettet jeg et ext2-filsystem, som per standard har en blokkstørrelse på 4096 byte, noe som også er vist på tegningen. Du kan sjekke størrelsen på blokken i filsystmet slik:

root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   
Last mounted on:          
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 ()
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

Den parameter vi trenger er «Block size».

Nå er det interessante, hvordan lese filen /home/serp/testfile? Filen består av en eller flere blokker i filsystemet, hvor dataene lagres. Hvordan finne filen ved å vite navnet? Hvilke blokker skal leses?

Her kommer vi til nytte av inode. I filsystemet ext2fs finnes det en «tabell» som inneholder informasjon om alle inode. Antallet inode i ext2fs bestemmes ved oppretting av filsystemet. De nødvendige tallene finner vi i parameteren «Inode count» i uteksporten fra tune2fs, dvs. vi har 65536 stk. I inode inneholder den nødvendige informasjonen: listen over filsystemblokkene for den søkte filen. Hvordan finne inode-nummeret for den spesifiserte filen?

Samsvaret mellom navn og inode-nummer er lagret i katalogen, og katalogen i ext2fs er en fil av en spesiell type, dvs. den har også sitt eget inode-nummer. For å bryte denne onde sirkelen ble inode-nummeret for rotkatalogen tildelt et «fast» nummer, «2». La oss se innholdet i inode nummer 2:

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

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

Som det fremgår, er den nødvendige mappe indeholdt i blokken med nummer 579. Her finder vi node-nummeret for mappen home, og så videre i rækken, indtil vi i mappen serp ser node-nummeret for den anmodede fil. Hvis nogen pludselig ønsker at tjekke, om nummeret er korrekt, og om der er de nødvendige oplysninger, er det ikke svært. Vi gø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 outputtet kan man læse filnavnene i mappen.

Så er jeg nået til det vigtigste spørgsmål: "hvilke årsager kan der være til, at der opstår en skrivefejl"?

Det vil naturligvis ske, hvis der ikke er ledige blokke i filsystemet. Hvad kan man gøre i dette tilfælde? Udover den oplagte løsning at "fjerne noget unødvendigt" bør man huske, at der i filsystemerne ext2, 3 og 4 findes noget, der hedder "Reserved block count". Hvis man ser i listen ovenfor, har vi disse blokke "13094". Disse blokke er kun tilgængelige for brugeren root. Men hvis man hurtigt skal løse problemet, kan man gøre dem tilgængelige for alle, hvilket vil give lidt ledig plads:

root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Sætter procentdelen af reserverede blokke til 0% (0 blokke)

Det vil sige, at 5% af diskpladsen som standard ikke er tilgængelig for skrivning, og taget i betragtning, hvor store moderne diske er, kan det være hundreder af gigabyte.

Hvad ellers kan der være? Der kan også opstå en situation, hvor der er ledige blokke, men noderne er opbrugt. Dette sker typisk, hvis man har masser af filer i filsystemet, som er mindre end størrelsen på filsystemets blok. Da der bruges 1 inode pr. fil eller mappe, og der i alt findes (for dette filsystem) 65536 — er denne situation mere end realistisk. Dette kan man tydeligt se i outputtet fra kommandoen 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 godt kan ses i /var/www, er antallet af ledige filsystemblokke og antallet af ledige inodes meget forskelligt.

Hvis inodes løber tør, kan jeg ikke hjælpe med råd, fordi der ikke er nogen (hvis jeg tager fejl, så lad mig vide). Så for partitioner, hvor små filer produceres, skal filsystemet vælges korrekt. For eksempel kan inodes ikke løbe tør i btrfs, da nye oprettes dynamisk efter behov.

Kilde: habr.com