[Beta 2] DSM 6.1 - 15022: Erfahrungen, Probleme, Bugs

Status
Für weitere Antworten geschlossen.
Syno mit SMB 4.4 aber ohne SMB-Multichannel o.O.
Der Test von goetz lässt aber hoffen :D
 
Habe jetzt im "White Paper for Data Protection with Synology Snapshot Technology. Based on Btrfs File System" nachgelesen

Auszug:
"CRC32-C Checksums - Checksums will be generated for user data and metadata to avoid silent corruption. If a checksum mismatch is detected during a reading process, it will first try to recovery automatically, by obtaining a good copy of this block for metadata. If no good copy is available, an error will be reported instead of giving the user the incorrect data."

Der letzte Satz hat es in sich:

"Wenn keine einwandfreie Kopie (der Daten vorhanden ist) wird statt dessen, das dem Benutzer die falschen Daten zur Verfügung gestellt werden, ein Fehler angezeigt"

Übersetzung sicher nicht 100%, aber für den Standard-Benutzer verständlich

Für mich ein Widerspruch in sich, da ja die "falschen" Daten (Bildfehler) ja angezeigt werden ...

Also auf Deutsch: Btrfs ist keine eierlegende Wollmilchsau - btrfs is no egg-laying, milk-bearing woolly sow :confused:

P.S. wenn die Daten korrigiert werden können, ist alles ok, ansonsten Pech gehabt
Conclusio: ohne Btrfs würde es man gar nicht merken !!!
 
Das sehe ich allerdings anders. Eben für den Fall das eine Datei vor Umstellung auf btrfs oder schon vor Ablage auf dem Dateisystem einen Fehler hat, kann kein System der Welt die Datei wieder fehlerfrei herstellen.
Meine Daten waren anscheinend vor Umstellung auf btrfs fehlerfrei - nachdem ich dieses Format nutze (schon mit der ersten Beta 6.0, glaube ich), habe ich auch noch keine Fehlermeldung bekommen, bzw. einen Fehler in meinen Dateien feststellen können.
Sollte es also so sein, dass bei mir ein Bit gekippt ist, so scheint mein System (seit 6.1 Beta zumindest) diesen Zustand geheilt zu haben.
 
Jap so ist es denke ich auch.
Wenn die Daten vorher schon einen Fehler hatten, können dir nicht repariert werden.

Das man aber einen Fehler angezeigt bekommt der nicht repariert werden kann ist schon komisch :/
 
Nachtrag zu oben:

im aktuellen White-Paper steht folgendes:

"CRC32-C Checksums - Checksums will be generated for user data and metadata to avoid
silent corruption. If a checksum mismatch is detected during a reading process, it will
first try to recovery automatically, by obtaining a good copy of this block for metadata. If
no good copy is available, an error will be reported to the user."

Wenn keine korrekten Daten vorhanden sind, wird ein Fehler angezeigt
 
Wenn die Datei vorher schon einen Fehler hatte - hatte ja auch vorher ext4 - dann hat man es ja normalerweise nicht gemerkt ;)
Bleib trotzdem bei Btrfs, da alleine auf Grund der Snapshots (bei mir für die wichtigsten Ordner angelegt) ich wirklich wichtige Dateien (Registrierungscodes etc.) wiederherstellen konnte, die ich gelöscht hatte.
 
Könnte jemand der das VirtualDSM Manger Paket installiert hat mal auf der Konsole folgendne Befehl absetzen und hier die Ausgabe posten.

Ziel ist dass ich wissen möchte ob Synology dort auch die VNC Funktionalität von QEMU mitkompilert hat oder ob sie wie bei DSM 6.0.2 fehlt.

Befehl als Root (sudo -i) starten
Rich (BBCode):
qemu-system-x86_64 vnc :1
Sollte eine Fehlermeldung kommen bitte posten, wenn nichts kommt und der Befehl gestartet wird aber keine eingabe mehr möglich ist mit [Strg]+[C] abbrechen.

In dem Fall könnte man weitere Tests durchführen: http://www.synology-forum.de/showthread.html?82229-VirtualDSM-Manager-zum-Virtuasiereln-nehmen
 
Zuletzt bearbeitet:
Hilft das?

root@DS415plus:~# qemu-system-x86_64 vnc :1
qemu-system-x86_64: could not open disk image vnc: Could not open 'vnc': No such file or directory
root@DS415plus:~# qemu-system-x86_64
qemu-system-x86_64 vnc :1
 
Relativ. Scheinbar ist hier etwas anders.

Welche Version ist bei dir installiert?
Rich (BBCode):
qemu-system-x86_64 -version

Wirklich genau könntest du es sagen wenn du wie in meinem verlinkten Beitrag beschrieben (siehe XML File von Virsh) eine vdisk.img, xp.iso. winxp.xml in einem Verzeichnis hast und dann über virsh oder qemu....64 direkt startest.
Damit sollte theortisch dann eine VM per VNC erreichbar sein.

Mangels Hardware (Xpenology gibts leider nur bis 6.0.2) und schiess davor die Beta zu installieren kann ich es selbst nicht testen ;)
 
Eine Antwort wäre dann im verlinkten Thema, oder per PN wünschenswert damit das hier nicht ausartet ;)
 
anscheinend verstehe ich was falsch bzgl. der Korrektur von "Bit-Fehlern"

Das ist ganz normales Verhalten von Btrfs weil... ohne regelmäßiges scrubbing hat man faktisch keinen Schutz vor bitrot.
 
Ohje, ich dachte, btrfs befreit mich vom scrubbing ...
 
Ich dachte die Prüfung wird automatisch durchgeführt.
Jedenfalls nachdem man eine Datei geschrieben/gelesen hat.

Wenn jemand noch paar Infos dazu hat wie es bei Synology ist immer her damit :)
 
Btrfs erstellt die Checksummen Blockweise. Ändert sich ein Bit in einem Block wird das bei der Prüfung der Checksumme bemerkt. Welches Bit sich verändert hat ist nicht bekannt. Folglich werden die Dateien im Log als defekt genannt, die in den Block reinragen. Selbst wenn nur eine Datei davon betroffen ist. Es muss der ganze Block ersetzt werden. Dieser Block wird von den noch vorhandenen Festplatten eingelesen und der defekte überschrieben. Fertig ist die Reparatur.

Jetzt zum scrubbing:
Wird ein Block lange nicht gelesen, erfährt es für diese Zeit auch keine Prüfung der Checksumme.
Kippt jetzt der selbe Block in Woche 3 auf der einen Seite und in Woche 5 auf der anderen Seite so würde scrubbing in Woche 4 den Block reparieren.

Findet kein scrubbing statt können beide Seiten eine fehlerhafte Checksumme aufweisen.
Eine Reparatur ist dann nicht mehr möglich.
 
Hallo zusammen,

ich habe angefangen zu lesen, aber 24 Seiten waren mit doch zu viel. Und die Suche ergab nichts.

Nachdem ich beim Upgrade von DSM 5.x auf DSM 6.0 bereits feststellen musste, dass der SSH Zugriff nicht mehr direkt mit root ging (das war bei mir kein Sicherheitsproblem), geht der Zugriff nun überhaupt nicht mehr. Wenn ich die Shell wie bisher öffnen möchte, bekomme ich vom Client ein Authentisierungsfenster, in dem die EIngabe eines Passwortes nicht mehr möglich ist (ist ausgegraut). Was soll das jetzt wieder??? Weiß jemand wie ich auf die Shell zugreifen kann???
 
Seit DSM 6 geht es einfach über den admin und dann holt man sich einfach root z.B. sudo -i
Das steht hier 100fach im Forum.

Mit der B2/RC geht es genau so.

Evtl. SSH deaktiviert, Port falsch oder auto. Blockierung die IP gesperrt.
 
Das mit sudo -i ist mir klar. Sorry, war nicht ganz deutlich in meinem Beitrag. Es geht überhaupt nicht mehr. sudo -i akzeptiert mein Passwort nicht. Mit einem anderen Admin User kann ich mich nicht per User / PW anmelden. Wenn ich den SSH Client auf Keyboard Interactive stelle, bin ich einfach so angemeldet, ohne je ein PÜasswort eingegeben zu haben.

SSH ist aktiv, Port ist i.O., IP ist nicht geblockt.

Wenn ich das ganze über Telnet probiere, dann klappt die Anmeldung USer/PW mit einem Admin Account. sudo -i geht auch da nicht.
 
Sonderzeichen im Passwort?
Ggf. einmal abändern zum Testen.
 
Habe die Lösung. Man darf sich offensichtlich nicht mit irgendeinem Benutzer aus der Admin-Gruppe mit der Shell konnektieren und dann sudo -i ausführen. Es MUSS der admin User sein, dann geht's.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat