[gelöst: Festplatte defekt]Kopieren (Schneiden Filme kopieren) extrem langsam

Zitat von Salvi 5

Wie kriege ich raus ob mir die Platte die Hufe reisst, oder ob ich irgendwo was drehen muss?

Wie wäre es mit ein paar S.M.A.R.T. Tests: http://wiki.ubuntuusers.de/Festplattenstatus ?

Zuerst dmesg, schauen ob HDD bezogene Fehler kommen oder der DMA Modus abgeschaltet wird (gerne bei gammligen HDD Datenkabeln).
Und zur Sicherheit schadet ein langer SMART Selbsttest (läuft im Hintergrund auf der HDD selber und dauert Stunden) auch nicht.

Starke Fragmentierung kann auch ne Ursache sein.

cu

Zitat von Salvi 5

Danke für die Tippse. Ich hab jetzt mal dieses smartctl gestartet. Können diese Geschwindigkeitsverluste tatsächlich eine defekte Platte bedeuten?

Möglich, aber dann würde ich was im Syslog erwarten.

Was sagt denn das Gehör? Wenn sie beim kopieren die meiste Zeit damit beschäftigt ist den Kopf durch die Gegend zu schieben wäre das auch ne Erklärung. Leider gibts für Linux keine brauchbaren Defrag Programme weil Linux aufgrund der Definition das Problem nicht kennt

cu

prüf mal ob markad parallel läuft und den zu kopierenden film scannt. fast alle probleme sind bei mir auf dieses tool zurück zu führen, wenn es um leistungs probleme geht.

Zitat von Salvi 5

seit kurzem ist es mir fast unmöglich Filme zu schneiden. Der Schnittvorgang, der ja nix anderes ist, als ein Kopiervorgang dauert erstens ewig lange (schon mal 10-15min für einen 4 GB Film) und zweitens brauche ich während dieser Zeit nicht mal daran zu denken, am VDR was anderes zu machen. Der blockiert sofort, wenn ich Glück habe wird nur das Menü unbedienbar, wenn nicht, verschwindet das Bild und ich darf mir die ganze Zeit "NoSignal" anschauen. Ich habe 5 Platten, davon 2 IDE, der Rest SATA. Von dem Problem scheint aber nach diversen Kopierorgien nur die eine IDE-Platte betroffen zu sein.

Kenn ich auch von meinem AMD System (Lucid s.Sig.), bin ebenso ratlos. Platte schnell, keine Fehler, markad ist nicht die Ursache.

Ist aber ein Thema das sich über VDR Versionen angebahnt hat und immer schlimmer wurde. Es fing damit an das laufende HD Aufnahmen durch Schnittoperationen (SD & HD) gestört wurde. Es war noch nie auf dem System möglich eine zweite Aufnahme sinnvoll für den Schnitt vorzubereiten, super zäh.

Jetziger Stand entspricht ungefähr Deinem Verhalten, man schmeißt den Schnitt einer HD Aufnahme an, Live VDR Betrieb ist noch drin, auch OSD, aber wehe man versucht parallel eine Aufnahme anzuschauen. Es ist auch egal ob eine Aufnahme läuft oder nicht, also markad, diese wäre eben dann "nur" fehlerhaft. Die letzten Prozent der Verschlechterung kamen mit der Aktivierung von "xmltv2vdr".

Aber auf dem Test-VDR mit dem Single Core Celeron G440 nebendran (Precise s.Sig.), funktioniert der gleiche Umfang an VDR & Plugins (auch xmltv2vdr) problemlos. Ich kann während einer laufenden HD Aufnahme, weitere Aufnahmen schneiden lassen und während dessen weitere Aufnahmen vorbereiten.

Mein Eindruck ist, irgendwas läuft hier bei meinem AMD System mit der Verteilung auf die Threads "schief". Du bist der Erste, der das gleiche Problem berichtet, dann ist es doch eher nicht nur mein HW, mal sehen ...

Regards
fnu

Zitat von Salvi 5

@ traxanos
markad kann ich ausschließen, ich habs deinstalliert und das Problem besteht weiterhin.

das hätte sich wenn auch mit 100% cpu last gezeigt.

Zitat von Salvi 5

BTW: man konnte doch irgendwie mit dd viele Daten auf ne Platte schreiben, weiß zufällig noch jemand wie das ging?

Für sowas würde ich bonnie bzw. bonnie++ nehmen, schau mal ob das im Repo ist.

ansonsten:

dd if=/dev/zero of=Datei_auf_Platte bs=1M count=1024

schreibt 1GB Nullen. Alternativ direct auf das device schreiben (umgeht Dateisystem - aber das scheint ja nicht das Problem zu sein?)

Zitat von Salvi 5

Nur die Schreibvorgänge auf die Platte sind extrem langsam und gehen nur schubweise voran.

Hmm, scheint dann ein anderes Problem als bei mir zu sein, ausserhalb der VDR Funktion rennt die Maschine wie sie soll:

hdparm -tT /dev/sda/dev/sda: Timing cached reads:   3570 MB in  2.00 seconds = 1785.48 MB/sec Timing buffered disk reads:  250 MB in  3.01 seconds =  83.15 MB/sec

dd if=/dev/zero of=./testfile bs=1M count=10241024+0 Datensätze ein1024+0 Datensätze aus1073741824 Bytes (1,1 GB) kopiert, 4,4977 s, 239 MB/s

Aber die Größe der Datei muß so gewählt werden das die Buffer während des Schreibens überschrieben werden müssen und durch den WriteThru Effekt die Daten der HDD zum Vorschein kommen:

dd if=/dev/zero of=./testfile bs=1M count=1024010240+0 Datensätze ein10240+0 Datensätze aus10737418240 Bytes (11 GB) kopiert, 115,027 s, 93,3 MB/s

rsync Raten betragen 40-50MB/s, ftp Transfers peak'en auf 90MB/s+. Hier mal bonnie++, weil's angesprochen wurde:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CPvdr1             8G  1045  95 84314  12 40812  13  2085  85 98908  15 184.7   7Latency             12627us    1726ms    5726ms   95445us     113ms     756msVersion  1.96       ------Sequential Create------ --------Random Create--------vdr1                -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP                 16  1720  14 +++++ +++  1535  10  1767  15 +++++ +++  1483  10Latency               105ms     273us   68124us     114ms      90us     168ms

"dd" ist aber ein schlechter Benchmark, weil single threaded und punktuell. Moderne Platten und Dateisysteme werden bei parallelen Zugriffen erst richtig flott.

Die Probleme treten nur innerhalb VDR Betrieb auf, ansonsten nicht, insofern bin ich seit Wochen und Monaten ratlos.

=> [edit] Genauer gesagt tritt das Problem nur auf, wenn ich Aufnahmen schneiden lasse. Kopieren innerhalb und ausserhalb VDRs machen keinerlei Probleme ... [/edit]

Ich kann mit dem Gerät 16 Aufnahmen von 4 Transpondern parallel machen, mehrheitlich HD, und keine dieser Aufnahmen ist dann fehlerhaft. Zu Erinnerung, da laufen dann auch 16x markad ...

Regards
fnu