Versuch: Datenrettung zerstörter Directories

  • Vorab für später hinzugekommene Leser: Hier gibt es eine Zusammenfassung der Ergebnisse

    --

    Hallo liebe Freunde,


    in diesem Thread versuche ich alle meine Erfolge und Misserfolge der Datenrettung zu dokumentieren (Datenverlust durch das Update auf 4.3.4.0537). Ob es gelingt, weiß ich noch nicht. Aber ich eröffne den Thread jetzt schon, damit Ihr evtl. Eure Erfahrungen ergänzen könnt.


    Vorab ein Hinweis, was ich womöglich "falsch" gemacht habe, womit ich meine Daten überhaupt erst zerstört habe:


    Nach dem Update auf 4.3.4.0537 (TS-251+, RAID1, 1 Thin Volume, vollverschlüsselt) hatte ich eine Vielzahl der hier im Forum gelisteten Probleme (Login-Probleme, Hänger beim Entschlüsseln oder Dateisystemcheck, korrupte Verzeichniseinträge auf der Festplatte usw.). Irgendwie hatte ich Glück, dass meine Daten vom Datenverlust nicht betroffen zu sein schienen, sondern nur ein Systemverzeichnis. Einem Foreneintrag folgend habe ich

    • ein Backup gemacht,
    • dann sichereitshalber ein Verify und
    • dann ein Downgrade auf 4.3.4.0516.

    Das "Downgrade" habe ich allerdings so gemacht, dass ich das ganze System neu aufgesetzt habe - ich wollte, dass keine Fehler zurückbleiben:

    • 4.3.4.0516 heruntergeladen und Checksumme geprüft,
    • dann über Webfrontend eingespielt (aber ohne Neustart)
    • dann mit fdisk alle Partitionsdaten gelöscht
    • dann 10-Sekunden-Reset
    • dann 4.3.4.0516 völlig frisch installiert

    Ich fürchte, dieses Vorgehen könnte ein gravierender Fehler gewesen sein. Es hat zwar dazu geführt, dass ich nun ein anscheinend funktionierendes noch leeres 0516er QNAP-System habe. Beim Versuch, meine Daten vom Backup zurückzuspielen stellte ich aber fest, dass nun mein zuvor erstelltes Backup zahlreiche korrupte Verzeichniseinträge hat. Mir fiel es wie Schuppen von den Augen: Das Backup hatte ich ja mit der defekten 4.3.4.0537 erstellt!


    Deshalb muss ich unbedingt darauf hinweisen, dass manche hier schreiben, dasss sie anders vorgangen sind: Sie haben zuerst das Downgrade gemacht (ohne Datenlöschung), dann waren die Verzeichniseinträge wieder in Ordnung.


    Möglicherweise sollte man also beides tun: Backup vor dem Downgrade, dann Downgrade, dann schauen ob die Daten auf der Platte wieder i.O. sind, und falls ja, noch ein Backup nach dem Downgrade. Dann kann man vergleichen, welches Backup saubere Daten enthält. Hier könnt ihr ja gerne mal bestätigen/dementieren.


    Ich jedenfalls habe nun nur noch einen Stand meiner Daten: den des vom 4.3.4.0537 erstellten Backups - und der ist korrupiert.


    Nun gehe ich auf die Suche, ob ich technische Möglichkeiten finde, diese Daten wieder lesbar zu machen. Wenn Ihr also hier eigene Erfahrungen habt, bitte gerne her damit. Z.B. wenn es Ideen gibt, was da überhaupt passiert ist. Dazu gehört für mich auch die Frage: Wie kann man heutzutage überhaupt eine Linux-Distribution so zusammenstellen, dass man es schafft, damit die ext4-Filesysteme derart zu korrupieren? Was hat QNAP da überhaupt gemacht? Z.B. ein falsche Compilerschalter bzgl. Byte-Order oder was auch immer. Das zu Wissen könnte helfen, die Daten zu retten. Ein Beispiel: Ich hatte mal ein Synology, das hat plötzlich im wahrsten Sinne des Wortes über Nacht angefangen alle Daten in vertauschter Byte-Order zu schreiben. Zunächst lief alles gut, weil fehlerhaft geschriebene Daten nicht neu eingelesen wurden - sie waren ja noch im RAM. Erst nach dem nächsten Reboot war das Filesystem nicht mehr interpretierbar, weil ja nun alle Blöcke, die jüngst geschrieben worden waren (z.B. das Root-Verzeichnis) in umgekehrter Byte-Order geschrieben waren. Als ich diese Ursache endlich irgendwann rausgefunden hatte, konnte ich loslegen und ein Programm schreiben, dass das ext4-Filesystem interpretiert und heuristisch erkennt, welche Blöcke es erwischt hat, und welche nicht. Es hat fast einen Sommer Freizeit gedauert, aber so bekam ich meine Daten zu 99,9% wieder. Danach bin ich zu QNAP gewechselt ... den Rest kennt ihr. Also: was ist hier überhaupt im Filesystem passiert? Das frage ich mich und Euch.


    Bevor ich anfange, meine einzige verbliebene Datenplatte zu analysieren, habe ich schonmal eine Frage: Ein Rettungsversuch könnte sein, die mit dem 4.3.4.0537 geschriebenen Daten bewusst nochmal mit dem 4.3.4.0537 auszulesen. Nun habe ich die 4.3.4.0537 aber garnicht mehr, und man kann sie ja offiziell auch nicht mehr downloaden. Hat einer noch einen Link auf die zurückgezogene 0537?


    Viele Grüße!

    Eine Antwort auf meine letzte Frage habe ich schon selbst gefunden:

    Die zurückgezogene Firmware kann man auch jetzt noch von QNAP herunterladen, wenn man einfach Datum und Nummer im Download-Link einer anderen Firmware passend ersetzt.

    Einmal editiert, zuletzt von Sumpfdotter () aus folgendem Grund: Sticky-Link zu den Ergebnissen eingefügt

  • Ganz ehrlich, wenn Dir die Daten wichtig sind würde ich Qnap kontaktieren und denen Dampf machen. Das man als Endbenutzer im Nebel herumstochern soll wie man seine Daten noch retten kann klingt für mich einfach nur grotesk. Am Ende machst Du einen irreversiblen Schritt zuviel/falsch und alles ist weg.

  • Natürlich ist es ein Weg, QNAP zu kontaktieren. Das habe ich auch getan. Wenn jemand hier von QNAP etwas hilfreiches hören sollte, bitte behaltet es nicht für Euch.


    Dieser Thread ist für diejenigen gedacht, die das Heft selbst in die Hand nehmen.


    Ich selbst mache mir keine Hoffnungen, dass eine zur Datenrettung hilfreiche Antwort von Seiten QNAP kommen wird. Ein Indiz ist für mich schon, dass ich zum ganzen Rückruf keinerlei offizielle Meldungen finde. Ich lasse mich gerne eines besseren belehren, oh bitte. Meine Erfahrungen sind anders. Bspw. hatte Apple-Care mir mal bei einem Software-Fehler des iPhone geraten, welches ein Restore vom Backup unmöglich machte: Machen Sie Screenshots von allen Einstellungen und dann einen Werksreset. Ich konnte nur antworten: Also vergessen wir ab sofort die Apple-Datensicherungslösung und machen stattdessen immer Screenshots? Was bleibt einem in solchen Fällen anderes übrig, als das Heft selbst in die Hand zu nehmen?

  • Sumpfdotter Ich habe hier schon die neuere Firmware nach dieser misslungenen 0537. Eigentlich nutze ich keine Verschlüsselung aber diesmal habe ich ein verschlüsseltes Volumen vor dem Update erstellt und kann zumindest bei meiner TVS-871U berichten, dass sich das Volumen damit entschlüsseln lässt.


    Mehr Details dann mit dem anstehenden Release.


    Stay tuned

    Christian

  • Analyse mit e2fsck ergibt drei Fehlerarten:


    1. Es wird moniert, dass viele Verzeichnisse HTree-Indizes enthalten, obwohl das Filesystem ohne HTree-Unterstützung eingerichtet sei. Und in der Tat, das zugehörige Flag "dir_index" taucht nicht in der Flag-Liste des Filesystems nicht auf. These: Klingt fast so, als wäre der HTree-Support nachträglich mit tunefs abgeschaltet worden (vgl. Artikel zu tunefs/HTree abschalten, Situation 2).


    2. Diverse MIN/MAX-Werte der HTrees werden als unzulässig moniert. These: Vielleicht passiert dies, wenn nach Abschalten der HTrees noch weiter in die Verzeichnisse geschrieben wurde?


    3. Diverse Dateien haben ungültige Dateidaten (Datum/Uhrzeit jenseits von gut und böse)

    Das erfordert weitere Prüfungen. Auf den ersten Blick versteuen sich diese Dateien über diverse Verzeichnisse und haben alle als Datum 1961-11-27 01:35. Das sind -255479100 Sekunden seit 1970, also in Hex 0xF0C5B2C4. Als vorzeichenlos gerechnet komme ich auf 02. Januar 2098. Mit all diesen Werten verbinde ich jetzt erstmal rein garnichts. Merkwürdig, dass dieser Wert sich an so verschiedenen Stellen wiederfindet.

  • christian

    Ich bin mir nicht sicher, ob dieser Test wirklich aussagekräftig ist - die Verschlüsselung ist ja nicht ganz pauschal kaputt in der 537 und es gibt ja auch offenbar genug Kisten, die das Update überlebt haben.


    Ich bin jedenfalls gespannt, mit welchen weiteren Details Du rausrückst, die jenseits des Changelog der Firmware stehen werden :-)


  • Sehr interessant. Ich habe die obigen Thesen weiter verfolgt. Während auf einem "normalen", unter Linux mit mkfs.ext4 erzeugen Volume das "dir_index"-Feature aktiviert ist, siehe hier:




    Fehlt dieses Flag auf den unter QTS mit mkfs.ext4 der GUI erzeugten Volumes, übrigens sowohl unter QTS 0516 als auch 0537:






    D.h. warum auch immer setzt QTS die Volumes ohne Verzeichnisindizierung auf. Aber obwohl abgeschaltet, entstehen existieren auf diesen QNAP-Volumes Directory-Indizes:




    Wenn ich stichprobenartig in die betroffenen Verzeichnisse schaue (0516er-Build), sind diese noch in Ordnung (keine Fragezeichen-Attribute bei "ls"). Warum es erst im 0537er zu Fehlern zu kommen scheint, falls dem so ist, wäre eine gute Frage. Möglicherweise gab es ja im ext4-Dateisystem eine Änderung, die ins QTS 0537 eingeflossen ist und die dafür sorgt, dass erst ab dem 0537 die (eigentlich abgeschalteten) Indizes inkonsitent werden.


    Mal angenommen, so ein Index veraltet. Das passt ziemlich genau zu dem was wir sehen: Die Dateien werden ohne Zuhilfenahme des Indexes gelistet, wenn man sie der Reihe nach ausgibt (z.B. ls-Befehl listet die Files auf), sie sind also noch da. Will man aber auf die Dateien zugreifen (Attribute oder Inhalte auslesen), geht er über den falschen Index und findet sie dann nicht mehr (z.B. ls-Befehl zeigt ???-Attribute).


    Deshalb die These: 0516 enthält ein ext4-FS, was die (eiglt. abgeschalteten Indizes) fälschlicherweise erstellt, pflegt und beim Auslesen verwendet. 0537 enthält ein ext4-FS (neue Version), was die (eigtl. abgeschalteten Indizes) nicht mehr korrekt pflegt (sind ja abgeschaltet), aber beim Auslesen immernoch verwendet.


    Das klingt abenteuerlich, aber für mich nicht unlogisch zu dem, was ich bei mir beobachten konnte. Noch nicht ganz passt für mich ins Bild, dass das Downgrade den Fehler behoben hat. Es sei denn, das Downgrade macht automatisch ein e2fsck.


    Wenn das alles so stimmt, könnten die Daten mit e2fsck vermutlich gut rettbar sein. dumpfs listet jedenfalls die zerstörten Verzeichnisse meiner Backup-Platte sauber auf - es umgeht sicher den Index. Unter QTS 0537 hatte e2fsck bei mir nun aber nicht korrekt repariert - es entstanden doppelte Verzeichniseinträge. Vielleicht versuche ich die Reparatur lieber mit einem e2fsck einer aktuellen Linux-Distribution.


    Habt ihr alle Eure Daten mittels e2fsck wiederbekommen können?

    Einmal editiert, zuletzt von Sumpfdotter () aus folgendem Grund: Fehler korrigiert

  • Sumpfdotter deine Ticket ID habe ich direkt an die Entwicklung weitergeleitet, sozusagen am Support vorbei. Vielleicht ist es dir auch möglich deine Erkenntnisse von weiter oben direkt ins Ticket einzufügen?


    sawachika das hast du nicht ganz Unrecht, allerdings sind die bisher gesammelten Informatione (abgesehen von den die Sumpfdotter hier mit uns teilt) sehr spärlich. Übrigens hat sich Sumpfdotter bisher als Einziger auf meinen Aufruf gemeldet https://forum.qnapclub.de/thre…?postID=291272#post291272

    https://forum.qnapclub.de/thre…?postID=291316#post291316

    https://forum.qnapclub.de/thre…?postID=291341#post291341


    Im Changelog wird es die folgenden weiteren Punkte geben:

    Zitat

    - Unlocking encrypted volumes would take a long time after the NAS restarted if users chose not to save the encryption key, and users would not be able to access certain applications.

    - Fixed a cross-site scripting vulnerability to prevent unauthorized access to sensitive information.

    - Users could not restore snapshots when accessing shared folders via Samba after adding the NAS to an Active Directory domain and enabling advanced folder permissions and Windows ACL.


    Betrachtet man das Problem global, so komme ich zu der Schlussfolgerung, dass ein derzeit überlasteter Support (Krankheit, Urlaub oder was auch immer) plus ein hohes Supportaufkommen über die Osterfeiertage gepaart mit der fehlerhaften Firmware mit der Ticketbearbeitung nicht nach kommt. Es ist also schwierig genau die Probleme heraus zu filtern, die für das Problem in der Firmware 0537 sorgen und somit ist es auch nicht 100% möglich eine Analyse zu fahren.


    Meine Annahme bestätigt sich dann aufgrund von E-mails, worin klar wird, dass die "suddenly reboot" Problematik so nicht bekannt war. Leider konnte ich dazu nur 3 Beiträge finden und weiterleiten:


    Grüße

    Christian

  • Hallo, danke Christian für die Diskussion. Bzgl. des "langsamen Aufschließens": Da hab ich völlig vergessen, was ich dagegen getan hatte. Eine Maßnahme war, dass ich alle Apps deaktivert habe.


    Das "langsame Aufschließen", das "Aufhängen beim File-System-Check", und "Datenverlust" könnten vielleicht die identische Ursache haben, nämlich die o.g. defekten Directory-Indizes. Das korrupte Dateisystem sorgt dafür, dass diverse Voränge nicht beendet werden (das ist defintiv so beim "Aufhängen beim File-System-Check") oder vielleicht ganz lansam ablaufen, weil sie in Time-Outs reinlaufen.


    Immer wenn ich glaube, was herausgefunden zu haben, hänge ich das Wesentliche auch noch ans Ticket an.


    Zur Dokumentation ein Versionsvergleich:

    • QTS 4.3.4 0516: mke2fs_64 1.42.13 (17-May-2015), using EXT2FS Library version 1.42.13 (QTS erzeugt kein DIR_INDEX)
    • QTS 4.3.4 0537: mke2fs_64 1.42.13 (17-May-2015), using EXT2FS Library version 1.42.13 (QTS erzeugt kein DIR_INDEX)
    • Knoppix 8.1: mke2fs 1.43.6 (29-Auf-2017), using EXT2FS Library version 1.43.6 (Knoppix erzeugt DIR_INDEX)

    3 Mal editiert, zuletzt von Sumpfdotter () aus folgendem Grund: Präzisiert

  • ich habe am 31.3. und am 1.4. hier von den kritishcen Fehler der Firmware und den Backups berichtet

    mit klarer warnung auf keinen Fall zu updaten und falls man es gemacht hat sofort downgraden


    jedes manuelle fixen zerstört wohl mehr als es repariert


    nachdem ich die downgrade lösung gefunen habe habe ich das hier auch mehrfach gepostet um andere zu retten und zu warnen

  • Laut Code-Review der mke2fs 1.42.13 gelten beim Erstellen folgende Default-Features: sparse_super,large_file,filetype,resize_inode,dir_index. Diese könnten überschrieben werden durch ein File /etc/mke2fs.conf, was es aber unter QTS nicht gibt, oder durch Kommandozeilenparameter.


    Ein einfacher Test verifiziert, dass das mke2fs von QTS sich auch per Default genau so verhält und dir_index aktiviert:

    [/share] # mke2fs_64 /dev/mapper/cachedev2



    Die Filesystem features sind per Default auch unter QTS also: ext_attr resize_inode dir_index filetype sparse_super large_file

    Nun wollte ich wissen, ob QTS evtl. per Kommandozeilenparameter diese Default-Werte überschreibt. Dazu habe ich ein großes Dateisystem per GUI anlegen lassen und dabei die Prozessliste überwacht:



    QTS verwendet keine Argumente, die das Erzeugen von dir_index verhindern.


    Daraus folgere ich: QTS erzeugt die Dateisystem zunächst mit aktiviertem dir_index.


    Wenn man sich ein mit QTS erzeugtes Dateisystem aber nach Fertigstellung betrachtet, ist dir_index wieder deaktiviert:




    Daraus folgere ich: QTS deaktiviert nach der Erzeugung das Feature dir_index wieder.






    D.h. QTS verwendet vermutlich "tunefs", um die Features nachträglich abzuändern. Bzgl. dir_index ist das gemäß o.g. Artikel keine gute Idee. Nun wäre es interessant zu verifizieren, ob tatsächlich diese tunefs-Aufrufe geschehen.


    Nachtrag: obige Folgerungen waren falsch. Ich habe übersehen, dass eben genau die Option "-t ext4" die entscheidene Option ist. Die Option "-t ext4" sorgt dafür, dass "dir_index" nicht gesetzt wird.

    Es bleibt aber auch dabei, bspw. unter Knoppix wird dir_index gesetzt, auch mit "-t ext4" (s.o.):



    nachdem ich die downgrade lösung gefunen habe habe ich das hier auch mehrfach gepostet um andere zu retten und zu warnen

    Hallo immo,


    der Hinweis an sich ist sehr hilfreich. Ich selbst würde nach erkanntem Datenverlust niemals noch mit Schreibzugriff auf die betroffenen Medien gehen. D.h. ich würde immer erst ein Backup der Daten (im Idealfall der kompletten Medien) machen, ehe ich weitere Schritte - z.B. ein Downgrade - unternehmen. Dieses Backup zu erstellen gestaltet sich aber nicht so einfach. Ich war so naiv, es mit QTS selbst zu erstellen. Vermutlich war dabei garnicht das Problem, dass ich die Daten mit QTS kopiert habe, sondern dass ich das Zieldateisystem von QTS einrichten ließ. Dass man ext4 überhaupt kaputtkonfigurieren kann, hatte ich nicht auf dem Schirm. Deshalb bleibe ich bei meiner Empfehlung, vor dem Downgrade ein Backup zu machen - nur eben bitte nicht unbedingt mit QTS, oder wenigstens nicht mit QTS das Zielmedium formatieren!


    Der "Filesystemcheck" bei QTS macht - übrigens ohne dass es für mich ersichtlich wäre - einen Reparaturversuch mit Schreibzugriff. Also hier teile ich auch die Empfehlung: Hände weg von diesem Knopf, ehe man nicht sein Volume dupliziert hat!

    D.h. QTS verwendet vermutlich "tunefs", um die Features nachträglich abzuändern. Bzgl. dir_index ist das gemäß o.g. Artikel keine gute Idee. Nun wäre es interessant zu verifizieren, ob tatsächlich diese tunefs-Aufrufe geschehen.

    Konkret führt QTS folgende Aufrufe durch:


    mke2fs_64 /dev/mapper/cachedev5 -t ext4 -K -q -m0 -F -b 4096 -i 16384

    tunefs_64 -i 0 -c 0 -r 131072 /dev/mapper/cachedev5

    tunefs_64 -L DataVol4 /dev/mapper/cachedev5

    2 Mal editiert, zuletzt von Sumpfdotter ()

  • Hi Sumpfdotter,


    Das Problem scheint bisher ja nur aufgetreten zu sein, wenn Verschlüsselung im Spiel war, tendenzeill dann, wenn der Key manuell eingegeben werden muss.


    Ich habe hier zwei Ideen warum das bei mir nicht schief ging - die erste Idee ist, dass ich ein unverschlüsseltes System-Volume nutze, damit QTS nicht bei jedem Reboot meckert, das irgendwelche Standard-Shares fehlen, die ich eh nicht nutze.

    Allerdings hätte ich erwartet, dass es dann eben kaputt gehen müsste, wenn ich mein Daten-Volume mounte. Das ist aber nicht passiert.

    Ich habe das auch verifiziert - ich kann jede Datei lesen und sie stimmt auch über Prüfsummen mit dem überein, was zuletzt vor dem 537er Release auf mein Backup-NAS geschrieben wurde.

    Die zweite Idee ist, dass ich sämtliche TS-431+/P2 im Januar/Februar komplett neu aufgesetzt habe.

    Möglicherweise wird im QTS schon eine ganze Zeit lang etwas anders gemacht und bsiher alte und neue Setups gleichermaßen verarbeitet?

    Und 537 hat jetzt einfach die alten Setups an dieser Stelle angleichen wollen - bei den ARM Kisten haben sie ja beispielsweise die System-Partition auf ext4 konvertiert, das war bei meinen Kisten aber gar nicht mehr notwendig.

    Vieleicht probierst Du daher deine Tests mal mit der Firmware, die dein NAS bei der Ersteinrichtung hatte und vergleichst das Verhalten mit der537er?

  • Hi Sawachika,

    Das Problem scheint bisher ja nur aufgetreten zu sein, wenn Verschlüsselung im Spiel war, tendenzeill dann, wenn der Key manuell eingegeben werden muss.

    Ja, das wundert mich auch. Ich bin gerade von den Symptomen rückwärts, also was sind das eigtl. für Fehler. Und da komme ich bis zu dem fehlenden "dir_index"-Feature bei gleichzeitigen HTrees auf dem Laufwerk (was nicht sein dürfte). Damit kann ich die Symptome mir erklärbar machen. Aber wie das mit den Auslösern (Eingabe des Kennworts) zusammenspielt, ist mir bislang ein totales Rätsel. Zumal ich bislang keine Unterschiede zwischen 0516 und 0537 erkenne - die ext4-Software-Version scheint identisch.

    Die zweite Idee ist, dass ich sämtliche TS-431+/P2 im Januar/Februar komplett neu aufgesetzt habe.

    Möglicherweise wird im QTS schon eine ganze Zeit lang etwas anders gemacht und bsiher alte und neue Setups gleichermaßen verarbeitet?

    Und 537 hat jetzt einfach die alten Setups an dieser Stelle angleichen wollen - bei den ARM Kisten haben sie ja beispielsweise die System-Partition auf ext4 konvertiert, das war bei meinen Kisten aber gar nicht mehr notwendig.

    Vieleicht probierst Du daher deine Tests mal mit der Firmware, die dein NAS bei der Ersteinrichtung hatte und vergleichst das Verhalten mit der537er?

    In diese Richtung habe ich tatsächlich auch schon gedacht. Ich gehöre zu denjenigen, die einen riesen-Softwaresprung gemacht haben. Ich hatte bestimmt mehrere Monate kein Softwareupdate gemacht. Es war reiner Zufall, dass ich Anfang April geupdated habe. Möglicherweise war der Sprung zu groß. Bestätigt wird das dadurch, dass ich die Dateisystemfehler (HTrees ohne dir_index-Flag) sofort auch auf dem 0516er-Build bekomme (s.o.). Allerdings ohne, dass der Fall einritt, dass die Indizes korrupt werden würden. Insofern wundert es mich auch total, dass das erst beim Sprung auf 0537 kaputtging.


    Wichtige Frage also: Die, die Probleme hatten - haben die alle einen größeren Update-Sprung gemacht?


    Oder hat jemand die Probleme tatsächlich auch beim Update von 0516 auf 0537 bekommen?

    So, an der Stelle steige ich jetzt aus. Ich kann - auch im Source-Code von mke2fsck - nicht nachvollziehen, warum dir_index nicht aktiviert wird, und warum trotzdem HTrees erzeugt werden, und warum es dann ab 0537 zu korrupten HTrees kommt, sofern Verschlüsselung im Spiel ist.


    Was ich nun glaube zu wissen ist, dass wenn ich die Indizes wegräume, meine Daten wieder i.O. sein müssten. Mal sehen, ob e2fsck das reparieren kann.


    Ich werde berichten. Dazu muss ich mir erst noch was bauen, weil ich nicht mal eben noch eine 6TB-Platte rumliegen habe zum clonen.


    Danke für die Diskussionen! Vielleicht geht's hier ja doch noch irgendwie weiter, wenn noch jemand eine zündendene Idee hat. Insbesondere dahindegehend, wie man QTS davon abhält, die Dateisystemfehler zu erzeugen. Mein frisch aufgestetztes 0516er zeigte die Dateisystemfehler nun ja auch, nur eben ohne sichbare Fehler zu erzeugen. So kann das mit QTS ja nicht bleiben. Ich werde deshalb sicher auch nicht auf einem 0516er aufsetzen.

    Mal eine Frage, ich hab mein QNAP gerade nicht am Laufen. Kann mal einer die Umgebungsvariablen auslesen, ob da die Variable MKE2FS_CONFIG gesetzt ist? Ansonsten hab ich gerade gesehen, dass der Distributionshersteller sein eigenes mke2fs-Profil reincomilieren kann. Vermute also mal, dass QNAP Abschalten von dir_index hart reincompiliert hat. Hm ... könnte man vielleicht im Hex-Editor von /sbin/mke2fs_64 sehen ... werde ich bei Gelegenheit mal reinschauen.

    Die zweite Idee ist, dass ich sämtliche TS-431+/P2 im Januar/Februar komplett neu aufgesetzt habe.

    Stimmt, ich hatte das vor Übernächtigung garnicht richtig interpretiert. Du meinst, dass womöglich alle, die ihr System ab Version XY aufgesetzt haben, verschont blieben, und alle, die ihr System davor aufgesetzt haben und dann fortschreitend upgedatet haben, es erwischt hat?


    Ich möchte auch nochmal in aller Deutlichkeit darauf hinweisen, dass auch ein frisch aufgesetztes 0516er-Build (aktuell von QNAP angebotenes Build) Filesystemfehler erzeugt! Nur eben welche, die im Betrieb nicht auffallen. Also wer will und kann sollte ruhig mal e2fsck laufen lassen. Aber nicht vom GUI aus. Da bekommt ja NULL ausgabe, und außerdem wird stillschwiegend gleich wieder repariert. Mir kommt das System wie eine tickende Zeitbombe vor: Es entstehen konsistente HTrees - alles gut. Bis man irgendwas komisches auslöst. Nach der Passworteingabe zum Aufschließen laufen ja sicher die ganzen Skripte los, um die Anwendungen zu starten usw. Bei mir startet da dieser "rm -r"-Befehl. Vielleicht geht ja dann erst ein HTree kaputt. Und vielleicht ist dieser Trigger erst unter 0537 eingebaut worden, wohingegen die Zeitbombe in allen Dateisystemen tickt ... nur so ein Gedanke ...

    SUMMARY (posted to QNAP)


    Let me summarize my research:


    1.) In contrast to the linux default, the mke2fs_64 binary of QTS 4.3.4 0516 (and 0537 as well) creates ext4 filesystems without "dir_index" feature enabled (tested with /sbin/mke2fs_64 -t ext4 and then dumpfs)

    2.) Without "dir_index", ext4 should not create HTrees. But there will appear HTrees!! This is a bug, and even e2fsck will find and list these HTrees as errors! Note - this also happens on a freshly installed QTS 4.3.4 build 0516, not only 0537! Assumption: Maybe, QTS uses some feature combination of ext4 that is not well tested and therefore buggy (see https://www.novell.com/support/kb/doc.php?id=7011432)

    3.) In most cases, all HTrees seem to be consistent. So no errornous behaviour results from these illegal HTrees.

    4.) But case of some triggers - I don't know which ones, but it might have something to do with unlocking an encrypted device in 0537 by entering the password - the HTrees might get inconsistent. This happened on my main data volume.

    5.) Also if you take an external volume, format (and in my case encrypt) it with QTS 0537, there might appear inconsistent HTrees on the external volume. This happened on by backup drive.

    6.) If there are HTrees (see 2.), the ext4 filesystem of QTS seems to use them when reading the filesystem, even though "dir_index" is disbaled. And the result is:

    7.) If there are inconsistent HTrees (see 4./5.), the content of the corresponding directories can be listet (no HTree is used when iterating over the directory entries), but the files inside the directory cannot be accessed (Htrees are used to quickly navigate to the directory entry). And this behaves like a data loss.

    8.) I HOPE (not yet tested) the HTrees can be removed by e2fsck. And after that, the files can be accessed again. But e2fsck of 0537 was not able to repair the directories! Afterwards, there were no HTrees anymore, but there now were duplicate directory entries. And BTW, the inconsistent directory entries reappeared when files have been accessed. Very crazy. But debugfs of Knoppix 8.1 can list the files, so I HOPE that e2fsck of Knoppix might fix it. I'd let you know.

    9.) But nevertheless, even if the data gets saved, the QTS filesystems always are without the "dir_index" feature and therfore the illegal HTrees will appear again. Including the risk that they get inconsistent.


    So please, QNAP:

    Do something regarding to the "dir_index" feature, please do not only fix the symptom that the illegal HTrees get inconsistent. Please also fix that either the illegal HTrees will not appear, or that you decied to use HTrees explictly by enabling the dir_index-feauture - which is linux standard behaviour! Please care about connecting external ext4 volumes to other comupters. So other computers might produce the same bugs when dealing with the QTS feature combination and vice versa, QTS must be able to deal with the default feauter combination when other drives are connected, anyway.



    Regards

    Holger

  • Ich hatte meine externe Backup-Platte mit QTS formatiert. Jetzt versuche ich die Platte am Linux-PC zu mounten, aber der findet schon die Partition nicht und moniert, dass das MSDOS-Format bei einer 6TB-Platte nicht funktionieren kann:



    Im Forum finde ich nix zum Thema Partition Table bei QNAP. Any hints?

    Also, zur Dokumentation: Ich habe per Hexdump ein "EFI" bei Offset $1000 und ein "LUKS" bei $30000 gefunden ... mal sehen, ob ich die Partitionstabelle neu schreibe oder einen Weg finde, das Luks mit Offset zu mounten ...

    Krass. Habe soeben das Tool "dmsetup" kennengelert. Mittels "sudo dmsetup create luksi --table '0 <nrOfSectors> linear </dev/sdx> 384'" konnte ich ein passendes Blockdevice anlegen (384 * 512 = $30000). Danach luksOpen und ab geht die halluzi.

    Habe nun mit dem e2fsck von Linux das Filesystem aufgeräumt. Die gelisteten Fehlermeldungen waren (hatte ich glaube ich schonmal geschrieben):

    • Die Existenz unzähliger HTrees wurde moniert (dir_index ist nicht aktiviert)
    • Unzählige HTree-Einträge wurden als korrput gemeldet (MIN/MAX-Überschreitung)
    • Etliche Datei-Zeitstempel wurden als vermutlich falsch gemeldet, weil >Jahr 2038 (das könnte aber an meinen Daten liegen)

    Jetzt sind noch einige Kopieraktionen nötig, ehe ich wirklich auf die geretten Daten schauen kann.