+-Serie DS716+ : Daten, Fakten, Berichte

[items]

Hach nee ist das schön anzusehen:
BTRFS, Wiederherstellung der Datensicherung per USB also gut was los auf den Platten und gleichzeitig 130GB kopieren (s. Screenshot) und trotzdem nur ne Auslastung der CPU von 40%


Das Ding ist heute angekommen und kann was! Definitiv!

Überaus zufriedene Grüße
items

 

[dil88]

So muss es sein - vor allem, wenn man so tief ins Portemonnaie gegriffen hat.

 

[speedymax]

Ich finde dafür, dass speedymax schreibt er würde gerne mal seine eigenen Erfahrungen sammeln, greifst du ihn doch recht heftig an. Eigentlich unnötig. Er richtet doch bei keinem Dritten Schaden an.

Genau so ist es, aber da stehe ich darüber und ignoriere es. Jeder weiß doch das er gerne mal austeilt.

 

[speedymax]

Mit dem Dateiformat btrfs wird beim verschieben in einem verschlüsselten Ordner die Dateigröße mit 0 byte angegeben und ist korrupt.
In der File Station sowie nach dem Download auch direkt am Mac. Selbst beim zurück kopieren/verschieben ist die Datei nicht mehr lesbar.

Hast Du dazu von Synology noch mal etwas dazu gehört? Ich wollte das jetzt auch noch mal nachstellen, was auch geklappt hat.
Mir ist dazu aber noch aufgefallen das es nur passiert wenn die Quelle und das Ziel auf dem gleichen BTRFS Volume liegen.
Versucht man das gleiche von unterschiedlichen Volumes gibt es keine Probleme.
Keine Ahnung ob das von Bedeutung ist, aber eventuell ist das für Synology zur Fehlereingrenzung interessant.

 

[PsychoHH]

Hast Du dazu von Synology noch mal etwas dazu gehört? Ich wollte das jetzt auch noch mal nachstellen, was auch geklappt hat.
Mir ist dazu aber noch aufgefallen das es nur passiert wenn die Quelle und das Ziel auf dem gleichen BTRFS Volume liegen.
Versucht man das gleiche von unterschiedlichen Volumes gibt es keine Probleme.
Keine Ahnung ob das von Bedeutung ist, aber eventuell ist das für Synology zur Fehlereingrenzung interessant.

Nein nichts mehr gehört.

Ich sollte einen Fernzugang einrichten, da ich aber eh wieder Drittanbieter Apps nutze habe ich das erstmal gelassen, da ich sonst erst wieder zurücksetzen muss.

Also mit unterschiedlichen Volumes habe ich das nicht probiert. Waren dann aber beide mit btrfs?
Denn mit ext4 habe ich keine Probleme.


Öffne aber gerne ein Ticket dazu.

Danke dir.

 

[geimist]

Verschieben mit 2 unterschiedlichen Volumes (jeweils btrfs) funktioniert es auch hier.

 

[speedymax]

Ja bei 2 unterschiedlichen Volumes (beide btrfs) gibt es keine Probleme. Probleme gibt es nur wenn die Operation innerhalb eines Volumes stattfindet. Das sollte auch Synology eigentlich klar nachstellen können.

 

[Waldstiefler]

Hier steht auch mittlerweile eine DS716+ für die erste Config.
Der Wumms den die Kiste hat ist schon beeindruckend.

Das BTRFS Problem beim Verschieben konnte ich, oh Wunder, auch nachstellen und habe gleich mal ein Ticket geöffnet.

 

[Claus67]

Sagt mal, ist dies normal bzw. kann dies mal einer nachvollziehen:
Wenn ich auf der DS716+ mit BTRFS as root in einem unverschlüsselten & verschlüsselten Ordner eine Verzeichnis bzw. Datei anlege so haben diese garkeine Berechtigungen.

Lummerland2> mkdir test
Lummerland2> touch test.log
Lummerland2> dir
d---------    1 root     root             0 Dec 24 11:02 test
----------    1 root     root             0 Dec 24 11:03 test.log
Lummerland2>

An den Berechtigungen von admin habe ich nichts geändert.
Nach meinem Verständnis sollte (zumindest) root die Berechtigungen wie unter Systemsteuerung->Gemeinsame Ordner bzw. ->Benutzer festgelegt haben.

Bei meiner DS210j mit EXT3 besitzen beide Berechtigungen.

Lummerland> mkdir test
Lummerland> touch test.log
Lummerland> dir
drwxr-xr-x    2 root     root          4096 Dec 24 11:14 test
-rw-r--r--    1 root     root             0 Dec 24 11:14 test.log

 

[dil88]

Ich vermute, dass das mit der Umstellung im DSM auf ACL und nichts mit BTRFS zu tun hat.

 

[PsychoHH]

Waldstiefler vielen Dank für den Test und eröffnen eines Tickets. Viel Spaß mit der Kiste die hat echt Power.

Ich schreibe nun nochmal eine Email an den Support.




Er nutzt wahrscheinlich ja aber auf beiden 5.2 sollte doch dann gleich sein?

 

[dil88]

Das mag sein, dass er auf beiden DSM 5.2 nutzt, aber ich meine mich zu erinnern, dass dann, wenn man das Volume unter einer alten nicht-ACL-DSM-Version eingerichtet hat, eine explizit ausgelöste Migration erfolgen muss, um ACL einzurichten. Ist dies nicht erfolgt, dürfte dementsprechend bei der 210j noch ohne ACL gearbeitet werden. Darauf deutet auch das Filesystem Ext3 hin, was schon seit einiger Zeit durch Ext4 abgelöst wurde.

 

[Claus67]

Ich habe beim "BTRFS-Filestation-Verschiebe-Problem" noch etwas weitergeforscht. Nach dem Verschieben von einem unverschlüsselten Verzeichnis in ein verschlüsseltes war ja die Dateigröße augenscheinlich NULL.
Prüft man jedoch die Diskbelegung so haben die Dateien mit nichten die Größe NULL sondern die unsprüngliche Größe:

Lummerland2> dir
d---------    1 root     root          1680 Dec 24 01:47 .
d---------    1 root     root          1680 Dec 24 01:47 ..
----------    1 root     root             0 Dec 24 01:47 messages0
----------    1 root     root             0 Dec 24 01:47 messages1
----------    1 root     root             0 Dec 24 01:47 messages2
----------    1 root     root             0 Dec 24 01:47 messages3
----------    1 root     root             0 Dec 24 01:47 messages4
----------    1 root     root             0 Dec 24 01:47 messages5
----------    1 root     root             0 Dec 24 01:47 messages6
----------    1 root     root             0 Dec 24 01:47 messages7
----------    1 root     root             0 Dec 24 01:47 messages8
----------    1 root     root             0 Dec 24 01:47 messages9
Lummerland2> du -ah
196.0K  ./messages0
196.0K  ./messages1
196.0K  ./messages2
196.0K  ./messages3
196.0K  ./messages4
196.0K  ./messages5
196.0K  ./messages6
196.0K  ./messages7
196.0K  ./messages8
196.0K  ./messages9
1.9M    .
Lummerland2>

Ich mutmaße (bitte kommentieren), dass hier logische Fehler im Laufwerk vorliegen/entstanden sind.

Frage:
Gibt es einen Befehl auf der DS mit dem man ein Volumen (RAID1) auf logische Fehler überprüfen/korrigieren kann.

Hintergrund:
Habe mit mäßígem Erfolg bei Synology ein Ticket aufgemacht. Die wollen nun, dass ich das Volumen plattmache, die DS zurücksetze und alles neu aufsetze und wenn das Problem weiter besteht, darf ich mich dann wieder melden. Das kostet mich 1 Woche bis alles wieder so eingerichtet ist. In Hinblick auf eine Rootcause-Analyse und Korrektur halte ich das für unsinn. Will nun bis 26.12. noch Infos sammeln und dann antworten.

 

[PsychoHH]

Wenn du die 0 byte Datei aber dann in einen anderen Ordner kopierst oder herunterlädst ist diese auch kaputt, jedenfalls ist es bei mir so.

Ich habe eben nochmal dem Support geschrieben.

Mein Problem ist aber auch, dass ich nun ein viertes mal alles einrichten müsste und darauf habe ich gerade echt keine Lust. Kann ja nicht so schwer sein den Fehler nachzustellen. Und da die Dateien schnell zerstört werden können und das bei einer nicht Beta Version, sollten Sie dieses Problem schnellstmöglich beheben.

 

[Claus67]

Sehe ich genau so. Hatte schon früher gepostet, dass ich nicht nachvollziehen kann, dass Sie es nicht nachvollziehen können.
Hier mein Ticket und die Antwort. Blöderweise werden die Links nach dem Abschlicken durch automatisches Einfügen von "amp;" hinter jedem "&" zerstört.

SETUP:
DS716+ mit BTRFS Filesystem im RAID1.

FEHLERBILD:
Nach dem VERSCHIEBEN von Dateien mittels Filestation von einem unverschlüsselten in einen verschlüsselten Ordner haben die Dateien im verschlüsselten Ordner die Größe NULL und sind korrupt.

Dies ist kein Einzelschicksal:

http://www.synology-forum.de/showth...akten-Berichte&p=577141&viewfull=1#post577141
http://www.synology-forum.de/showth...akten-Berichte&p=577494&viewfull=1#post577494

ZUSATZINFOS:

1. Das Problem wurde laut Synology-Forum vom Synology-Support um den 04./07.12. angesehen konnte aber nicht nachvollzogen werden.

http://www.synology-forum.de/showth...akten-Berichte&p=577476&viewfull=1#post577476

2. Gleiches Verschieben auf der Kommandozeile (PUTTY) mittels mv-Befehlt führt zu KEINEM Fehler (siehle Link, ich bin Claus67).

http://www.synology-forum.de/showth...akten-Berichte&p=578104&viewfull=1#post578104

3. Gleiches Verschieben auf einer DS716+ mit EXT4 (Link Abschnitt ERGÄNZUNG: ...) sowie auf einer DS1515+ mit DSM6.0Beta war laut Synology-Forum unauffällig. Deshalb scheint es ein DS716+ mit BTRFS spezifischen Problem zu sein.

http://www.synology-forum.de/showth...akten-Berichte&p=577334&viewfull=1#post577334
http://www.synology-forum.de/showth...akten-Berichte&p=577542&viewfull=1#post577542
http://www.synology-forum.de/showth...akten-Berichte&p=577571&viewfull=1#post577571

Frage:
Kann der Fehler mittlerweile nachvollzogen werden?
Wird dieser gefixt?

VORGEHEN ZUM NACHVOLLZIEHEN:
1. einen verschlüsselten gemeinsamen Ordner erstellen.
2. Dateien/Ornder mit Dateien mittels Drag & Drop von einem UNverschlüssleten in den verschlüsselten Ordner verschieben.
3. Größer der Dateien im verschlüsselten Ordner prüfen (-> NULL).

Hier die Antwort von Synology:

Guten morgen,

Vielen Dank für Ihre Anfrage.
Prüfen Sie bitte zunächst Ihre NASseitigen Festplatten im erw. Smart Test nach Fehlern und Defekten, ob die Unregelmäßigkeiten daher stammen.
Prüfen Sie einen RAM TEST über den Synology Assistenten um weitere Fehler zu ermitteln.
Ggf. bestehen Dateisystemfehler, weshalb die Dateien korrupt sind.
Logische Dateisystemfehler können Sie beheben in dem Sie das Volume bspw. löschen und Neuaufbauen. Die Daten können Sie temporär auslagern und schauen, ob diese dort lesbar sind.
Sofern Sie Drittanbieterpakete aus externen Quellen installiert hatten oder haben, deinstallieren Sie diese zunächst und prüfen Sie das Verhalten erneut. Ansonsten gehen Sie bitte den Weg über die Rückstellung:
https://www.synology.com/de-de/knowledgebase/tutorials/493
Sollte das Problem bestehen bleiben, kontaktieren Sie uns über das Support Center erneut, unter Angabe der debug Protokoll-datei und der Datums-Zeitangabe, wann der Fehler nachgestellt wurde und aufgetreten ist.

Mit freundlichen Grüßen / with kind regards

- SMART test ist so konfiguriert, dass er für die Anfangszeit zeitgesteuert täglich (Schnelltest), ausführlicher Test jede Woche durchgeführt wird um Frühausfällen zu erkennen. Werte werden mit eigenem Script ausgelesen und weggeschrieben. Alles unauffällig.
- RAM Test mit dem Syno-Assistenten bekomme ich nicht hin da ich auf reisen bin und mich nur remote aufschalten kann. Gibt es da was auf der Kondozeile?
- Drittanbieter-Pakete sind nicht installiert.

 

[geimist]

Support aus dem Kindergarten - sie machen alles mit (Text-) Bausteinen

 

[PsychoHH]

Ich habe meine ds komplett zurückgesetzt keine Drittanbieter Apps installiert und alles so belassen nur neustes DSM und ein volume erstellt.

Dann wurde auch ein Speichertest gemacht und der log zugeschickt.

Antwort war:

interessanter weise sind die Logs unauffällig.

Festplatten in Ordnung.
Arbeitsspeicher in Ordnung.
Netzwerk in Ordnung.
"Message" in Ordnung.
"SMB.log" in Ordnung.

Tatsächlich finde ich nichts.
Sagen Sie mir bitte Bescheid, ob dieses Verhalten auch im
neuem System auftaucht.

Dann habe ich ja die DS direkt getauscht und es war mit komplett formatierten Festplatten immer noch vorhanden.

Mehr können wir User meiner Meinung nach nicht machen und sie sollten eine 716+ einfach einrichten und das Problem nachvollziehen können.

 

[Waldstiefler]

Bei mir ist es auch ein nacktes System mit aktuellstem DSM und keinerlei Apps etc.

Ich finde das verhalten von Synology in dem Fall nur erstaunlich, da es sich bei der 716+ um ein klar an das Business-Umfeld adressiertes NAS handelt. Da sollte der Support dann schon anders reagieren.
Naja mal sehen...
Immerhin wird da 716+ ja auch wg. dem Support oft einem Selbstbau-Server à la N54L etc. vorgezogen.

Für den Produktiv-Einsatz ist hier eh eine Vollverschlüsselung vorgesehen, von daher ist das Problem jetzt @work bei mir nicht so essentiell. Nur hat man dann halt auch das Gefühl, dass es ggf. noch woanders haken könnte

Positiv zu bemerken bleibt: egal ob verschlüsselt oder nicht GB-LAN stopft die 716+ bis oben zu

 

[Bordi]

... Kindergarten - ...Bausteinen

+1

 

[Insane307]

So nach einigen Wochen Nutzung ist mir dann doch ein Bug aufgefallen der an der 716+ liegen muss.

Ich hab in bestimmten Shared Folders auf der ersten Ebene (also direkt im Shared Folder) das Phänomen das sich leere Ordner nicht löschen lassen.
Die Daten darin können problemlos gelöscht werden, nur der Ordner an sich nicht.

Auch auf der Kommandozeile mit root ist es nicht möglich die Ordner zu löschen.
root hat aber alle Rechte.

Die Ordner haben keine Sonderzeichen oder ähnliches, manche heißen einfach nur Neuer Ordner.

Kann das jemand nachstellen oder hat ähnliches beobachtet?
Über den Windows Explorer werden die Ordner ganz normal gelöscht, erscheinen aber nach einiger Zeit von allein wieder.
Über die DS File wird übrigens zurückgegeben das keine Rechte vorhanden wären.

Das ist alles sehr kurios und tritt bei mir nur auf der 716+ auf. Bin gerade extra zurück auf EXT4 da ich dachte es liegt an BTRFS aber nein, unter EXT4 gleiches verhalten.