Med jævne mellemrum, for at flytte til det centrale distributionscenter, interviewer jeg hos forskellige store virksomheder, hovedsageligt i St. Petersborg og Moskva, til en DevOps-stilling. Jeg bemærkede, at mange virksomheder (mange gode virksomheder, for eksempel Yandex) stiller to lignende spørgsmål:
- hvad er inode;
- af hvilke årsager kan du få en diskskrivningsfejl (eller for eksempel: hvorfor du måske løber tør for diskplads, essensen er den samme).
Som det ofte sker, var jeg sikker på, at jeg kendte dette emne godt, men så snart jeg begyndte at forklare, blev huller i viden tydelige. For at systematisere min viden, udfylde hullerne og ikke længere genere mig selv, skriver jeg denne artikel, måske vil den være nyttig for en anden.
Jeg starter fra bunden, dvs. fra en harddisk (vi kasserer flashdrev, SSD'er og andre moderne ting; lad os for eksempel overveje et hvilket som helst 20 eller 80 gig gammelt drev, da blokstørrelsen der er 512 bytes).
Harddisken ved ikke, hvordan den skal adressere sin plads byte for byte; den er betinget opdelt i blokke. Bloknummerering starter fra 0. (Dette kaldes LBA, detaljer her: )
Som det kan ses af figuren, udpegede jeg LBA-blokke som HDD-niveauet. Forresten kan du se, hvilken blokstørrelse din disk har som denne:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Niveauet ovenfor er en partition, en for hele disken (igen for nemheds skyld). Oftest bruges to typer partitionsmarkering: msdos og gpt. Følgelig er msdos et gammelt format, der understøtter diske op til 2Tb, gpt er et nyt format, der er i stand til at adressere op til 1 zettabyte af 512 byte blokke. I vores tilfælde har vi en partition af typen msdos, som det kan ses af figuren, begynder partitionen med blok nr. 1, mens nul bruges til MBR.
I den første partition oprettede jeg et ext2-filsystem, dets standardblokstørrelse er 4096 bytes, hvilket også afspejles i figuren. Du kan se filsystemets blokstørrelse på denne måde:
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-c898746ccd76Den parameter, vi har brug for, er "Blokstørrelse".
Nu er den interessante del, hvordan man læser filen /home/serp/testfile? En fil består af en eller flere filsystemblokke, hvori dens data er gemt. Kender du filnavnet, hvordan finder jeg det? Hvilke blokke skal jeg læse?
Det er her inoder kommer til nytte. ext2fs filsystemet har en "tabel", der indeholder information for alle inoder. Antallet af inoder i tilfælde af ext2fs indstilles ved oprettelse af filsystemet. Vi ser på de nødvendige tal i parameteren "Inode count" på tune2fs-outputtet, dvs. vi har 65536 stk. Inoden indeholder den information, vi har brug for: en liste over filsystemblokke for den fil, vi leder efter. Hvordan finder man inodenummeret for en given fil?
Det tilsvarende navn og inodenummer er indeholdt i biblioteket, og et bibliotek i ext2fs er en speciel filtype, dvs. har også sit eget inodenummer. For at bryde denne onde cirkel blev et "fast" inodenummer "2" tildelt rodmappen. Lad os se på indholdet af 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: 1Som du kan se, er den mappe, vi har brug for, indeholdt i bloknummer 579. I den finder vi nodenummeret for hjemmemappen, og så videre ned i kæden, indtil vi i serp-mappen ser nodenummeret for den ønskede fil. Hvis der pludselig er nogen, der vil tjekke, om nummeret er korrekt, og om de nødvendige oplysninger er der, er det ikke svært. Det gør vi:
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_imageI outputtet kan du læse navnene på filerne i mappen.
Så jeg kommer til hovedspørgsmålet: "af hvilke årsager kan der opstå en optagelsesfejl?"
Dette vil naturligvis ske, hvis der ikke er nogen ledige blokke tilbage i filsystemet. Hvad kan man gøre i dette tilfælde? Udover det åbenlyse "slet alt unødvendigt", skal du huske, at der i filsystemer ext2,3 og 4 er sådan noget som "Reserveret blokantal". Hvis du ser på listen ovenfor, har vi "13094" sådanne blokke. Disse er blokke, der kun kan skrives af root-brugeren. men hvis du har brug for at løse problemet hurtigt, kan du som en midlertidig løsning gøre dem tilgængelige for alle, hvilket resulterer i lidt ledig plads:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)De der. som standard har du 5 % af diskpladsen, der ikke er tilgængelig til skrivning, og givet mængden af moderne diske, kan dette være hundredvis af gigabyte.
Hvad kunne det ellers være? Det er også muligt, at der er frie blokke, men der er ikke flere noder. Dette sker normalt, hvis du har en masse filer på dit filsystem, der er mindre end filsystemets blokstørrelse. I betragtning af at der bruges 1 inode på 1 fil eller mappe, og i alt har vi (for et givet filsystem) 65536 - situationen er mere end realistisk. Dette kan tydeligt ses fra outputtet af 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/wwwSom det tydeligt kan ses på /var/www-partitionen, varierer antallet af frie blokke i filsystemet og antallet af ledige noder meget.
Hvis du løber tør for inoder, vil jeg ikke fortælle dig nogen besværgelser, fordi... der er ingen (hvis jeg tager fejl, så lad mig det vide). Så for partitioner, hvor små filer formerer sig, bør du vælge filsystemet med omhu. For eksempel kan btrfs inoder ikke slutte, fordi Nye oprettes dynamisk om nødvendigt.
Kilde: www.habr.com