Diesmal lag es weniger am Platz als daran, dass mein letztes Posting der aktuelle Fortschritt (Stand gestern Abend) war.
Danke auch für den Hinweis mit dem Blog. Das wäre vermutlich ein besserer Ort gewesen. Sehr viel gibt es eventuell eh nicht mehr zu schreiben...
fsck.ext4 läuft noch immer auf meinem PC (mit lesendem Zugriff über xmount auf die aktive VolumeGroup im QNAP und schreibendem Zugriff auf eine lokale Cache-Datei), aber meine Hoffnungen gehen gegen Null.
fsck belegt nach etwa 15 Stunden bereits wieder knapp 50G RAM
root@test:~# free -h
total used free shared buff/cache available
Mem: 54G 54G 373M 79M 139M 2,0M
Swap: 975M 143M 832M
# top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
36334 root 20 0 49,254g 0,048t 696 D 21,7 89,7 192:52.73 fsck.ext4
Und der aktuelle Fortschritt ist minimal:
Inode 1080925 block 16777392 conflicts with critical metadata, skipping block checks.
Inode 1080925 block 79167888 conflicts with critical metadata, skipping block checks.
Laut dumpe2fs habe ich einen Inode count von 318767104. Selbst wenn ich davon die 291766261 free inodes abziehe, dann bleiben noch immer 27000843 inodes übrig.
(Gedanke am Rande: warum eigentlich diese extrem hohe Zahl an free inodes? Das Filesystem kann doch nicht zu 91,5% leer sein? Hmm, vielleicht spiegelt das auch nur ein wenig die Anzahl der theoretisch möglichen Dateien wieder...)
Wenn ich gerade mit dem fsck bei Inode 1080925 bin, dann wären das gerade mal 4% Fortschritt - nach 15 Stunden. Könnte dann also in frühstens 15 Tagen mit einem Ende des Checks rechnen.
Zumindest wenn die Geschwindigkeit beibehalten werden kann und diese nicht (aufgrund des deutlich langsameren Swappings) in die Knie gehen sollte.
Werde heute Abend/Nacht nochmal einen Blick auf den Fortschritt werfen.
Mehr als 128 GB RAM kann ich zuhause nicht ohne weiteres bereitstellen. Und selbst das keine 2 Wochen ununterbrochen am Stück.
Hätte in meinem Keller-Testlab zwar noch einen älteren FSC-Server mit 144 GB RAM, aber das wäre auch nur minimal mehr und ich bekomme den Server auch nicht so einfach stabil mit Gigabit an das NAS angebunden.
Hätte alternativ eventuell noch die Möglichkeit die Platten (inkl. dem externen QNAP Gehäuse) im Rechenzentrum an ein Testsystem mit 1-2 TB RAM zu klemmen und dort für einen Check in eine VM durchzureichen.
Nur dann bräuchte ich erstmal eine VM, die dazu in der Lage wäre das properitäre LVM VolumeGroup von QNAP zu aktivieren.
Also doch noch einen Versuch starten den QNAP Kernel aus den Quellen zu bauen? Bin hier nur Extern verlinkte Datei entfernt! Mehr dazu siehe in den Forenregeln! weitergekommen. Hat das hier schonmal jemand mit einem aktuellen Kernel geschafft? Oder doch lieber versuchen einen Dump von dem installierten (ist ja x86 bzw. amd64) NAS zu ziehen und das komplette NAS irgendwie in einer VM zum Laufen zu bekommen?
Weiß momentan nicht was einfacher wäre... entsprechende Tools zum extrahieren der img-Dateien scheint es ebenfalls zu geben.
Oder doch noch schauen, ob ich mit dd einen zweiten Dump ziehen kann, der (muss dann aber auf das Byte genau sein!) an der Stelle fortsetzt, an der mit dem ersten Dump das 16TB Limit erreicht war? In dem Fall könnte ich mir die zwei (Teil-)dumps auf ein WD MyBook Duo Gehäuse mit einem RAID0 aus 2x10 TB (mehr habe ich leider momentan nicht greifbar) kopieren und so ins RZ bringen. Weiterer Aufwand, weitere Kosten. Dabei sind bereits die bisherigen Aufwände nicht mehr wirtschaftlich zu rechtfertigen...
Es geht inzwischen fast mehr um das "nicht aufgeben" wollen, als um die Sache selbst.
Weitere Ansätze:
Parallel habe ich übrigens noch ein zweites Loop-Device an die Quellen geklemmt (das ist das schöne bei xmount. Echt cooles Tool!) und mir das mit Testdisk und dem Sleuthkit (bzw. autopsy) angeschaut. Viel mehr als bei einem regulären mount sehe ich darauf aber auch nicht. Tools wie "r-explorer" und noch ein anderes (optisch fast identisches) Tool habe ich in der Demoversion ebenfalls probiert. Auch nicht mehr Erfolg als ein regulärer Mount.
Photorec und Co. brauche ich bei der Datenmenge erst garnicht probieren.
Sonst noch Ideen? Kann man fsck eventuell irgendwie beschleunigen bzw. den Inode-Check übergehen? Sehe beim Mount einen Teil der Ordner, aber kann sie nicht öffnen. Ein paar wenige Ordner lassen sich öffnen, aber die Dateien darin nicht lesen. Vermutlich hätte ich damals keinen "so frühen" (und vermutlich defekten) Superblock für den ersten fsck Versuch wählen sollen. Bei einem hinteren Block wäre das Ergebnis eventuell besser gewesen. Who knows?
Schalte jetzt erstmal etwas ab, mache einen Ausflug aufs Land und ein paar Kilometer Spaziergang mit meiner Partnerin.
Vielleicht wird der Kopf dann wieder etwas klarer
EDIT:
Okay, brauche nicht länger warten. fsck wurde wegen Speichermangel abgebrochen:
Inode 1080925 block 195560835 conflicts with critical metadata, skipping block checks.
Signal (6) SIGABRT si_code=SI_TKILL
fsck.ext4(+0x30d29)[0x5579032acd29]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7f47abbf2f20]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f47abbf2e97]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f47abbf4801]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x1362d)[0x7f47ac81962d]
fsck.ext4(+0x17ca7)[0x557903293ca7]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x144dc)[0x7f47ac81a4dc]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x14879)[0x7f47ac81a879]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x1533b)[0x7f47ac81b33b]
fsck.ext4(+0x1879c)[0x55790329479c]
fsck.ext4(+0x1a183)[0x557903296183]
fsck.ext4(+0x1a24c)[0x55790329624c]
/lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_get_next_inode_full+0x75)[0x7f47ac82e2a5]
fsck.ext4(e2fsck_pass1+0xa16)[0x557903296d36]
fsck.ext4(e2fsck_run+0x5a)[0x55790328fb2a]
fsck.ext4(main+0xda7)[0x55790328b857]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f47abbd5b97]
fsck.ext4(_start+0x2a)[0x55790328dafa]
Alles anzeigen
Edit:
Habe jetzt ein zweites dd-image für die restlichen 4 TB erstellt. Mit xmount lassen sich beide dd-images (16+4 TB) zusammen nutzen und über diverse dd-dumps (mit skip in die Nähe der Grenze der beiden Dumps und dann eine sha1sum über 1GB Daten) konnte ich nachweisen, dass xmount und der vg identisch sind.
Kopiere gerade das dd-image über usb 3.1 auf ein externes Gehäuse mit einem RAID0 aus 2x10 TB WD Platten. Die original-Platten archiviere ich dann mal für die nächsten 3-4 Wochen.
root@NAS:/share/HDDImage# dd if=image.ext4 of=extern/image.ext4 bs=4096 status=progress
3120753426432 bytes (3.1 TB, 2.8 TiB) copied, 7795 s, 400 MB/s
in etwa 10 Stunden sollte er mit der großen Datei fertig sein. Mal schauen wann ich dann das nächste Mal ins RZ komme...
PS @admins: sorry für die Verlinkung zu Pastebin. Die Kernelausgaben hätten sonst zu schnell das 10.000 Zeichen Limit gesprengt. Deshalb der Umweg zur externen Seite. Kommt nicht wieder vor.