Etwas über Inode

Um zum zentralen Vertriebszentrum zu wechseln, führe ich regelmäßig Vorstellungsgespräche bei verschiedenen großen Unternehmen, hauptsächlich in St. Petersburg und Moskau, für eine DevOps-Stelle. Mir ist aufgefallen, dass viele Unternehmen (viele gute Unternehmen, zum Beispiel Yandex) zwei ähnliche Fragen stellen:

  • Was ist Inode?
  • Aus welchen Gründen können Sie einen Fehler beim Schreiben auf die Festplatte erhalten (oder zum Beispiel: Warum Ihnen möglicherweise der Speicherplatz ausgeht, das Wesentliche ist dasselbe).

Wie so oft war ich mir sicher, dass ich mich mit diesem Thema gut auskenne, aber sobald ich anfing zu erklären, wurden Wissenslücken deutlich. Um mein Wissen zu systematisieren, die Lücken zu schließen und mich nicht länger in Verlegenheit zu bringen, schreibe ich diesen Artikel, vielleicht ist er für jemand anderen nützlich.

Ich fange ganz unten an, d.h. von einer Festplatte (wir werden Flash-Laufwerke, SSDs und andere moderne Dinge verwerfen; betrachten wir zum Beispiel jedes 20 oder 80 GB alte Laufwerk, da die Blockgröße dort 512 Byte beträgt).

Die Festplatte weiß nicht, wie sie ihren Speicherplatz Byte für Byte ansprechen soll, er ist bedingt in Blöcke unterteilt. Die Blocknummerierung beginnt bei 0. (Dies wird LBA genannt, Details hier: ru.wikipedia.org/wiki/LBA)

Etwas über Inode

Wie aus der Abbildung ersichtlich ist, habe ich LBA-Blöcke als HDD-Ebene festgelegt. Welche Blockgröße Ihre Festplatte hat, können Sie übrigens so sehen:

root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512

Die Ebene darüber ist eine Partition, eine für die gesamte Festplatte (wieder der Einfachheit halber). Am häufigsten werden zwei Arten von Partitionsmarkierungen verwendet: msdos und gpt. Dementsprechend ist msdos ein altes Format, das Festplatten bis zu 2 TB unterstützt, gpt ist ein neues Format, das bis zu 1 Zettabyte an 512-Byte-Blöcken adressieren kann. In unserem Fall haben wir eine Partition vom Typ msdos, wie aus der Abbildung hervorgeht, beginnt die Partition mit Block Nr. 1, während für den MBR Null verwendet wird.

In der ersten Partition habe ich ein ext2-Dateisystem erstellt. Die Standardblockgröße beträgt 4096 Byte, was sich auch in der Abbildung widerspiegelt. Sie können die Blockgröße des Dateisystems wie folgt anzeigen:

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

Der Parameter, den wir brauchen, ist „Blockgröße“.

Der interessante Teil ist nun, wie liest man die Datei /home/serp/testfile? Eine Datei besteht aus einem oder mehreren Dateisystemblöcken, in denen ihre Daten gespeichert sind. Wenn Sie den Dateinamen kennen, wie finden Sie ihn? Welche Blöcke soll ich lesen?

Hier kommen Inodes zum Einsatz. Das ext2fs-Dateisystem verfügt über eine „Tabelle“, die Informationen für alle Inodes enthält. Die Anzahl der Inodes wird bei ext2fs beim Erstellen des Dateisystems festgelegt. Wir schauen uns die benötigten Zahlen im Parameter „Inode count“ der tune2fs-Ausgabe an, d.h. wir haben 65536 Stück. Der Inode enthält die Informationen, die wir benötigen: eine Liste der Dateisystemblöcke für die gesuchte Datei. Wie finde ich die Inode-Nummer für eine bestimmte Datei?

Der entsprechende Name und die Inode-Nummer sind im Verzeichnis enthalten, und ein Verzeichnis in ext2fs ist ein besonderer Dateityp, d. h. hat auch eine eigene Inode-Nummer. Um diesen Teufelskreis zu durchbrechen, wurde dem Root-Verzeichnis eine „feste“ Inode-Nummer „2“ zugewiesen. Schauen wir uns den Inhalt von Inode Nummer 2 an:

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

Wie Sie sehen, ist das von uns benötigte Verzeichnis in Blocknummer 579 enthalten. Darin finden wir die Knotennummer für den Home-Ordner und so weiter in der Kette, bis wir im Serp-Verzeichnis die Knotennummer für die angeforderte Datei sehen. Wenn jemand plötzlich überprüfen möchte, ob die Nummer stimmt und ob die nötigen Informationen vorhanden sind, ist das kein Problem. Wir machen:

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

In der Ausgabe können Sie die Namen der Dateien im Verzeichnis lesen.

Damit komme ich zur Hauptfrage: „Aus welchen Gründen kann es zu einem Aufnahmefehler kommen?“

Dies geschieht natürlich, wenn im Dateisystem keine freien Blöcke mehr vorhanden sind. Was kann in diesem Fall getan werden? Neben dem offensichtlichen „Löschen Sie alles Unnötige“ sollten Sie bedenken, dass es in ext2,3-, 4- und 13094-Dateisystemen so etwas wie „Reservierte Blockanzahl“ gibt. Wenn Sie sich die Auflistung oben ansehen, haben wir „XNUMX“ solcher Blöcke. Dabei handelt es sich um Blöcke, die nur vom Root-Benutzer beschreibbar sind. Wenn Sie das Problem jedoch schnell lösen müssen, können Sie sie als vorübergehende Lösung für alle verfügbar machen, wodurch etwas freier Speicherplatz entsteht:

root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)

Diese. Standardmäßig stehen 5 % des Festplattenspeichers nicht zum Schreiben zur Verfügung. Angesichts der Größe moderner Festplatten können dies Hunderte von Gigabyte sein.

Was könnte es sonst sein? Es ist auch möglich, dass es freie Blöcke gibt, aber keine Knoten mehr. Dies geschieht normalerweise, wenn sich in Ihrem Dateisystem eine Reihe von Dateien befinden, die kleiner als die Blockgröße des Dateisystems sind. Wenn man bedenkt, dass 1 Inode für 1 Datei oder 65536 Verzeichnis ausgegeben wird und wir insgesamt (für ein bestimmtes Dateisystem) XNUMX haben, ist die Situation mehr als realistisch. Dies ist deutlich an der Ausgabe des df-Befehls zu erkennen:

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

Wie auf der /var/www-Partition deutlich zu erkennen ist, variieren die Anzahl der freien Blöcke im Dateisystem und die Anzahl der freien Knoten stark.

Für den Fall, dass Ihnen die Inodes ausgehen, verrate ich Ihnen keine Zaubersprüche, denn ... Es gibt keine (wenn ich falsch liege, lass es mich wissen). Für Partitionen, in denen sich kleine Dateien vermehren, sollten Sie das Dateisystem also mit Bedacht wählen. Btrfs-Inodes können beispielsweise nicht enden, weil Neue werden bei Bedarf dynamisch erstellt.

Source: habr.com

Kommentar hinzufügen