Periodiski, lai pārietu uz Centrālo sadales centru, veicu intervijas dažādos lielos uzņēmumos, galvenokārt Sanktpēterburgā un Maskavā, DevOps amatam. Es pamanīju, ka daudzi uzņēmumi (daudzi labi uzņēmumi, piemēram, Yandex) uzdod divus līdzīgus jautājumus:
- kas ir inode;
- Kādu iemeslu dēļ var rasties diska rakstīšanas kļūda (vai piemēram: kāpēc diskā var pietrūkt vietas, būtība ir tāda pati).
Kā jau tas bieži notiek, biju pārliecināta, ka labi pārzinu šo tēmu, taču, tiklīdz sāku skaidrot, atklājās nepilnības zināšanās. Lai sistematizētu savas zināšanas, aizpildītu robus un vairs sevi neapmulsinātu, rakstu šo rakstu, varbūt vēl kādam noderēs.
Sākšu no apakšas, t.i. no cietā diska (atmetīsim zibatmiņas diskus, SSD un citas modernas lietas; piemēram, ņemsim vērā jebkuru 20 vai 80 giga vecu disku, jo bloka izmērs ir 512 baiti).
Cietais disks nezina, kā uzrunāt savu vietu baitu pa baitam, tas ir nosacīti sadalīts blokos. Bloku numerācija sākas no 0. (To sauc par LBA, sīkāka informācija šeit:
Kā redzams attēlā, es norādīju LBA blokus kā HDD līmeni. Starp citu, jūs varat redzēt, kāds bloka lielums ir jūsu diskā, piemēram:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512
Iepriekš minētais līmenis ir nodalījums, viens visam diskam (atkal vienkāršības labad). Visbiežāk tiek izmantoti divu veidu nodalījumu iezīmēšanas veidi: msdos un gpt. Attiecīgi msdos ir vecs formāts, kas atbalsta diskus līdz 2Tb, gpt ir jauns formāts, kas spēj adresēt līdz 1 zettabaitu no 512 baitu blokiem. Mūsu gadījumā mums ir msdos tipa nodalījums, kā redzams attēlā, nodalījums sākas ar bloku Nr. 1, savukārt MBR tiek izmantota nulle.
Pirmajā nodalījumā izveidoju ext2 failu sistēmu, tās noklusējuma bloka izmērs ir 4096 baiti, kas arī ir atspoguļots attēlā. Failu sistēmas bloka lielumu varat skatīt šādi:
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-c898746ccd76
Mums nepieciešamais parametrs ir “Bloka izmērs”.
Tagad interesantā daļa ir, kā lasīt /home/serp/testfile failu? Fails sastāv no viena vai vairākiem failu sistēmas blokiem, kuros tiek glabāti tā dati. Zinot faila nosaukumu, kā to atrast? Kurus blokus man vajadzētu lasīt?
Šeit noder inodes. Ext2fs failu sistēmai ir "tabula", kurā ir informācija par visām inodes. Inodes skaits ext2fs gadījumā tiek iestatīts, veidojot failu sistēmu. Apskatām vajadzīgos skaitļus tune2fs izvades parametrā “Inode count”, t.i. mums ir 65536 gab. Inode satur mums nepieciešamo informāciju: failu sistēmas bloku sarakstu failam, kuru mēs meklējam. Kā atrast inode numuru konkrētam failam?
Attiecīgais nosaukums un inode numurs ir ietverts direktorijā, un direktorijs ext2fs ir īpašs faila veids, t.i. ir arī savs inodes numurs. Lai pārtrauktu šo apburto loku, saknes direktorijam tika piešķirts "fiksēts" inodes numurs "2". Apskatīsim 2. inodes saturu:
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: 1
Kā redzat, mums nepieciešamais direktorijs atrodas blokā ar numuru 579. Tajā mēs atradīsim mājas mapes mezgla numuru un tā tālāk pa ķēdi, līdz serp direktorijā mēs redzēsim pieprasītā faila mezgla numuru. Ja pēkšņi kāds vēlas pārbaudīt, vai numurs ir pareizs un vai ir vajadzīgā informācija, tas nav grūti. Mēs darām:
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
Izvadē var izlasīt direktorijā esošo failu nosaukumus.
Tāpēc es nonāku pie galvenā jautājuma: "kādu iemeslu dēļ var rasties ierakstīšanas kļūda?"
Protams, tas notiks, ja failu sistēmā nav palicis neviens brīvs bloks. Ko šajā gadījumā var darīt? Papildus acīmredzamajam “izdzēsiet visu nevajadzīgo”, jums jāatceras, ka ext2,3, 4 un 13094 failu sistēmās ir tāda lieta kā “Rezervēto bloku skaits”. Ja paskatās uz iepriekš minēto sarakstu, mums ir šādi bloki “XNUMX”. Tie ir bloki, kurus var rakstīt tikai saknes lietotājs. bet, ja problēma ir ātri jāatrisina, kā pagaidu risinājumu varat tos padarīt pieejamus ikvienam, tādējādi radot brīvu vietu:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)
Tie. pēc noklusējuma jums ir 5% no diska vietas, kas nav pieejama rakstīšanai, un, ņemot vērā mūsdienu disku apjomu, tas var būt simtiem gigabaitu.
Kas gan cits tas varētu būt? Iespējams arī, ka ir brīvi bloki, bet mezglu vairs nav. Tas parasti notiek, ja jūsu failu sistēmā ir daudz failu, kas ir mazāki par failu sistēmas bloka lielumu. Ņemot vērā, ka 1 inode tiek iztērēta 1 failam vai direktorijam, un kopā mums ir (attiecīgai failu sistēmai) 65536 - situācija ir vairāk nekā reāla. To var skaidri redzēt no komandas df izvades:
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
Kā skaidri redzams /var/www nodalījumā, brīvo bloku skaits failu sistēmā un brīvo mezglu skaits ir ļoti atšķirīgs.
Gadījumā, ja jums beigsies inodes, es jums nestāstīšu nekādas burvestības, jo... tādu nav (ja kļūdos, dariet man zināmu). Tāpēc starpsienām, kurās vairojas mazi faili, jums vajadzētu saprātīgi izvēlēties failu sistēmu. Piemēram, btrfs inodes nevar beigties, jo Ja nepieciešams, tiek dinamiski izveidoti jauni.
Avots: www.habr.com