Beiträge von Sumpfdotter

Hallo Salegy,

danke für den Tipp. Ich kann mir vorstellen, dass Thick-Provisioning kompatibel ist - vielleicht greift deshalb das Tool. Das Thin-Provisioning ist es jedenfalls nicht. Auch nachdem ich in den Metadaten des Laufwerks alle als unbekannt monierten Einträge rausgenommen habe, konnte Linux das nicht mounten. Auch finde ich in den von QNAP bereitgestellten QTS-GPL-Sourcen keine entsprechende Anpassung des LVMs, d.h. ich komme da nicht weiter.

Ob das von Dir vorgestellte Tool auchThin-Provisioning kann, wäre interessant. Ich selbst höre an der Stelle jetzt mal auf und werde wenn überhaupt nur noch Raw benutzen - in der Hoffnung, dass daran nix gepatched wurde.

VG!

Holger

Hallo,

wenn ich eine unter QTS mit Thin-Provisioning erstellte Partition versuche unter Linux einzubinden, beschwert sich der Logical Volume Manager von Linux, dass er mit der Partition so nichts anfangen kann:

WARNING: unrecognized segment type tier-thin-pool
LV tp1, segment 1 invalid: does not support flag ERROR_WHEN_FULL. for tier-thin-pool segment.
Internal error: LV segments corrupted in tp1.

QTS hat offensichtlich ein proprietäres LVM-Format. D.h. Datenzugriff und/oder -rettung ist erstmal mit Standard-Tools nicht möglich? Man muss schon Programmierer sein und in die QTS-Patches des Linux-Kernels eintauchen und so eigene Tools entwickeln, wenn außerhalb von QTS zugreifen möchte? Hat jemand Tipps und/oder Tools parat?

Viele Grüße

Holger

Ergänzung hier, weil ich eine neue Frage nicht in einen neuen Post stellen darf (Verbot des Doppelposts):

Weiß jemand, ob Thick-Provisioning kompatibel wäre? Dann könnte man darauf umschwenken, wenn einem die Kompatibilität wichtig ist.

Ich kann nur versuchen, mich zu wiederholen: Ich hatte nach dem Auftreten des Fehlers meine Daten von QTS auf ein USB-Backup-Laufwerk gesichert, und dann sogar verifiziert. Danach die primären Datenträger neu aufgesetzt. Beim Restore vom USB-Backup dann der Schock: Das Filesystem im Backup-Laufwerk hatte ebenfalls korrupte Dir-Indizes, und damit war auch das Backup erstmal beschädigt, und zwar dieses Mal auch in meinen Nutzdaten.

Das muss nicht heißen, dass bei Dir das gleiche passiert. Immerhin hatte ich das 0537er Build und als Ziel-Dateisystem das QTS-ext4. Wenn Dein USB-Laufwerk ein anderes Datei-System hat, hast Du vielleicht bessere Karten. Oder Du hast bessere Karten, weil Du das 0515er zum Kopieren verwendest.

Wenn Du ein Backup hast, dann greife nicht mit QNAP darauf zu. So hab ich mein Backup auch noch zerschossen.

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:

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

Wenn Du die Fragezeichen hast, dann kann ich Dir den oben zitierten Thread empfehlen. Die Verzeichnisse Deines ext4-Dateisystems sind so denke ich in einem inkonsistenten Zustand: Es gibt korrupte, sog. HTree-Indizes. Glücklicherweise sind diese Indizes redundant und man kann sie reparieren lassen. Allerdings hat das QTS-Interne e2fsck bei mir versagt. Anschließend hatte ich doppelte Dateieinträge, und die Indizes wurden immer wieder und wieder korrupt. Wie ich in dem Thread schon schrieb, vermute ich, dass es vielleicht garnicht am konkreten Build liegt, sondern dass der Fehler im System schlummern könnte, und er mit einem bestimmten Upgrade-Schritt zu Tage tritt ...

Hier werde ich noch ein paar Sachen zu meiner QNAP-ext4-Analyse ergänzen: QNAP ext4-Kompatibel ja/nein?

Ja, das interessiert mich auch. .qpkg/photostation war auch genau der Ordner, der sich bei mir nicht löschen ließ - weil eben das QTS-"EXT4"-Filesystem - allerdings vom 0537! - u.a. diese HTrees durcheinander gebracht hat. (Siehe hier)

(mach mal ls -al, ob da Fragezeichen kommen ...)

Ich hab die 4.3.4.0551 auf TS-251+, und ich vermisse das /dev/disk-Filesystem. Kann das einer nachvollziehen? Ich habe den Ordner /dev/disk nicht mehr, wo man bspw. mit /dev/disk/by-id/ seine Platten per ID browsen kann usw.

Zitat von SaschaB

cannot upload file /Season 1/xxxxxx-s01e03.avi: Disk error

Hi Sascha, ich kann nur empfehelen, das betroffene Verzeichnis einmal in einer Shell (ssh) mittels des Befehls "ls -al" auflisten zu lassen. Sind dort alle Dateiattribute korrekt? Ein Problem mit der 0537 war, dass kein Zugriff mehr auf die Dateiattribute erfolgen konnte, zumindest wenn diese von der Anwendung auf bestimmte Art abgefragt wurden.

Zitat von SaschaB

Entschlüsselung der Volumes dauert ewig

-RTRR-Backup zum zweiten NAS läuft nur noch taktend mit 2MB/s

Wenn Du Performance-Probleme hast, dann schau doch mal in die Task-Liste. (z.B. mit dem Befehl "top" in einer Kommanodzeilenshell). Die Fehler im Dateisystem äußerten sich bei der 0537 derart, dass z.B. Dateilöschen nicht mehr möglich war und gerne mal ein "rm"-Prozess (Datei-Löschen) mit voller Last gerödelt hat und so Platte und Prozessor belegt hat.

Zitat von Ernie01

Nun kann man aber eine solche Kopie nicht im NAS einsetzen.

Warum ist das so ?

Ich habe hier gerade genau das umgekehrte Erlebnis!

Ich habe eine der beiden RAID1-Platten temporär zur Rettung benutzt und komplett mit "dd" andere Daten drübergebügelt. Als ich sie wieder ins QNAP einsetzte, fuhr das "ganz normal" hoch und hat ohne eine einzige Nachfrage zu stellen angefangen, das RAID wieder zu synchronisieren. Obwohl auf der Platte gar keine RAID-Partitionierung mehr vorliegt!

Bildschirmfoto 2018-04-20 um 23.14.46.png

Und dabei wimmelt es doch von Fehlermeldungen, schließlich war die Platte ja auch ganz anders paritioniert:

Bildschirmfoto 2018-04-20 um 23.15.25.pngBildschirmfoto 2018-04-20 um 23.15.42.png

Einerseits toll, dass es versucht, robust zu sein. Andererseits: Ziemlich uncool, selbstständig Rettungsversuche zu unternehmen. Und wie's ausschaut bleibt es auch bei versuchen. Denn ich glaube nicht, dass sich das wieder gerade biegt.

Ich hätte erwartet, dass eine gespiegelte Platte als identische Platte erkannt wird und eine neu formatierte Platte als neue Platte. Aber das ist wohl nicht so. Er erkennt die Platte an phyischen Eigenschaften. Sehr gruselig. Warum macht man das so?

Zitat von JottWe

Nach langer Recherche hatte ich gesehen, dass die Samba-Config (smb.conf) hinüber war, d.h. fast leer.

Kannst Du das etwas konkretisieren? Bei mir war die Ursache defekte Suchbäume in den Ordnern des womöglich verpatchten ext4-Systems. Die Folgen daraus können ja sehr vielfältig sein, aber das Dateien sich "fast leeren", darunter kann ich mir gerade so recht nichts vorstellen.

Meine Frage wäre immer, wie die Verzeichisse aussehen, wenn man sie mit ls -al auflistet, siehe hier:

qnap_fs_demage.png

Mavalok2: Wo sind denn die Umfrageergebnisse hin? Ich finde die gerade nicht mehr ...

Zitat von Ernie01

Nun kann man aber eine solche Kopie nicht im NAS einsetzen.

Warum ist das so ?

Sehr interessant. Ich hätte auch angenommen, dass die Platten aus Sicht vom Software-Raid identisch sind. Das erzeugt das Gefühl, dass QTS irgendwie auf die Hardware-IDs der Platte mit draufschaut? Aber wenn, dann müsste diese Zuordnung ja irgendwo gespeichert sein? D.h. das 10-Sekunden-Reset könnte helfen, falls Du Dir das leisten kannst? Zumindest ein Verdacht ... ? Bzgl. Start mit gegraded-RAID: Ich kann mich noch erinnern, dass ich mein erstes RAID1 mit nem selbstgebauten PC-NAS hatte. Als da mal die Platten inkonsistent wurden (weil >60°C, also schlechte Kühlung kann ich nicht empfehlen - und übrigens waren das Serverplatten unter Garantie, die nicht einen einzigen Fehler zu meldeten!, aber egal ;-)) hatte ich auch ziemliche Verrenkungen anrichten müssen, weil das so aus dem ff nicht aktiviert werden konnte.

Zitat von Ernie01

mkpasswd f. LUKS

mkpasswd? Was ist das? Ich musste mal dieses dämliche C-Programm mit der cryptlib compilieren, um das QNAP-versalzene LUKS-Kennwort ($1$YCCaQNAP ...) herzuleiten. Gibt es da ein Kommantozeilentool??

Sorry. Nicht das Programm ist dämlich. Das ist natürlich lebensrettend gewesen. Danke an den Autor!! Dass man es braucht, das ist irgendwie bescheiden.

Zitat von Jagi

Aber es ist ja eine neue FW draussen. Jetzt wird alles gut. Mutige vor

Friedensangebot akzeptiert. Ich war auch etwas genervt wegen der Sache. Aber dann muss ich gleich mal schauen, was unser Frischfleisch hier macht. Ich kann jedem nur empfehlen: QNAP einmal einrichten, und dann gleich mal einen Filesystem-Check machen. Aber nicht den aus der QNAP-Gui, der macht nämlich nicht nur check, sondern repariert. Ich empfehle, die Platte an einen Linux-Rechner zu hängen (Knoppix oder whatever), und dann mal e2fsck auszuführen. Ja, im Falle von RAID und Verschlüsselung nicht einfach. Sobald ich mit Datenrettung durch bin und meine Platten wiederhabe, mache ich das. Bin gespannt, ob da immer noch invalide HTrees im Filesystem erzeugt werden! Ich werde hier berichten.

Zitat von Robertson23

woher hast du gewusst, was die richtigen Platten zum löschen sind und wo das Dom ist?

Ich weiß nicht, was DOM bedeutet, aber ich vermute mal es gibt eine fest verlötete SSD, auf die die Firmware draufgespielt wird. Und dass ihr das als DOM bezeichnet. Jedenfalll kann ich mich nicht erinnern, welches sd-Device das bei mir war. Ich würde mich auch nie darauf verlassen, dass es immer und überall das gleiche sd-Device ist. Deshalb verschaffe ich mir immer erst einen Überblick mit ls -al /dev/disk/by-id/ und Konsorten.

Zitat von PRIME

anscheinend nur nicht korrekt entschlüsselt wurden, wie auch schon Sumpfdotter geschrieben hatte.

Moment, mit Verschlüsselung hat das nichts zu tun! Die Verzeichniseinträge können nicht dargestellt werden, weil die Indizierung im Dateisystem inkonsistent ist. Vgl. hier und hier.

Zitat von PRIME

Ich nehme an es liegt an den behobenen Sicherheitslücken im SMB

Kaum vorstellbar. SMB ist eine Applikation. Hier ist das Dateisystem kaputtgegangen. Eigentlich etwas, was absolut stabil ist, solange man nicht dranrumprogrammiert.

An der Stelle bin ich immer mit ssh drauf und habe mit "top" und "ps" nachgesehen, welcher Prozess da so lange rumrödelt. Bei mir war es ein "rm -r", der nicht vorwärts kam. War zum Glück leicht zu entdecken, weil er einen ganzen Core belastet hat.

Zitat von Jagi

Ganz ehrlich ? Mir ist das völlig Latte wie du mit deinen Daten umgehst. Ich finde das nur klasse wie sich, wenn was in die Hose geht, beschwert wird. Man sollte sich dem Risiko eines FW-Updates immer bewusst sein.

Hi Jagi,

"ganz ehrlich, wenn Du nicht updatest, dann brauchst Du Dich nicht wundern, wenn Hacker Dein System kaputt machen"

"ganz ehrlich, wenn Du updatest, dann brauchst Du nicht nicht wundern, wenn das Bananen-System Deine Daten kaputt macht"

Deine Meinung kann ich überhaupt nicht nachvollziehen. Vielleicht weil ich mein Gerät als NAS nutzen möchte, also als Datenspeicher.

Überleg mal: Ich habe hier privat für über 1000 Euro Equipment um meine Daten sicher abzulegen - ich spiegele also meine Daten falls eine Platte ausfällt und ich mache zusätzlich noch ein Backup, falls etwas die Daten kaputtfunzt. Was soll man noch alles tun? Wenn nun eine riesen Schlamperei, und sorry wenn ich das auch so deutlich sage, denn ich habe nun ein paar Nächte reverse Engineering hinter mir, zum Datenverlust auf allen drei Medien führt, dann muss Kritik nicht nur erlaubt sein, sondern unbedingt erfolgen.

Wenn das Teil eines können soll, dann meine Daten (er)halten! Und das konnte es in jeder Nacht nicht. Stattdessen dauern Klicki-Bunti-Updates?

VG

Holger

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

Ich bin immer kein Freund davon, an einem System mit verlorenen Daten rumzudoktern. Ich repliziere gerade mein defektes Dateisystem auf eine andere Platte. Dann hoffe ich (einiges spricht dafür), dass e2fsck die Fehler korrigieren kann.

Zitat von dr_mike

Das ist genau das, was, wie im ersten Beitrag erwähnt, bei falscher Anwendung das DOM killt.

NEIN, ich habe NICHT gemacht, was im ersten Beitrag zitiert wird. Aber danke für Deinen Hinweis, das muss ich schärfen! Ich habe NUR die Platten gelöscht. Logisch, dachte ich. Wenn man mit etwas Sachverstand und Wachheit an die Sache mit dem Ziel rangeht, die Festplatten zurückzusetzen, wird man hoffentlich merken, wenn es mehr sd-Devices als Festplatten gibt. Den im ersten Beitrag zitierten Artikel kannte ich auch. Aber der ist wirklich gefährlich und stumpf, weil er nicht darauf eingeht, die Platten vorher auch zu identifizieren.

So wie sich das NAS verhält, leite ich für mich ab, dass es drei Speicher enthält: Die Platten, die ich einbaue. Eine interne SSD mit der Firmware und ein NVRAM für die Konfig. Ob das stimmt, weiß ich nicht. Aber dehalb habe ich die drei SChritte gemacht: Firmware neu einspielen, Platten (und nur die) zurücksetzen und Konig löschen. Das ganze hier zum Fachsimpeln zur Diskussion gestellt. Bitte nicht mein Verfahren falsch nachmachen und dabei die Partitionstabelle der internen SSD löschen. Darauf muss man in der Tat hinweisen.

Zitat von Robertson23

komisch ist nur, dass ich genau das bei meinem 253a gemacht habe vor nem Jahr oder so und es lies sich (wie in dem link beschrieben) ganz normal wieder einrichten.

Es gab bei mir noch ein drittes /dev/sd*. Da wird wohl die Firmware drauf liegen. Die zitierte Anleitung sagt, ALLE /dev/sd* löschen. Du hast aber (schlauerweise) nur die Platten gelöscht.

Zitat von qpukk

Korrekt wäre "dd if=/dev/zero ..."

Guter Hinweis, man bin ich eingerostet