On Thursday 06 November 2003 00:17, David Haller wrote:
Und gerade der Superblock (warum heisst der gerade _super_block?) ist eben entscheidend.
Das e2fsck verwendet nur minimale Informationen aus dem Superblock, wenn es ein Dateisystem rekonstruiert. Bei Verwendung von Defaultparametern ist der Superblock für die Rekonstruktion des Dateisystems sogar vollkommen unnötig. Genauer (Stand Ende 1996): $ agrep -d'$' "statistischen Daten der Blockgruppe" ~/Diplom/tex/*tex Die statistischen Daten der Blockgruppe können leicht durch eine Dateisystemprüfung regeneriert werden. Die Startadressen der Bitmaps und der Inodetabelle sind bei perfekten Medien vorhersagbar: Sie belegen immer die ersten freien Blöck einer Blockgruppe. Lediglich bei Medien mit fehlerhaften Blöcken kann es vorkommen, daß die Lage der Bitmaps und der Inodetabelle verschoben ist -- bei modernen Medien erfolgt das Managment defekter Blöcke jedoch festplattenintern, sodaß dieser Fall praktisch niemals auftritt. Es ist daher im Prinzip nicht notwendig\footnote{Man kann dies demonstrieren, indem man ein existierendes ext2--Dateisystem mit {\tt mke2fs -S} {\it gerätebezeichnung\/} neu anlegt. Dieser Aufruf überschreibt nur die Superblock--Kopien und alle Deskriptor--Kopien, während Bitmaps und Inodetabellen unangetastet bleiben. Ein anschließender Aufruf von {\tt e2fsck -f} {\it gerätebezeichnung\/} stellt das Dateisystem wieder her.}, die Deskriptorinformationen jedesmal komplett in jeder Blockgruppe zu replizieren. Dazu kommt, daß diese Informationen für jeweils 32 Blockgruppen einen Datenblock belegen und daher bei steigender Dateisystemgröße einen immer größeren Anteil des Dateisystems durch eigentlich unnötige Verwaltungsinformationen belegen. Das geht auch heute noch (*1). Wie Du siehst, wird in (*1) genau gar keine Information aus den Superblocks verwendet außer der Information über die Größe der Blockgruppen (alles andere ist ja überschrieben worden). Wenn die Information über die Größe der Blockgruppen regeneriert werden kann (weil der Default verwendet worden ist), kann man das Dateisystem auch ganz ohne Superblock, ohne Descriptortabellen und ohne Inode- und Blockbitmaps neu erzeugen. Notwendig sind aber eine vollständige Inodetabelle an bekannten Positionen und vollständige Datenblöcke, insbesondere vollständige Datenblöcke der Verzeichnisstrukturen. e2fsck baut dann Superblock, Blockgroup-Descriptors und Inode- und Block-Bitmaps komplett neu auf. Die Robustheit von ext2 basiert also einzig und alleine auf der statischen Natur des Dateisystems: Da beim Anlegen des Dateisystems alle Inodes angelegt und platziert werden müssen, kann man aus der Blocknummer im Dateisystem die Rolle des Blocks im Dateisystem ableiten (Metadatenblock oder Datenblock). Die Regeneration des Dateisystems ist dann lediglich eine Anwendung der ext2-Mapping-Iteratoren über die Metadatenstrukturen. Alle dynamischen Dateisysteme müssen diese implizite Information darüber, was Daten und was Metadaten sind, aufgeben. Das gilt nicht nur für reiserfs, xfs oder vxfs, sondern das galt auch für die ext2-Modifikation, die ich 1996 ext3 nannte: ----- \chapter{Zusammenfassung und Ausblick} \label{kap07ausblick} \section{Zusammenfassung} Ziel dieser Arbeit war es, die Anzahl der Inodes in einem UNIX--Dateisystem dynamisch zu gestalten. Es sollte ein lauffähiges Dateisystem geschaffen werden, das mit einer kleinen Anzahl von Inodes angelegt wird und zur Laufzeit selbsttätig und ohne Eingriff eines Systemverwalters nach Bedarf weitere Inodes beschafft und gegebenenfalls wieder freigibt. Zu diesem Zweck wurden das Linux--ext2--Dateisystem und die zu diesem Dateisystem gehörenden Werkzeuge analysiert. Auf der Grundlage des Kernelquelltextes für das ext2--Dateisystem wurde ein formales Modell des Dateisystems beschrieben. Dabei wurde ein besonderer Schwerpunkt auf die Aspekte der Block-- und Inodeverwaltung gelegt, während die Verwaltung von Verzeichnisstrukturen bewußt ausgeklammert wurde, da dies für das angestrebte Ziel unerheblich war. Das Modell des Dateisystems wurde anschließend so verändert, daß es nicht mehr mit einer Inodetabelle statischer Größe und Positionierung arbeitet, sondern statt dessen die Inodetabelle und die Inodebelegungsbitmap in regulären Dateien handhabt. Im Gegensatz zur statischen Inodetabelle des Ausgangsdateisystems lassen sich diese Datenstrukturen dynamisch nach Bedarf erweitern und modifizieren und sind damit zur Darstellung einer veränderlich großen Anzahl Inodes geeignet. Der Inodeallokator des Modelldateisystems wurde um Funktionen zur Vergrößerung und Verkleinerung dieser Dateien erweitert, d.h. das Modell des Dateisystems wurde so verändert, daß es tatsächlich neue Inodes beschafft, wenn die bisherige Inodetabelle erschöpft ist, und daß mehr benutzte Inodeblöcke wieder freigibt. Die Änderungen am Modell des Dateisystems wurden am Kernelquellcode und an den Hilfsprogrammen zur Dateisystemwartung nachvollzogen. Es entstand ein neues Dateisystem mit der Bezeichnung ext3 für den Linux--Kernel, Version 2.0. Dieses Dateisystem erfüllt die Anforderung, zur Laufzeit selbsttätig weitere Inodes zu beschaffen und nicht mehr genutzte Inodeblöcke wieder freizugeben. Der Durchsatz desneuen Dateisystems ist mit der Leistung des originalen ext2--Dateisystems vergleichbar, sofern die aggressive Vorbestellung von Blöcken nicht verwendet wird. Mit aggressiver Vorbestellung von Blöcken erzeugt das neue Dateisystem besser zusammenhängende Dateien, aber die Systemleistung sinkt in einigen pathologischen Fällen erheblich. Im modifizierten Dateisystem ist nicht mehr wie im Ausgangsdateisystem vorhersagbar, an welchen Stellen des Mediums die Inodetabelle gespeichert ist. Die Kenntnis dieser Information ist jedoch im Falle eines beschädigten Dateisystems für Reparaturversuche am Dateisystem essentiell. Das neue Dateisystem ist daher gegenüber Beschädigungen der Inodetabelle empfindlicher als das Ausgangsdateisystem --- ohne Kenntnis der Metainformationen aus der Inode dieser Datei ist das modifizierte Dateisystem praktisch nicht mehr zu reparieren. Wünschenswert wären Mechanismen, die das Dateisystem gegenüber solchen Beschädigungen unempfindlicher machen oder generell die Möglichkeiten zur Rekonstruktion von beschädigten Dateisystemen verbessern. ------ reiserfsck (3.6) hat genau diese verbesserten Mechanismen zur Rekonstruktion von beschädigten Dateisystemen: reiserfs markiert nämlich im Gegensatz zu meinem damaligen ext2-mod alle Metadatenstrukturen mit Magic Bytes, und reiserfsck kann auf diese Weise auch bei Verlust der Datei, die das Reiserfs-Äquivalent der Inodetabelle enthält, das Dateisystem wieder zusammensetzen.
reiserfsck löst ebenso wie e2fsck Dateien mit doppelt allozierten Blöcken ("Crosslinks") durch Duplizierung der betreffenden Blöcke auf. Die verwendeten Strategien sind genau spiegelbildlich, und sie funktionieren gut, wie ich leider vorgestern testen konnte.
*hehe* Was war denn?
Das war 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge und 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) mit einem /usr/share/doc/nvidia/NVIDIA-Linux-x86-1.0-4496-pkg2.run und valiant:~ # grep AGP /etc/X11/XF86Config Option "NvAGP" "1" das zu einem Totalstillstand des Systems geführt hat, nach dem valiant:~ # df -Th Filesystem Type Size Used Avail Use% Mounted on /dev/hdb3 reiserfs 7.7G 4.1G 3.6G 54% / /dev/hdb1 ext2 30M 6.2M 23M 22% /boot /dev/hdb5 reiserfs 29G 19G 11G 65% /home /dev/hdd1 xfs 75G 60G 16G 80% /export/disk1 geschreddert waren. / war "reiserfsck --fix-fixable" und danach ein im Prinzip unbeanstandetes "rpm --verify -a". Aber /home war ein "reiserfsck --rebuild" (/boot und /export/disk1 sind sowieso Scratchdisks und können jederzeit regeneriert werden). reiserfsck --rebuild macht im Grunde genommen ganz genau das, was e2fsck macht: Es durchsucht die Platte nach den Datenstrukturen des Dateisystems und baut daraus den gesamten Dateibaum neu, dann schiebt es seine Mapping-Iteratoren darüber, um die Invarianten zu testen und bekommt eine validierte neue Datenstruktur. Der einzige Unterschied zwischen e2fsck und reiserfsck (3.6) besteht darin, daß reiserfs nicht implizit die Rolle eines Datenblocks aus der Blocknummer ableiten kann, sondern auf Magic Bytes in den Blöcken angewiesen ist. Dementsprechend findet es nicht nur die Datenstrukturen von /dev/hdb5, sondern auch die Datenstrukturen von /home/kris/VMware/suse82/suse82.vmdk und /home/kris/tmp/looptest, die auf /dev/hdb5 aka /home lagen - aus der Sicht des ursprünglichen /dev/hdb5 sind das aber Datenstrukturen, keine Metadatenstrukturen gewesen, aber das kann ein Rebuild nicht wissen und nicht ableiten. Weil diese so gefundenen Blöcke aus Containerfiles im Rahmen der Struktur von /dev/hdb5 nicht konsistent untergebracht werden (Kunststück :-), hängt reiserfsck sie in /home/lost+found ab, und ich habe nach dem erfolgreichen Rebuild des Dateisystems erst mal 800 MB Schmutz aus /home/lost+found putzen können - für das reiserfsck waren das vmdk und das looktest nämlich ein einziger, gigantischer Crosslink, den es auflösen mußte. Wie auch immer, Deine Angst vor reiserfs ist - zumindest mit 3.6 - ziemlich unbegründet. reiserfsck 3.6 ist unfreiwillig getestetermaßen ziemlich komplett und auch in der Lage, aus inkonsistenten und widersprüchlichen Trümmern die Originalstrukturen zu rekonstruieren. Kristian (*1) valiant:~ # dd if=/dev/zero of=/tmp/x bs=1024k count=100 100+0 records in 100+0 records out valiant:~ # mke2fs /tmp/x mke2fs 1.34 (25-Jul-2003) /tmp/x is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 25688 inodes, 102400 blocks 5120 blocks (5.00%) reserved for the super user First data block=1 13 block groups 8192 blocks per group, 8192 fragments per group 1976 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 32 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. valiant:~ # mount -t ext2 -o loop /tmp/x /mnt valiant:~ # for i in `seq 1 100`; do cp /etc/termcap /mnt/$i; done valiant:~ # ls /mnt . 12 18 23 29 34 4 45 50 56 61 67 72 78 83 89 94 lost +found .. 13 19 24 3 35 40 46 51 57 62 68 73 79 84 9 95 1 14 2 25 30 36 41 47 52 58 63 69 74 8 85 90 96 10 15 20 26 31 37 42 48 53 59 64 7 75 80 86 91 97 100 16 21 27 32 38 43 49 54 6 65 70 76 81 87 92 98 11 17 22 28 33 39 44 5 55 60 66 71 77 82 88 93 99 valiant:~ # df -Th /mnt Filesystem Type Size Used Avail Use% Mounted on /tmp/x ext2 97M 85M 7.1M 93% /mnt valiant:~ # umount /mnt valiant:~ # mke2fs -S /tmp/x mke2fs 1.34 (25-Jul-2003) /tmp/x is not a block special device. Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 25688 inodes, 102400 blocks 5120 blocks (5.00%) reserved for the super user First data block=1 13 block groups 8192 blocks per group, 8192 fragments per group 1976 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729 Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 22 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. valiant:~ # e2fsck -y -f /tmp/x e2fsck 1.34 (25-Jul-2003) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(1--8192) Fix? yes Free blocks count wrong for group #0 (7941, counted=0). Fix? yes Free blocks count wrong for group #1 (7941, counted=0). Fix? yes Free blocks count wrong for group #2 (7943, counted=0). Fix? yes Free blocks count wrong for group #3 (7941, counted=0). Fix? yes Free blocks count wrong for group #4 (7943, counted=0). Fix? yes Free blocks count wrong for group #5 (7941, counted=0). Fix? yes Free blocks count wrong for group #6 (7943, counted=0). Fix? yes Free blocks count wrong for group #7 (7941, counted=0). Fix? yes Free blocks count wrong for group #8 (7943, counted=0). Fix? yes Free blocks count wrong for group #9 (7941, counted=0). Fix? yes Free blocks count wrong for group #10 (7943, counted=547). Fix? yes Free blocks count wrong (99150, counted=12336). Fix? yes Free inodes count wrong for group #0 (1976, counted=1865). Fix? yes Directories count wrong for group #0 (0, counted=2). Fix? yes Free inodes count wrong (25688, counted=25577). Fix? yes /tmp/x: ***** FILE SYSTEM WAS MODIFIED ***** /tmp/x: 111/25688 files (9.9% non-contiguous), 90064/102400 blocks valiant:~ # mount -t ext2 -o loop /tmp/x /mnt valiant:~ # ls /mnt . 12 18 23 29 34 4 45 50 56 61 67 72 78 83 89 94 lost +found .. 13 19 24 3 35 40 46 51 57 62 68 73 79 84 9 95 1 14 2 25 30 36 41 47 52 58 63 69 74 8 85 90 96 10 15 20 26 31 37 42 48 53 59 64 7 75 80 86 91 97 100 16 21 27 32 38 43 49 54 6 65 70 76 81 87 92 98 11 17 22 28 33 39 44 5 55 60 66 71 77 82 88 93 99 valiant:~ # df -Th /mnt Filesystem Type Size Used Avail Use% Mounted on /tmp/x ext2 97M 85M 7.1M 93% /mnt valiant:~ # umount /mnt valiant:~ # rm /tmp/x -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG