Frage - gibt es bekannte QTS-Modifikationen an ext4?

    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:

    1. 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")
    2. 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.
    3. 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

    Folgende beiden zugesicherte Produkteigenschaften möchte ich in diesem Thread einmal überprüfen:


    Bildschirmfoto 2018-04-21 um 19.45.42.png


    • Punkt 1: Ist das intern verwendete Dateisystem ext4-kompatibel? Wenn nein, wo gibt es erkennbare Abweichungen?
    • Punkt 2: Ist das für externe Laufwerke unterstützte Dateisystem ext4-kompatibel? Wenn nein, wo gibt es erkennbare Abweichungen?

    Übersicht der Ergebnisse:


    Test-/Anwendungsfall Ergebnis internes Medium Ergebnis externes Medium
    QTS liest ein mit Linux erstelles ext4-Medium
    		 - kein realer Anwendungsfall - QTS mountet ext4 nicht von selbst (erkennt es nicht als gültig);
    kann aber über Kommandozeile gemountet werden
    QTS schreibt ein mit Linux erstelltes ext4-Medium
    		 - kein realer Anwendungsfall - - Tests ausstehend -
    (z.B. korrektes Pflegen der HTrees und Metadata-Checksum?)
    Linux liest ein mit QTS erstelltes ext4-Medium
    		 - Tests ausstehend -
    (z.B. invalide HTrees?)    		 - Tests ausstehend -
    (z.B. invalide HTrees?)
    Linux schreibt ein mit QTS erstelltes ext4-Medium
    		 - kein realer Anwendungsfall - - Tests ausstehend -



    Zu o.g. Punkt 2 habe ich aktuell folgendes Ergebnis:


    Ein mit einem aktuellen Linux formatiertes ext4-Dateisystem wird von QTS 4.3.4 0551 nicht unmittelbar unterstützt:

    Bildschirmfoto 2018-04-21 um 19.01.19.png

    Bildschirmfoto 2018-04-21 um 19.35.48.png


    Ich begebe mich jetzt auf die Suche, was die optionalen Features $2c0 sind, also $200 + $80 + $40, denke ich.

    Möglicherweise wurde das EXT4-Volume nur deshalb nicht gemounted, weil QTS zuerst versucht, das Medium als EXT3 zu interpretieren, und das schlägt dann fehl (vgl. hier). Mit der spezifischen Angabe "-t ext4" beim Mount-Befehl hat das Read-Only-Mounten dann geklappt.


    QTS 4.3.4 verwendet nach Auskunft von e2fsck die EXT2FS-Lib in der Version 1.42.13. Dies hat sich von 0515 auf 0551 auch nicht geändert:


    Bildschirmfoto 2018-04-21 um 20.09.12.png

    Hallo,


    leider konnte offenbar noch niemand etwas zu den offenen Fragen sagen. Für alle, die eventuell später hier landen:


    Mein Analysen breche ich an der Stelle an. Ich habe den letzten öffentlichen Stand der QTS-Sourcen (Februar 2018) mit dem zugehörigen Original-Kernel verglichen. QNAP macht nach meiner Auffassung einige Änderungen an ext4, z.B.:

    • Directory-Indizes für Case-Insensitive Suche, vermutlich für Windows-Kompatibiliät
    • Eigene ACLs (sog. RICH-ACLs), vermutlich für Windows-Kompatibiliät
    • Lazy-Init in nebenläufigen Threads
    • Änderungen an Tools wie e2fsck
    • usw.

    Im Ergebnis habe ich in meinen Test stets einige Kniffe zu tun, um QTS-Volumes mit Linux zu mounten und umgekehrt. Und ich ahne, dass man besser keine Schreibzugriffe auf so "über kreuz" gemountente Volumes durchführen sollte - insofern man einen RW-mount denn hinbekommt.


    Leider brauche ich für meine Daten einen Speicher, der zuverlässig funktioniert und im Ernstfall mit Standardtools abgerufen werden kann. Deshalb sind mir das in Summe zu viele Anpassungen. Allein der Source-Code "super.c", der die ext4-Metadaten beschreibt, hat 76 Änderungen gegenüber dem Original-Kernel bzgl Quota, Journal, ACL, Read-Only-Mode, Case-Insensitivität, Lazy-Init, Trim, Fehler-Handling, Ejection oder HAL. Darunter auch neue Flags, die IDs belegen, wo ich nicht herausfinden konnte dass diese für eigene Benutzung reserviert seien. Bei inode.c geht es dann weiter mit 46 Änderungen usw.


    Ich denke soweit reicht es aus, dass ich mir ein Bild machen konnte. Nichtsdestotrotz würde mich immer interessieren, inwieweit andere Nutzer Inkompatibilitäten erleben oder eben - sehr interessant - Workarounds dafür darstellen.

    Zitat von warpcam

    Evtl. ist es dann eine bessere Idee, die externen Platten mit normalem Linux zu formatieren statt mit dem NAS oder gleich NTFS einzusetzen.


    Das ist ein wirklich guter Punkt! Wie schon dargestellt ließen sich bei mir mit Koppix 8.1 formatierte ext4-Medien nicht ohne Weiters in QTS einbinden. Hinzu kommt die Sorge, dass diese beim Schreibzugriff durch QTS mit proprietären Aspekten (z.B. HTree-Einträge) inkonsistent werden könnten.


    Aber eventuell kann ja mal einer herausfinden, welche ext4-Features man beim Formatieren einer externen Platte setzen muss / nicht setzen darf, damit QTS und Linux die so formatierte Platte erkennen und wechselseitig fehlerfrei lesen und schreiben können?


    Das wäre doch schonmal ein erheblicher Fortschritt in der Interoperabilität.

    Zitat von Sumpfdotter

    Aber eventuell kann ja mal einer herausfinden, welche ext4-Features man beim Formatieren einer externen Platte setzen muss / nicht setzen darf, damit QTS und Linux die so formatierte Platte erkennen und wechselseitig fehlerfrei lesen und schreiben können?

    Ich hab jetzt mal meine externe Backup-Platte an den PC angeschlossen und per Linux (Desinfec't 2017, basiert auf Ubuntu 16.04.2 LTS) versucht darauf zuzugreifen. Das ging problemlos bereits über den automatischen Mount, der Zugriff über den Dateimanager. Schreiben hab ich nicht ausprobiert (ist ja meine Backupplatte), aber wenn das nicht ginge, hätte der Mount sicher gemeckert.


    Es gibt da aber dazu eine Historie, denn diese externe Platte wurde schon mit einem alten QTS 4.1.4 ext4 formatiert (TS-253pro). Damals gab es das neue Volume-Management noch nicht (und ich habe auch nicht umgestellt) und vermutlich deshalb noch keine so gravierenden Änderungen. Hier sind die File System Features, die damals gesetzt wurden (tune2fs -l /dev/sddXXund am PC-Ubuntu angezeigt werden. Damit läuft sie ohne Probleme auch unter QTS 4.3.4_0516.

    Zum Vergleich noch die Ausgabe des NAS: tune2fs -l /dev/sdcX


    Mount-Options lt. mount:

    /dev/sdc1 on /share/external/DEV3302_1 type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,data_err=abort,delalloc,nopriv,nodiscard,noacl)


    Zum Schluss noch die interne Platte, ebenfalls noch mit QTS 4.1.4 konfiguriert (Legacy-Volume ohne Snapshot-Unterstützung, kein RAID, Single-Drive). Ob sich diese Platte am PC lesen lässt, habe ich nicht ausprobiert. Diese Ausgabe wurde direkt auf dem NAS erzeugt:

    tune2fs -l /dev/mapper/cachedev1

    5 Mal editiert, zuletzt von warpcam ()

    Ich habe folgende Konstellation:
    - TS-231P 4.3.4.0435 vom 30.12.2017 mit 2x2TB HDD intern (scheint je ext4 lt. mount Optionen)

    - 2x2TB Backup ext4 mit QTS formatiert (glaube ich zumindest)

    - 1x 500GB HDD Cold Backup Storage NTFS formatiert mit QTS


    Die internen habe ich an Linux bisher nicht gemounted. Eine externe Backupplatte schon mehrmals unter aktuellen Arch (zum damaligen Zeitpunkt, da Arch ja öfters mal den Kernel aktualisiert :)). Mounten ging ohne Probleme über den Dateiexplorer und es waren auch alle Daten lesbar. Zudem konnte ich auch Dateien ohne Probleme auf die Backupplatte kopieren von einer anderen NTFS Platte. Es gab zumindest keine Fehler übers UI von GNOME.


    Testweise hatte ich auch einen 128GB USB Stick mit ext4 mit QTS formatiert und dieser war auch mit DiskInternals Linux Reader unter Windows 10 lesbar.


    Die NTFS Partition kann ich in meinen Windows PC einbauen und ist les- und schreibbar.


    Wenn ich irgendwie helfen kann oder Befehle ausführen soll, wenn ich wieder meine Backupplatten hole, probiere ich dies natürlich gerne.


    BTW: Was ich komisch finde laut 0551 Changelog kommt für meine AL CPU jetzt erst ext4?! - Was meinen die damit? Den Firmware Flash-Speicher?

    Zitat

    "This QTS update changes the file system of the system partition to ext4 for ARM-based models with Annapurna Labs processors. For data security reasons, you are not able to downgrade QTS to a previous version after this update."