Hallo,
aufgrund eines Datenverlustes nach Update auf QTS 4.3.4 build 0537 war ich gezwungen zur Wiederherstellung der Funktionsfähigkeit etwas Reverse-Engineering zu betreiben. Ich bin mir sicher, dass mir das nach deutschem Recht gestattet ist.
Entgegen dem hier dargestellten Post:
Erfahrungsbericht: Filesystem ext4 in einer Qnap TS-259 Pro
... bin ich für mein dafürhalten auf Unterschiede zum Standard "ext4" gestoßen.
Ich habe herausgefunden, dass QTS mindestens ein vom Standard abweichendes ext4-Feature-Profil verwendet. Das scheint zwar in ext4 vorgesehen, aber QTS schafft es nicht, sich konsistent zu verhalten, und zwar auch nicht z.B. im Build 0516:
- Im Gegensatz zum Linux-Default erzeugte das /sbin/mke2fs_64 von QTS 4.3.4 0516 (und 0537) bei allen meinen Tests ein ext4-Filesystem mit abgeschaltetem "dir_index"-Feature (überprüft mit "dumpfs")
- Obwohl nur "dir_index" aber abgeschaltet war, erzeugte in meinen Tests das QTS HTree-Einträge in den Directory-Inodes. Diese Einträge sind meiner aktuelle Ansicht nach widersprüchlich zur ext4-Spezifikation, weil eben "dir_index" abgeschalte ist.
- Das bestätigt die Dateisystem-Prüfung: e2fsck meldet diese HTree-Einträge als Fehler im Dateisystem. Und zwar sowohl e2fsck von einem Standard-Linux als auch das in QTS integrierte e2fsck meldeten bei mir diese Fehler. Und das sogar auf einem frisch installierten QTS 4.3.4 0516.
Meine Vermutung ist, dass QTS im besten Falle eine Feature-Kombination von ext4 verwendet, die sagen wir mal unüblich und daher wenig gestestet und daher vielleicht eben buggy ist. Vgl. hier: https://www.novell.com/support/kb/doc.php?id=7011432 Es kann natürlich auch andere Modifikationen als Grund haben.
Kennt ihr andere Anzeichen, wo QTS vom ext4-Standard oder gar der ext4-Spezifikation abweicht? Ich dachte das wäre vorbei:
Bildschirmfoto 2018-04-17 um 22.27.04.png
Mir ist das sehr wichtig! Ich muss sicherstellen, dass meine Daten in einem nicht-proprietären Format gesichert sind. Geht es Euch auch so?
VG
Holger