Periodicamente, con l'obiettivo di passare al CRS, faccio colloqui in diverse grandi aziende, principalmente a San Pietroburgo e Mosca, per la posizione di DevOps. Ho notato che in molte aziende (in molte buone aziende, ad esempio in Yandex) vengono poste due domande simili:
- cos'è l'inode;
- per quali motivi si può verificare un errore di scrittura su disco (o ad esempio: perché si può esaurire lo spazio su disco, la sostanza è la stessa).
Come spesso accade, ero convinto di conoscere bene questo argomento, ma non appena ho iniziato a spiegare, le mie lacune sono emerse. Per sistematizzare le mie conoscenze, colmare le lacune e non mettermi più in imbarazzo, sto scrivendo questo articolo, forse potrà essere utile a qualcun altro.
Inizierò "dal basso", cioè dal disco rigido (escludiamo le unità flash, gli SSD e altre cose moderne, ad esempio, prendiamo in considerazione qualsiasi vecchio disco da 20 o 80 GB, poiché la dimensione del blocco è di 512 byte).
Il disco rigido non può indirizzare il suo spazio byte per byte, ma è convenzionalmente suddiviso in blocchi. La numerazione dei blocchi inizia da 0. (Questo è chiamato LBA, dettagli qui: )
Come puoi vedere dall'immagine, ho designato i blocchi LBA come livello HDD. A proposito, puoi vedere la dimensione dei blocchi del tuo disco in questo modo:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Il livello superiore è contrassegnato da una partizione, una per l'intero disco (di nuovo, per semplicità). Nella maggior parte dei casi, vengono utilizzati due tipi di marcatura delle partizioni: msdos e gpt. Di conseguenza, msdos è un vecchio formato che supporta dischi fino a 2 TB, mentre gpt è un nuovo formato che può indirizzare fino a 1 zettabyte di blocchi da 512 byte. Nel nostro caso, abbiamo una partizione di tipo msdos; come si può vedere dalla figura, la partizione inizia con il blocco n. 1, mentre il blocco n. XNUMX è utilizzato per MBR.
Nella prima sezione ho creato il file system ext2; di default, la dimensione del blocco è di 4096 byte, come si può vedere anche nella figura. Potete vedere la dimensione del blocco del file system in questo modo:
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-c898746ccd76Il parametro di cui abbiamo bisogno è "Dimensione del blocco".
Ora la cosa più interessante è come leggere il file /home/serp/testfile? Il file è costituito da uno o più blocchi del file system, che ne memorizzano i dati. Conoscendo il nome del file, come trovarlo? Quali blocchi leggere?
È qui che gli inode tornano utili. Il file system ext2fs ha una "tabella" che contiene informazioni su tutti gli inode. Il numero di inode nel caso di ext2fs viene specificato durante la creazione del file system. Controlliamo i numeri necessari nel parametro "Inode count" dell'output di tune2fs, ovvero abbiamo 65536 pezzi. L'inode contiene le informazioni di cui abbiamo bisogno: un elenco di blocchi del file system per il file che stiamo cercando. Come posso trovare il numero di inode per il file specificato?
La corrispondenza tra nome e numero di inode è contenuta in una directory, e una directory in ext2fs è un tipo speciale di file, ovvero ha anche un proprio numero di inode. Per interrompere questo circolo vizioso, alla directory radice è stato assegnato un numero di inode "fisso" "2". Diamo un'occhiata al contenuto dell'inode numero 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: 1Come potete vedere, la directory di cui abbiamo bisogno è contenuta nel blocco numero 579. In esso, troveremo il numero di nodo per la cartella home, e così via lungo la catena, fino a trovare il numero di nodo per il file richiesto nella directory serp. Se qualcuno volesse improvvisamente verificare se il numero è corretto e se le informazioni necessarie sono presenti, non è difficile. Facciamo quanto segue:
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_imageNell'output è possibile leggere i nomi dei file nella directory.
Quindi sono arrivato alla domanda principale: "per quali motivi può verificarsi un errore di registrazione"?
Naturalmente, questo accadrà se non ci saranno più blocchi liberi nel file system. Cosa si può fare in questo caso? Oltre all'ovvio "eliminare qualcosa di non necessario", è importante ricordare che nei file system ext2,3, 4 e 13094 esiste un "conteggio dei blocchi riservati". Se si guarda l'elenco sopra, ne abbiamo "XNUMX". Si tratta di blocchi disponibili in scrittura solo per l'utente root. Ma se si desidera risolvere rapidamente il problema, come soluzione temporanea è possibile renderli disponibili a tutti, in modo da liberare un po' di spazio:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Ciò significa che, per impostazione predefinita, il 5% dello spazio su disco non è disponibile per la registrazione e, dati i volumi dei dischi moderni, questa quantità potrebbe essere di centinaia di gigabyte.
Cos'altro potrebbe essere? Un'altra possibile situazione è quando si hanno blocchi liberi, ma i nodi sono spariti. Questo di solito accade se si hanno molti file nel file system che sono più piccoli della dimensione del blocco del file system. Considerando che 1 inode è dedicato a 1 file o directory, e ce ne sono 65536 (per questo file system), la situazione è più che reale. Questo può essere chiaramente visto dall'output del comando 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/wwwCome si può vedere chiaramente nella partizione /var/www, il numero di blocchi liberi del file system e il numero di nodi liberi differiscono notevolmente.
Nel caso in cui dovessi esaurire gli inode, non posso suggerirti alcun incantesimo, perché non ce ne sono (se sbaglio, fammelo sapere). Quindi, per le partizioni in cui si moltiplicano file di piccole dimensioni, dovresti scegliere un file system con attenzione. Ad esempio, in btrfs, gli inode non possono esaurirsi, perché ne vengono creati di nuovi dinamicamente quando necessario.
Fonte: habr.com
