Občas se ucházím o pozice DevOps v různých velkých firmách, většinou v Petrohradě a Moskvě, s cílem přestěhovat se do CRS. Všiml jsem si, že v mnoha firmách (v mnoha dobrých firmách, například v Yandexu) se pokládají dvě podobné otázky:
- co je inode;
- z jakých důvodů může nastat chyba zápisu na disk (nebo například: proč může dojít k vyčerpání místa na disku, podstata je stejná).
Jak to často bývá, byl jsem si jistý, že tuto téma znám dobře, ale jakmile jsem začal vysvětlovat — objevily se mezery v mých znalostech. Abych si systematizoval své znalosti, vyplnil mezery a už se neztrapňoval, píšu tento článek, snad se ještě někomu hodí.
Začnu «odspodu», tedy od pevného disku (flash disky, SSD a další moderní věci vynecháme, pro příklad vezmeme jakýkoli starý disk o velikosti 20 nebo 80 gigabytů, protože tam je velikost bloku 512 bytů).
Pevný disk neumí adresovat své místo po bytech, podmíněně je rozděleno na bloky. Číslování bloků začíná od 0. (tomu se říká LBA, podrobnosti zde: )
Jak je vidět z obrázku, bloky LBA jsem označil jako úroveň HDD. Mimochodem, velikost bloku vašeho disku lze zjistit takto:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Nad tímto úrovní je rozdělení, jedno na celý disk (opět pro zjednodušení). Nejčastěji se používají dva typy rozdělení: msdos a gpt. Msdo je starý formát podporující disky do 2Tb, gpt je nový formát schopný adresovat až 1 zettabajt 512 bytových bloků. V našem případě máme oddíl typu msdos, jak je vidět z obrázku, oddíl začíná s blokem č. 1, nula je použita pro MBR.
V prvním oddílu jsem vytvořil souborový systém ext2, jehož velikost bloku je ve výchozím nastavení 4096 bytů, což je také uvedeno na obrázku. Velikost bloku souborového systému lze zjistit takto:
root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4. února 2014)
Název objemu souborového systému:
Poslední připojeno:
UUID souborového systému: a600bf40-f660-41f6-a3e6-96c303995479
Magické číslo souborového systému: 0xEF53
Verze souborového systému: 1 (dynamická)
Funkce souborového systému: ext_attr resize_inode dir_index filetype sparse_super large_file
Příznaky souborového systému: signed_directory_hash
Výchozí možnosti připojení: user_xattr acl
Stav souborového systému: čistý
Chování při chybách: Pokračovat
Typ OS souborového systému: Linux
Počet inodů: 65536
Počet bloků: 261888
Počet vyhrazených bloků: 13094
Volné bloky: 257445
Volné inody: 65525
První blok: 0
Velikost bloku: 4096
Velikost fragmentu: 4096
Vyhrazené GDT bloky: 63
Bloky na skupinu: 32768
Framenty na skupinu: 32768
Inody na skupinu: 8192
Inodové bloky na skupinu: 512
Souborový systém vytvořen: Pá 2. srp 15:02:13 2019
Poslední čas připojení: n/a
Poslední čas zápisu: Pá 2. srp 15:02:14 2019
Počet připojení: 0
Maximální počet připojení: -1
Poslední kontrola: Pá 2. srp 15:02:13 2019
Kontrolní interval: 0 ()
UID vyhrazených bloků: 0 (uživatel root)
GID vyhrazených bloků: 0 (skupina root)
První inode: 11
Velikost inodu: 256
Požadovaná extra velikost: 28
Žádaná extra velikost: 28
Výchozí hash adresáře: half_md4
Seed hashe adresáře: c0155456-ad7d-421f-afd1-c898746ccd76Potřebný parametr je „Velikost bloku“.
Nyní je nejzajímavější, jak přečíst soubor /home/serp/testfile? Soubor se skládá z jednoho nebo více bloků souborového systému, ve kterých jsou uložena jeho data. Jak najít soubor podle jeho názvu? Které bloky číst?
Zde nám pomohou inody. V souborovém systému ext2fs existuje „tabulka“, která obsahuje informace o všech inodech. Počet inode v případě ext2fs je určen při vytváření souborového systému. Potřebná čísla najdeme v parametru „Počet inodů“ výstupu tune2fs, t.j. máme 65536 kusů. V inode jsou obsaženy potřebné informace: seznam bloků souborového systému pro požadovaný soubor. Jak najít číslo inode pro určený soubor?
Odpovídající jméno a číslo inode jsou obsaženy v adresáři, a adresář v ext2fs je soubor zvláštního typu, t.j. má také své číslo inode. Abychom přerušili tento začarovaný kruh, byla pro kořenový adresář přiřazena „pevná“ číslo inode „2“. Podívejte se na obsah inodu s číslem 2:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4. února 2014)
debugfs: stat
Inode: 2 Typ: adresář Režim: 0755 Příznaky: 0x0
Generace: 0 Verze: 0x00000000:00000002
Uživatel: 0 Skupina: 0 Velikost: 4096
File ACL: 0 Directory ACL: 0
Odkazy: 3 Počet bloků: 8
Fragment: Adresa: 0 Číslo: 0 Velikost: 0
ctime: 0x5d43cb51:16b61bcc -- Pá 2. srp 16:34:09 2019
atime: 0x5d43c247:b704301c -- Pá 2. srp 15:55:35 2019
mtime: 0x5d43cb51:16b61bcc -- Pá 2. srp 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- Pá 2. srp 15:02:14 2019
Velikost extra inodových polí: 28
BLOKY:
(0):579
CELKEM: 1Jak vidno, potřebná adresář se nachází v bloku s číslem 579. V něm najdeme číslo uzlu pro složku home, a tak dále po řetězci, dokud v adresáři serp neuvidíme číslo uzlu pro požadovaný soubor. Pokud by se někdo chtěl ujistit, zda je číslo správné a zda tam jsou potřebné informace, není to složité. Děláme:
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 lze přečíst názvy souborů v adresáři.
Tím jsem se dostal k hlavní otázce: „Jaké důvody mohou způsobit chybu zápisu“?
Samozřejmě k tomu dojde, pokud nezůstanou volné bloky souborového systému. Co v takovém případě dělat? Kromě zřejmého „smazat něco zbytečného“ je třeba si pamatovat, že v souborových systémech ext2,3 a 4 existuje něco jako „Počet rezervovaných bloků“. Pokud se podíváme na výpis výše, máme takových bloků „13094“. Tyto bloky jsou k dispozici pro zápis pouze uživateli root. Pokud však je třeba problém vyřešit rychle, jako dočasné řešení je možné je zpřístupnit pro všechny, čímž se vytvoří trochu volného místa:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Nastavení procenta rezervovaných bloků na 0% (0 bloků)To znamená, že ve výchozím nastavení máte pro zápis nedostupné 5% diskového prostoru, a vzhledem k objemům moderních disků to mohou být stovky gigabajtů.
Co dalšího může být? Další možná situace je, když volné bloky jsou, ale uzly došly. To se obvykle stává, pokud máte v souborovém systému spoustu souborů menších než velikost bloku souborového systému. Vzhledem k tomu, že na 1 soubor nebo adresář se utrácí 1 inode, a celkově jich máme (pro tento souborový systém) 65536 – situace je více než reálná. To je 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 dobře vidět na oddílu /var/www, množství volných bloků souborového systému a množství volných inodů se výrazně liší.
V případě, že dojdou inody, nemohu doporučit žádná kouzla, protože žádná nejsou (pokud se pletu, dejte mi vědět). Takže pro oddíly, ve kterých se množství drobných souborů šíří, je třeba pečlivě vybírat souborový systém. Například v btrfs inody nemohou dojít, protože se dynamicky vytvářejí nové podle potřeby.
Zdroj: habr.com
