+-Serie DS716+ : Daten, Fakten, Berichte

[dil88]

Es kann m.E. nicht am RAM liegen, wenn das Verhalten so immer wieder reproduziert werden kann, wie Du es beschreibst.

 

[PsychoHH]

Alles klar.

Dann werde ich nochmal komplett zurücksetzen und schauen ob das Problem behoben ist.

 

[PsychoHH]

Warum probierst du es nicht einfach aus und tauschst den RAM noch einmal!?

Hab ich. Liegt nicht am RAM.

Alles gelöscht und neu eingerichtet 2x

Schreib erstmal kurz den Support melde mich nochmals

 

[helmut72]

Kann einer das für mich mal prüfen? Und eine Datei in einen verschlüsselten Ordner verschieben und schauen ob die Datei funktioniert?
Bitte dann aber mit dem Dateiformat btrfs

Bin vor langer Zeit (als damals folgende FS "hip" waren) mit XFS, JFS und ReiserFS auf die Schnauze gefallen. Seitdem bleibe ich bei ext(2-4) bzw. meide Dateisysteme von Entwicklern und Firmen, die vergleichsweise nur am Rande am Kernel entwickeln, sondern eigene Interessen verfolgen. Dazu zählt auch Oracle, also BTRFS. So verlockend auch die Funktionen von BTRFS sind.

Ok, auf dem Raspi bzw. Embedded Hardware mit SD-Karte gibts natürlich ein anderes FS als ext(2-4), aber das sind ja wie ext(2-4) einfache und funktionierende Brot und Butter Dateisysteme und zum Glück fernab von irgendwelchen "Enterprise" Ambitionen. Enterprise heißt meist nichts gutes...

 

[PsychoHH]

Okay. Ich kann dich verstehen allerdings habe ich auch bei ext4 ein Problem. Welches ich bei der 212j nicht habe.


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.


Mit dem Dateiformat ext4 bleibt beim verschieben in einem verschlüsselten Ordner die Dateigröße gleich und wird somit richtig angegeben.
Die Datei selbst ist ebenfalls korrupt, aber nur in der File Station. Am Mac kann ich diese nach dem Download problemlos öffnen. Auch kann ich per Finder die Vorschau nutzen.

Fakt ist somit, dass es bei mir mit beiden Dateiformaten ein Problem gibt.

Mal schauen was der Support morgen schreibt.
Wenn nicht bring ich die DS zurück und versuch mein Glück erneut.

 

[Bordi]

Fakt ist somit, dass es bei mir mit beiden Dateiformaten ein Problem gibt.

Das es mit BTRFS Probleme gibt ist nun beileibe nicht neu. Ich hab bisher nur von Enthusiasten gehört das es Stabil sei, und möchte auch gleich darauf hinweisen das deren Auffassung von Stabiel weit von meiner Vorstellung abweicht. Daher, bevor Debian nicht zwei Stabel in folge -mit BTRFS als Vorgabe / Standardformat- raus bringt, würde und werde ich BTRFS lediglich zu Experimentalzwecke/Testzwecke in einer VM empfehlen.

 

[ovicula]

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.


Mit dem Dateiformat ext4 bleibt beim verschieben in einem verschlüsselten Ordner die Dateigröße gleich und wird somit richtig angegeben.
Die Datei selbst ist ebenfalls korrupt, aber nur in der File Station. Am Mac kann ich diese nach dem Download problemlos öffnen. Auch kann ich per Finder die Vorschau nutzen.

Wenn es dir weiterhilft würde ich nachher das auch mal unter ext4 testen - btrfs kann ich nicht bieten - hab meine Platten aus der DS212J migriert und nicht die Muße meine ganzen Daten zu schieben

ERGÄNZUNG: hab schon mal nebenher auf meiner 716+ (wie schon geschrieben: ext4) getestet. Dateien von unverschlüsselt zu verschlüsselt und umgekehrt und innerhalb verschlüsselt verschoben und kopiert. Jeweils keinerlei Probleme. Dateien lassen sich alle öffnen und haben die korrekte Größe.

 

[PsychoHH]

Danke dir. Dann hat meine DS wohl echt eine Macke. Selbst mit dem neusten Update klappt es mit ext4 nicht richtig in der File Station.

Jetzt bin echt am überlegen die bei Cyberport zu tauschen noch sind keine 2 Wochen rum mal schauen.

 

[speedymax]

Das es mit BTRFS Probleme gibt ist nun beileibe nicht neu. Ich hab bisher nur von Enthusiasten gehört das es Stabil sei, und möchte auch gleich darauf hinweisen das deren Auffassung von Stabiel weit von meiner Vorstellung abweicht. Daher, bevor Debian nicht zwei Stabel in folge -mit BTRFS als Vorgabe / Standardformat- raus bringt, würde und werde ich BTRFS lediglich zu Experimentalzwecke/Testzwecke in einer VM empfehlen.

Das sind ja interessante Informationen. Meine neue 716+ ist ich gerade auf dem Versandweg und eigentlich wollte ich die direkt auf btrfs aufsetzen, aber wenn das so ist bleibe ich wohl doch lieber erst mal bei dem gewohnten ext4. Stabilität geht nun mal über alles, da nützen mir neue Features wenig wenn es noch nicht ausgereift ist.

Mal was anderes, kann man den RAM nachträglich jederzeit problemlos aufrüsten wenn es nötig werden sollte, oder muss da irgendwas am System angepasst werden?

 

[ovicula]

Mal was anderes, kann man den RAM nachträglich jederzeit problemlos aufrüsten wenn es nötig werden sollte, oder muss da irgendwas am System angepasst werden?

Einfach den Riegel austauschen - vollkommen unkompliziert.

 

[PsychoHH]

DS wurde eben gegen eine neue getauscht.

Beide Festplatten habe ich unter Windows komplett gelöscht sprich die Partitionen.

Festplatte direkt rein und installiert.

Problem besteht weiterhin.


HDD 2 im laufenden Betrieb reingesteckt und ext4 erstellt. Keine Probleme.

HDD nochmal unter Windows komplett formatiert und im laufenden Betrieb reingesteckt und btrfs erstellt. Problem weiterhin vorhanden.


Also nun denke ich mal es handelt sich irgendwie um einen Bug. Warum dies Synology nicht nachvollziehen kann ist mir allerdings ein Rätsel.

Ich überlege jetzt ob ich einfach bei ext4 bleibe, wer weiß ob es nicht noch mehrere Probleme mit btrfs gibt.


Wer will kann es nochmal gerne mit btrfs probieren und berichten.

 

[dil88]

Danke für Deine Informationen. War denn jemand von Synology einmal auf Deiner 716+? Welche DSM Version hast Du drauf?

 

[PsychoHH]

Ja per Teamviewer. Hatte den Techniker auch die ganze Zeit am Telefon. Der Fehler ist auch intern nicht bekannt. Bei mir konnte er es aber auch sehen und hat sofort danach den log durchgeschaut, da wurde dann kein Kopiervorgang gestartet wenn man die Datei verschoben hat. So als wenn die DS nur einen Dateinamen kopiert aber die Datei nicht.

Es gibt keine Fehler der HDDs oder Samba usw.

Da ich halt Drittanbieter Software installiert hatte sollte ich erstmal neu installieren.
Heute morgen habe ich einen Speichertest per Assistent gemacht und nochmal einen debug log hingeschickt. Eventuell finden Sie ja etwas.

Es war die 5.2-5644 sowie die aktuelle 5.2-5644 Update 2 installiert.

Liegt es eventuell daran, dass mein ecc unterstützt wird wie hier geschrieben? http://www.synology-forum.de/showth...erichte/page24&p=573286&viewfull=1#post573286

 

[geimist]

Kann ich bestätigen.
Ich habe den Testlauf nachgestellt, und auch hier das gleiche Ergebnis:

- btfrs Volume
- verschlüsselter Ordner

Kopieren von unverschlüsselt nach verschlüsselt ist OK.
Verschieben von unverschlüsselt nach verschlüsselt ist Größe 0 Byte

 

[PsychoHH]

Oh man.

Dann bin ich ja echt nicht verrückt.

Das Problem sollte somit auch bei Synology vorhanden sein und leicht nachvollziehbar sein.

Die Frage ist nur woran liegt es?
Liegt es direkt an btrfs oder an die Implementierung von Synology?

Geht verschieben auf einem btrfs Dateisystem ohne diese ECC Unterstützung oder muss man dann jedes Mal kopieren statt verschieben nutzen?
Ich kenne mich mit den Dateisystemen echt nicht aus jedoch sollte so ein Fehler nicht vorhanden sein.

Hoffentlich wird das ganze gefixt.



Kann jemand das mal auf einer anderen DS mit btrfs probieren z.B. DSM 6 beta?

 

[dil88]

Mit ECC-RAM hat das, was Du und geimist beobachtet habt, nichts zu tun.

 

[Thonav]

Habe es gerade auf meiner DS1515+ mit btrfs probiert. Alles Szenarien funktionieren bei mir ohne Probleme.

- btfrs Volume
- verschlüsselter Ordner

Kopieren von unverschlüsselt nach verschlüsselt ist OK.
Verschieben von unverschlüsselt nach verschlüsselt ist OK

 

[PsychoHH]

Alles klar.

Ich nehme mal an in der dsm 6 beta wurde der Fehler behoben und sie haben ihn unter DSM 5.2 vergessen.
Danke dir.

 

[Bordi]

Ich nehme mal an in der dsm 6 beta wurde der Fehler behoben ...

Wieso bitte soll das so sein? 95% von dem was eine DS antreibt besteht aus eigenständigen OpenSource Projekten, an denen sich Synology nicht(!) beteiligt. DSM 6 ist nichts anderes als eine Update der Distro auf einen etwas neueren stand, und eine general-überholung der 5% Synology (welche zur Mehrheit aus der HTML-GUI besteht).
Wen du es schaffst die GUI auf ein aktuelles Debian 8.2 zu transferieren, hast du software-seitig so-was wie eine DSM 11.5.

..und zur Repetition: Ich schrieb Debian 8.2 und nicht Ubuntu 16.04 (Xenial Xerus) Daily Build

 

[ralfi80]

Wieso bitte soll das so sein?

Die Vermutung liegt ja erstmal nah, wenn es auf 716+ (mit 5.2) nicht funktioniert aber auf der 1515+ (mit vermutlich 6.0Beta) dann doch...