Dateiproblem bei udrec_suite

[Hai1961]

Udrec_suite läuft eigentlich ganz gut. Ausser, daß sich mein Linuxdateisystem jedesmal zerschiesst wenn ich irgendwas mit den aufgenommenen Dateien veranstalte (moven oder löschen).
Aufgenommen wird auf "/Aufnahme" auf hda1 (ca 30 GB). Die fertigen Dateien kommen nach "/daten/neu/Film" auf hdd5 (ca. 40GB). Diese Verzeichnisse sind für meinen Usernamen bearbeitbar. Die Partitionen sind ext3 formatiert. Als Betriebssytem kommt Debian zum Einsatz.

Folgende Probleme tauchen auf:
1. Lösche ich die Dateien in "/Aufnahme", egal ob als User oder root, behauptet mein Computer, daß ich danach ein nicht beschreibbares Dateisystem besitze und kein Programm arbeitet mehr vernünftig. Weitere Aufnahmen sind natürlich auch nicht mehr möglich.
Zunächst hatte ich gedacht, es liegt an Samba (das Verzeichnis ist freigegeben damit ich die Dateien auf einen anderen Rechner zum schneiden kopieren kann), aber auch bei lokalen Dateioperationen tritt dieses Problem auf.

2. Die fertigen Aufnahmen lassen sich nur als root verschieben oder löschen. Ebenso die von udrec_suite erstellten (Unter-)Verzeichnisse.

Nach Punkt 1 muss der Rechner neu gestartet werden und "fsck" per Hand ausgeführt werden damit es weitergehen kann. Das ganze ist reproduzierbar.

Any hints?

[sir-zock-a-lot]

Lösche ich die Dateien in "/Aufnahme", egal ob als User oder root, behauptet mein Computer, daß ich danach ein nicht beschreibbares Dateisystem besitze und kein Programm arbeitet mehr vernünftig.

Wie sieht denn die Behauptung auf der shell aus ?

Poste mal die Ausgabe von "fdisk -l /dev/hda"

Gruss,
Patrick

[Hai1961]

Ich habve gerade alles wieder in Ordnung gebracht, nachdem ich versuchte die Indiana Jones Aufnahmen von gestern zu löschen.

@counterstrike:~$ fdisk -l /dev/hda

Platte /dev/hda: 60.0 GByte, 60000000000 Byte
255 Köpfe, 63 Sektoren/Spuren, 7294 Zylinder
Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes

Gerät Boot Start End Blocks Id System
/dev/hda1 * 1 3647 29294496 83 Linux
/dev/hda2 3648 7294 29294527+ 5 Erweiterte
/dev/hda5 3648 3708 489951 82 Linux Swap
/dev/hda6 3709 7294 28804513+ 83 Linux

[Hai1961]

So nun habe ich wieder einiges aufgenommen und der Fehler trat natürlich wieder auf. Ich schreibe mal den Bildschirminhalt sinngemäß ab, da ich auf dem Linuxrechner nichts mehr speichern kann und auch kein Browser mehr was anzeigt (read/only Dateisystem).

Zunächst habe ich als User mittels "rm Dateiname" die v1 und ax Dateien gelöscht. Als Rückfrage kam ob ich die Datei XX (schreibgeschützt) löschen möchte. Ich habe alles mit ja beantwortet. Dann habe ich versucht die Dateien a0_a0 und a1_a1 zu löschen hierbei kam die Meldung, ob ich die symbolische Verknüpfung Datei XX entfernen möchte. Nach Bestätigung kam der Hinweis: Entfernen von XX nicht möglich: Das Dateisystem ist nur lesbar. Und danach hing der Rechner.

Was ist da los? Wieso kann ich als User schreibgeschützte Dateien löschen (ich denke das geht bei Linux nicht), was sind symbolische Verknüpfungen?

PS. Ich habe den Rechner jetzt noch mal hochgefahren. Eine Behandlung mit fsck war erforderlich. Im Aufnahmeverzeichnis waren die beiden symboliscchen Verknüpfungen und einige kleinere V1 und A e0 Dateien vorhanden. Diese liessen sich jetzt einwandfrei löschen.
Bei der vorher gelöschten V1 Datei handelte es sich um einen James Bond Film > 3GB. Könnte dies der Grund für die Crashes sein?

[sapsitapsi]

Hi Hai

Schick doch mal den Inhalt von /etc/fstab und den Auschnitt vor dem Reboot nach dem Crash auf /var/log/syslog.

CU,
sapsi

[Hai1961]

Ich habe mal die beiden Dateien herausgeholt und poste sie anbei. Im Syslog scheint nichts zu stehen. Der SMB Request kurz vor dem Crash war mein anderer Rechner der die Aufnahmedateien herunterkopiert hat.

Gestern abend haben wir noch einemal Simpsons und Sex and the City aufgenommen. Keine Datei war größer als 1,1GB. Sie liessen sich soeben, incl. symbolischer Verknüpfungen, einwandfrei löschen.
Liegt es doch an der Größe der Dateien? Aber warum tritt das Problem erst seit der neuen udrec_suite auf? Irgendwo im conf File der neuen Version fand ich eine Anmerkung das PX.ini irgendwas mit Dateien >1,5GB anstellt. Könnte das was damit zu tun haben. Diese symbolischen Verknüpfungen finde ich immer dann im Temp Verzeichnis wenn PX abgeschmiert ist. Das kommt bei mehr als 50% der Filme vor. Hat scheinbar nichts mit Linux zu tun, da PX auch unter Windows dieses Verhalten an den Tag legt.

Hier mal die Auszüge:

/etc/fstab:

/dev/hda1 / ext3 defaults,errors=remount-ro 0 1
/dev/hda6 /daten ext3 defaults,errors=remount-ro 0 0
/dev/hdd5 /daten/neu ext3 defaults,errors=remount-ro 0 0
/dev/hda5 none swap sw 0 0
proc /proc proc defaults 0 0
/dev/fd0 /floppy vfat defaults,user,noauto,showexec,umask=022 0 0
/dev/cdrom /cdrom iso9660 defaults,ro,user,noexec,noauto 0 0
# USB Kartenleser
usbdevfs /proc/bus/usb usbdevfs defaults 0 0
/dev/sda1 /usb/SmartMedia auto defaults,noauto,user,exec,rw 0 0
/dev/sdb1 /usb/CompactFlash auto defaults,noauto,user,rw 0 0
/dev/sdc1 /usb/SD-Card auto defaults,noauto,user,rw 0 0
/dev/sdd1 /usb/Memory-Stick auto defaults,noauto,user,rw 0 0
# Memory Stick
/dev/sde1 /home/user/mnt/Stick auto defaults,noauto,user,rw 0 0
# Samba Shares des Servers
//server/c-server /netz/server/c smbfs auto,gid=users,fmask=0664,dmask=0775,iocharset=iso8859-15,codepage=cp850,credentials=/etc/winpasswd 0 0
//server/d-server /netz/server/d smbfs auto,gid=users,fmask=0664,dmask=0775,iocharset=iso8859-15,codepage=cp850,credentials=/etc/winpasswd 0 0
//server/e-server /netz/server/e smbfs auto,gid=users,fmask=0664,dmask=0775,iocharset=iso8859-15,codepage=cp850,credentials=/etc/winpasswd 0 0
//server/f-server /netz/server/f smbfs auto,gid=users,fmask=0664,dmask=0775,iocharset=iso8859-15,codepage=cp850,credentials=/etc/winpasswd 0 0
//Papas-athlon/ide-papa /netz/papa/h smbfs auto,gid=users,fmask=0664,dmask=0775,iocharset=iso8859-15,codepage=cp850,credentials=/etc/winpasswd 0 0

/var/log/syslog:

Feb 17 17:10:07 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:11:21 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:12:35 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:13:49 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:15:03 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:16:17 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:17:01 counterstrike /USR/SBIN/CRON[333]: (root) CMD ( run-parts --report /etc/cron.hourly)
Feb 17 17:17:31 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:18:45 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:19:59 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:20:01 counterstrike /USR/SBIN/CRON[547]: (root) CMD ([ -d /etc/shaper ] && /etc/init.d/shaper timecheck)
Feb 17 17:21:13 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:22:27 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:23:41 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:24:55 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:26:09 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:27:24 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:28:38 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:29:52 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:30:01 counterstrike /USR/SBIN/CRON[1211]: (root) CMD ([ -d /etc/shaper ] && /etc/init.d/shaper timecheck)
Feb 17 17:31:06 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:32:03 counterstrike rpc.mountd: authenticated mount request from 192.168.0.207:714 for /daten/neu/Film (/daten/neu/Film)
Feb 17 17:32:20 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:33:34 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:34:48 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 17:35:32 counterstrike kernel: <5>smb_get_length: recv error = 5
Feb 17 17:35:32 counterstrike kernel: smb_request: result -5, setting invalid
Feb 17 17:35:32 counterstrike kernel: smb_retry: successful, new pid=345, generation=5
Feb 17 17:35:32 counterstrike kernel: smb_get_length: recv error = 5
Feb 17 17:35:32 counterstrike kernel: smb_request: result -5, setting invalid
Feb 17 17:35:33 counterstrike kernel: smb_retry: successful, new pid=350, generation=5
Feb 17 17:35:33 counterstrike kernel: smb_get_length: recv error = 5
Feb 17 17:35:33 counterstrike kernel: smb_request: result -5, setting invalid
Feb 17 17:35:33 counterstrike kernel: smb_retry: successful, new pid=353, generation=5
Feb 17 17:35:33 counterstrike kernel: smb_get_length: recv error = 5
Feb 17 17:35:33 counterstrike kernel: smb_request: result -5, setting invalid
Feb 17 17:35:34 counterstrike kernel: smb_retry: successful, new pid=356, generation=5
Feb 17 17:36:02 counterstrike ypbind[520]: broadcast: RPC: Timed out.
Feb 17 18:00:58 counterstrike syslogd 1.4.1#13: restart.

[sapsitapsi]

Moinsen

Das sieht eigentlich alles ganz gut aus. Jetzt aber die wichtigste Frage:
welche Distribution in welcher Version mit welchem Kernel setzt du ein?

[Hai1961]

Ursprungssystem Knoppix 3.3. Nach Anweisung aus http://www.debianforum.de/forum/viewtop ... highlight= auf Debian unstable umgewandelt. Kernel ist 2.4.22

[sir-zock-a-lot]

Aber warum tritt das Problem erst seit der neuen udrec_suite auf? Irgendwo im conf File der neuen Version fand ich eine Anmerkung das PX.ini irgendwas mit Dateien >1,5GB anstellt. Könnte das was damit zu tun haben.

Mit der udrec_suite hat dein Problem _definitiv_ nix zu tun. Eher wuerde ich auf defekte Hardware tippen. Mal ne andere Platte getestet ? Neu formatiert ? Als "ext2" gemountet ? Hier ist etwas Kreativitaet beim Debuggen gefragt.

Patrick

[Hai1961]

Bei beiden Platten im Rechner tritt das Problem auf. Lt. /etc/fstab ist ext3 gemountet
Das Problem läßt sich jetzt weiter einkreisen: Ich hatte wieder zwei Filme aufgenommen. Die V0 Dateien waren 1,6 und 2,3 GB groß. Die a0 Dateien ließen sich ohne Probs. löschen. Die kleine v0 ging auch. Aber nach Löschversuch der großen Datei kam wieder die Fehlermeldung, daß das Dateisystem nur lesbar ist. Und nichts geht mehr.
Das Problem liegt also anscheinend in der Dateigröße.