Periodisk interviewer jeg mig i forskellige store virksomheder, primært i Sankt Petersborg og Moskva, til stillingen som DevOps, da jeg overvejer at flytte til et datacenter. Jeg har bemærket, at mange selskaber (mange gode selskaber, for eksempel Yandex) stiller to lignende spørgsmål:
- hvad er inode;
- af hvilke årsager man kan få en skrivefejl på disken (eller for eksempel: hvorfor kan der være mangel på plads på disken, essensen er den samme).
Som ofte er jeg sikker på, at jeg kender dette emne godt, men så snart jeg begyndte at forklare, blev der synlige huller i mine viden. For at systematisere mine oplysninger, udfylde hullerne og ikke skamme mig mere, skriver jeg denne artikel, måske kan det også være nyttigt for andre.
Jeg vil starte "nedenfra", dvs. med harddisken (USB-nøgler, SSD og andre moderne enheder vil vi lade ligge, for eksempel kigger vi på enhver 20 eller 80 gigabyte gammel disk, da blokstørrelsen er 512 byte).
En harddisk kan ikke adressere sit rum byte for byte, det er betinget opdelt i blokke. Nummereringen af blokke begynder fra 0. (Det kaldes LBA, detaljer her: )
Som vist på tegningen har jeg markeret LBA-blokke som HDD-niveau. For øvrigt kan man tjekke, hvad blokstørrelsen på din disk er, på følgende måde:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Et niveau højere er partitionen, en på hele disken (igen for enkelhedens skyld). Der anvendes mest to typer partitionsopdeling: msdos og gpt. Hhv. er msdos det gamle format, der understøtter diske op til 2Tb, mens gpt er det nye format, der kan adressere op til 1 zettabyte 512 byte blokke. I vores tilfælde har vi en partition af typen msdos, som vist på tegningen, begynder partitionen ved blok nr. 1, mens den nulte bruges til MBR.
I den første partition har jeg oprettet et ext2-filsystem, som standard har blokstørrelsen 4096 byte, hvilket også er vist på tegningen. Man kan se blokstørrelsen på filsystmet på følgende måde:
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-c898746ccd76Den parameter, vi har brug for, er "Block size".
Nu kommer det interessante: hvordan læser vi filen /home/serp/testfile? Filen består af en eller flere blokke i filsystemet, som indeholder dens data. Hvordan finder vi filen, når vi kender dens navn? Hvilke blokke skal læses?
Her kommer vi til at bruge inode. I ext2fs filsystemet findes der en "tabel", der indeholder oplysninger om alle inode. Antallet af inode i ext2fs fastlægges ved oprettelsen af filsystemet. De nødvendige tal kan ses i parameteren "Inode count" fra outputtet af tune2fs, altså har vi 65536. I inode findes de oplysninger, vi har brug for: listen over blokke i filsystemet for den pågældende fil. Hvordan finder vi inode-nummeret for den angivne fil?
Samsvaret mellem filnavnet og inode-nummeret findes i kataloget, og et katalog i ext2fs er en særlig type fil, dvs. det har også sit eget inode-nummer. For at bryde denne onde cirkel fik rodkataloget tildelt et "fikseret" inode-nummer "2". Lad os se indholdet af 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: 1Som man kan se, findes den nødvendige mappe i blokken med nummer 579. Her finder vi nodenummeret for mappen home, og så videre i kæden, indtil vi i mappen serp ser nodenummeret for den anmodede fil. Hvis nogen skulle ønske at kontrollere, om nummeret er korrekt, og om der er de nødvendige oplysninger, er det ikke svært. Gør følgende:
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 man læse filnavne i mappen.
Her når jeg til det vigtigste spørgsmål: „Hvilke årsager kan der føre til en skrivefejl“?
Det vil naturligvis ske, hvis der ikke er nogen ledige blokke i filsystemet. Hvad kan man gøre i dette tilfælde? Udover det oplagte „slette noget unødvendigt“, skal man huske, at der i filsystemerne ext2,3 og 4 findes noget, der hedder „Reserved block count“. Hvis man kigger på opstillingen ovenfor, så har vi sådan nogle blokke „13094“. Det er blokke, der kun er tilgængelige for brugeren root. Men hvis man hurtigt skal løse problemet, kan man midlertidigt 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)
Indstiller den reserverede blokprocent til 0% (0 blokke)Det vil sige, at 5% af diskpladsen som standard ikke er tilgængelig til skrivning, og i betragtning af moderne diskstørrelser kan det være hundrede gigabyte.
Hvad ellers kan der være? En anden mulig situation er, at der er frie blokke, men nodene er udsolgt. Dette sker typisk, hvis du har en masse filer i dit filsystem, der er mindre end størrelsen af en blok i filsystemet. Da 1 inode bruges pr. fil eller mappe, og der i alt er (for dette filsystem) 65536 – er situationen mere end reel. Det 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/wwwSom godt kan ses i /var/www, adskiller mængden af ledige filsystemblokke og antallet af ledige noder sig markant.
Hvis inodes skulle løbe tør, har jeg ikke nogen løsninger, da der ikke er nogen (hvis jeg tager fejl, så lad mig vide det). Så for partitioner, hvor små filer hober sig op, bør filsystemet vælges med omhu. For eksempel kan inodes i btrfs ikke løbe tør, da de dynamisk oprettes efter behov.
Kilde: habr.com
