TTD Forum

Habe gerde folgendes Problem:

Mehrere Filme auf dem Topf mit 0.5.0 er Enigmal Version.
zwei davon kann ich nicht mehr anschauen. Der Topf friert ein. Hilft nur noch das ziehen des Netzsteckers. Mit Fielzilla sehe ich diese zwei Filme garnicht. Mit Samba zugriff sehe ich sie, kann sie aber nicht löschen oder kopieren.

Kommt folgende Meldung: xxx kann nicht kopiert werden. Ungültige Zugriffsnummer.

Kennt dieses Problem jemand?

Danke und Gruß
meins10

Ich tippe auf kaputtes Filesystem. Kommt schnell vor, wenn man den Topf per Steckerziehen ausschaltet. Einloggen, /dev/sda3 unmounten und fsck drüber laufen lassen.

Kannst Du mir das bitte etwas genauer erklären?

Besten Dank

umount /dev/sda3
fsck /dev/sda3

Der erste Befehl wird ausgeführt.
Beim zweiten kommt: fsck: fsck.auto: No such file or directory

Hmm. was mach ich da falsch?

gib mal fsck ein (ohne enter) und drücke zweimal die tab taste. Dann sollten vielleicht mehrere fsck Befehle angezeigt werden. Wenn einer davon ext3 oder ext2 beinhaltet, starte den.

Nun kommt:
The superblock could not be read or does not describe a correct ext2 ....

Was nun? Sorry aber mit Linux kenne ich mich noch nicht aus

ouch, das klingt nicht gut. Allerdings verstehe ich nicht, wieso du das filesystem dann trotzdem mounten kannst. Versuch's nochmal mit

mount /dev/sda3

und wenn das geklappt hat, dann einfach "mount" und poste die Ausgabe

nach: "mount /dev/sda3" kommt schon diese Ausgabe: mounting /dev/sda3 on /hdd failed: Device or resource busy

reboote mal und dann direkt die ausgabe von "mount"

tf7700 login: root


BusyBox v1.11.2 (2009-11-22 10:35:47 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

tf7700:~# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext3 (rw,noatime,nodiratime,data=ordered)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /ram type tmpfs (rw)
/dev/root on /dev.static type ext3 (rw,data=ordered)
tmpfs on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
automount(pid349) on /autofs type autofs (rw,fd=4,pgrp=349,timeout=5,minproto=2,
maxproto=3,indirect)
/dev/sda3 on /hdd type ext2 (rw,noatime,nodiratime)
tf7700:~#

Kannst Du damit was anfangen?

okay

/dev/sda3 on /hdd type ext2 (rw,noatime,nodiratime)

zeigt, dass /dev/sda3 auf /hdd gemountet ist als ext2 Filesystem. Das heißt, dass der superblock noch okay sein muss. Wenn Du jetzt "umount /dev/sda3" eingibst (Es sollten natürlich keine Zugriffe auf /hdd stattfinden!), solltest Du keine Ausgabe bekommen. Zur Sicherheit dann nochmal "mount" und checken, ob obige Zeile verschwunden ist. Wenn das der Fall ist nochmal "fsck.ext2 /dev/sda3" eingeben und hoffen, dass der check durchläuft. Wenn er alles repariert kriegt, mit "mount /dev/sda3" die Festplatte wieder einbinden und schauen, ob die Filme noch da und lesbar sind.

Durchgelaufen, mit hunderten Fehlern.
Leider sind die zwei Filme jetzt mit einer Dateigröße von 0 Byte angegeben.
Naja egal. Vielen Dank für deine Hilfe.
Werde jetzt mal die Platte tauschen und alles neu aufspielen. Vielleicht hat sie ja auch ein Problem.

Wenigstens konntest Du die anderen Filme retten. Ich halte es für wahrscheinlicher, dass die Festplatte nicht kaputt ist. Ich denke, das Steckerziehen ist das Problem. Bei einem normalen Linuxsystem ist das nicht so sehr das Problem, weil beim wieder Einschalten automatisch ein Check durchgeführt wird, und so wird normalerweise nicht auf einem korrupten Filesystem herumgeschrieben. Der Topf macht das aber nicht, und so kommt es zu Problemen. Deshalb sollte man beim hängendem E2 sich lieber einloggen und per "init 6" einen reboot durchführen. Das drunterliegende Linux ist nämlich normalerweise noch vollständig da (dass Linux abstürzt, habe ich in den 15 Jahren, die ich damit arbeite, vielleicht fünfmal erlebt). So wird wenigstens die Festplatte sauber ausgehängt. Eine Möglichkeit ist auch, das Filesystem auf ext3 zu befördern, dann wird vor jedem Schreibvorgang ein Journaleintrag angelegt, der beim Crash zur Reparatur benutzt werden kann. Dadurch treten trotz hartem Ausschalten keine Inkonsistenzen auf. Allerdings benötigt dieses Vorgehen mehr Ressourcen, weshalb es von TDT wohl für die sda3 Partition nicht benutzt wird (das root fielsystem ist ext3, wie Du der Ausgabe des mount-Befehls entnehmen kannst).

Super, dass endlich mal jemand etwas Ausführlicheres dazu schreibt...

Topfi sucht zum Beispiel (in dem "anderen Forum") nach genau solcher Information.

Was ich nicht ganz verstehe ist:

Allerdings benötigt dieses Vorgehen [ext3 für sda3] mehr Ressourcen, weshalb es von TDT wohl für die sda3 Partition nicht benutzt wird

Ressourcen in welcher Hinsicht? CPU? Hat es schonmal jemand ausprobiert?

Gruß,
-Karma

Karma hat geschrieben:Super, dass endlich mal jemand etwas Ausführlicheres dazu schreibt...

Topfi sucht zum Beispiel (in dem "anderen Forum") nach genau solcher Information.

Was ich nicht ganz verstehe ist:

Allerdings benötigt dieses Vorgehen [ext3 für sda3] mehr Ressourcen, weshalb es von TDT wohl für die sda3 Partition nicht benutzt wird

Ressourcen in welcher Hinsicht? CPU? Hat es schonmal jemand ausprobiert?

Gruß,
-Karma

Wenn ich mich recht erinnere, wird bei ext3 vor jedem Schreibvorgang ein log in das Journal geschrieben, so in etwa: ich bewege jetzt "x" von der Position y an die Position z. Dann wird der Vorgang ausgeführt und der Dateieintrag (wo steht was) aktualisiert. Daraufhin wird der Journaleintrag gelöscht. Fällt nun der Strom aus bevor der Dateieintrag aktualisiert wurde, zeigt der Dateieintrag auf eine Position, wo nix mehr ist. Beim nächsten Start des Dateisystems gibt's noch den Journaleintrag, so dass festgestellt werden kann, dass die Schreibaktion nicht beendet war, und der Fehler wird behoben. Fällt der Strom weg vor dem Löschen des logs, stellt das System fest, dass der Vorgang doch korrekt durchgeführt wurde, und alles ist gut. Das Journaling braucht natürlich Zeit, und wenn zwei oder gar mehr Aufnahmen gleichzeitig stattfinden, wird sich das schon bemerkbar machen. Ich meine, in den ersten TDT-Releases war Journaling für sda3 noch drin und wurde dann wegen dieser Erwägungen herausgenommen. Aber ich kann mich irren.

TDT hatte doch von ext3 auf ext2 gewechselt für sda3 in einer älteren Version.
Wird schon so seinen Grund haben.

Einfache Messungen zeigen, daß ext3 deutlich langsamer ist:

/dev/sda3 (ext3)
tf7700:/mnt# time dd if=/dev/zero of=bigfile1 bs=1024 count=40000
40000+0 records in
40000+0 records out
real 0m 6.74s
user 0m 0.33s
sys 0m 5.94s
--------------------------------
/dev/sda3 (ext2)
tf7700:/mnt# time dd if=/dev/zero of=bigfile bs=1024 count=40000
40000+0 records in
40000+0 records out
real 0m 2.64s
user 0m 0.22s
sys 0m 2.33s

Beide Messungen wurde mit der gleichen Festplatte (SAMSUNG HD252KJ) gemacht.

Wow! Das ist drastisch viel mehr! Also nicht sehr ratsam, hier ext3 zu benutzen.

Danke für die Info.

Nach "Beobachtung" der Probleme und Problemchen in diesem und dem "anderen" Forum scheint es mir, als hätte Topfield bei der Hardwarebestückung in einem Zoo eingekauft, so unterschiedlich sind die beschriebenen Symptome.

Ich frage mich z.B., was ich mit einen HD-Recorder anfange, der HD-Aufnahmen nicht wiedergeben kann. Aber dieses Problem haben offenbar nur Wenige. Ich werde jetzt die Festplatte gegen ein 2.5" Modell tauschen und sehen, was dann passiert!

Mit der Original FW hatte ich das Problem, dass der Topf andere Sendungen aufnahm, als ich programmiert hatte.... Auch unbrauchbar...

"Little do we complain though we suffer much", sagen die Iren.

Immerhin halte im Falle meines Geräts Enigma trotz allem für die zuverlässig(er)e Alternative....

Was soll denn bitte eine 2,5 Zoll Platte ändern. Ich würde zur sicherheit zur Zeit nichts wiedergeben solange ich 2 Sender aufnehme.

Gruß