Abych se mohl přesunout do Centrálního distribučního centra, pravidelně dělám pohovory v různých velkých společnostech, hlavně v Petrohradu a Moskvě, na pozici DevOps. Všiml jsem si, že mnoho společností (mnoho dobrých společností, například Yandex) si klade dvě podobné otázky:
- co je inode;
- z jakých důvodů se může objevit chyba zápisu na disk (nebo například: proč vám může dojít místo na disku, podstata je stejná).
Jak se často stává, byl jsem si jistý, že toto téma dobře znám, ale jakmile jsem začal vysvětlovat, objevily se mezery ve znalostech. Abych si své znalosti systematizoval, doplnil mezery a už si nedělal ostudu, píšu tento článek, třeba se bude hodit někomu dalšímu.
Začnu odspodu, tj. z pevného disku (vyhodíme flash disky, SSD a další moderní věci; uvažujme například jakýkoli 20 nebo 80 gig starý disk, protože velikost bloku je 512 bajtů).
Pevný disk neví, jak řešit svůj prostor bajt po bajtu, je podmíněně rozdělen do bloků. Číslování bloků začíná od 0. (Toto se nazývá LBA, podrobnosti zde: )
Jak je vidět z obrázku, jako úroveň HDD jsem označil bloky LBA. Mimochodem, jakou velikost bloku má váš disk, můžete vidět takto:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Výše uvedená úroveň je oddíl, jeden pro celý disk (opět pro jednoduchost). Nejčastěji se používají dva typy označení oddílů: msdos a gpt. V souladu s tím je msdos starý formát, který podporuje disky do 2 TB, gpt je nový formát schopný adresovat až 1 zettabajt 512 bajtových bloků. V našem případě máme oddíl typu msdos, jak je patrné z obrázku, oddíl začíná blokem č. 1, přičemž pro MBR je použita nula.
V prvním oddílu jsem vytvořil souborový systém ext2, jeho výchozí velikost bloku je 4096 bajtů, což se také odráží na obrázku. Velikost bloku souborového systému můžete zobrazit takto:
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-c898746ccd76Parametr, který potřebujeme, je „Velikost bloku“.
Nyní je zajímavá část, jak číst soubor /home/serp/testfile? Soubor se skládá z jednoho nebo více bloků systému souborů, ve kterých jsou uložena jeho data. Znáte název souboru, jak jej najít? Které bloky mám číst?
Zde se hodí inody. Souborový systém ext2fs má "tabulku", která obsahuje informace pro všechny inody. Počet inodů v případě ext2fs se nastavuje při vytváření souborového systému. Podíváme se na požadovaná čísla v parametru “Inode count” výstupu tune2fs, tzn. máme 65536 kusů. Inode obsahuje informace, které potřebujeme: seznam bloků systému souborů pro soubor, který hledáme. Jak zjistit číslo inodu pro daný soubor?
Odpovídající jméno a číslo inodu jsou obsaženy v adresáři a adresář v ext2fs je speciální typ souboru, tzn. má také své vlastní inodové číslo. Aby se tento začarovaný kruh prolomil, bylo kořenovému adresáři přiřazeno „pevné“ číslo inodu „2“. Podívejme se na obsah inodu číslo 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: 1Jak vidíte, adresář, který potřebujeme, je obsažen v bloku číslo 579. V něm najdeme číslo uzlu pro domovskou složku a tak dále v řetězci, dokud v adresáři serp neuvidíme číslo uzlu pro požadovaný soubor. Pokud by najednou někdo chtěl zkontrolovat, zda je číslo správné a zda tam jsou potřebné informace, není to těžké. My ano:
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_imageVe výstupu si můžete přečíst názvy souborů v adresáři.
Dostávám se tedy k hlavní otázce: "z jakých důvodů může dojít k chybě záznamu?"
Přirozeně k tomu dojde, pokud v systému souborů nezůstanou žádné volné bloky. Co lze v tomto případě dělat? Kromě samozřejmého „smazání všeho nepotřebného“ byste si měli pamatovat, že v souborových systémech ext2,3 a 4 existuje něco jako „počet rezervovaných bloků“. Pokud se podíváte na výpis výše, máme „13094“ takových bloků. Jedná se o bloky, do kterých může zapisovat pouze uživatel root. ale pokud potřebujete problém rychle vyřešit, jako dočasné řešení je můžete zpřístupnit všem, což povede k volnému prostoru:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Tito. standardně máte 5 % místa na disku, které není k dispozici pro zápis, a vzhledem k objemu moderních disků to mohou být stovky gigabajtů.
Co jiného by to mohlo být? Je také možné, že existují volné bloky, ale nejsou zde žádné další uzly. K tomu obvykle dochází, pokud máte v systému souborů spoustu souborů, které jsou menší než velikost bloku systému souborů. Vezmeme-li v úvahu, že na 1 soubor nebo adresář je utracen 1 inode a celkem jich máme (pro daný souborový systém) 65536 - je situace více než reálná. To lze jasně vidět z výstupu příkazu 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/wwwJak je jasně vidět na oddílu /var/www, počet volných bloků v systému souborů a počet volných uzlů se velmi liší.
V případě, že vám dojdou inody, neřeknu vám žádná kouzla, protože... žádné nejsou (pokud se mýlím, dejte mi vědět). Takže pro oddíly, ve kterých se množí malé soubory, byste měli zvolit souborový systém moudře. Například btrfs inody nemohou skončit, protože V případě potřeby se dynamicky vytvářejí nové.
Zdroj: www.habr.com