dd-Kommando hängt

[bluelupo]

Hallo zusammen,
ich habe mit einen LENOVO T60 z.Zt. ein Problem beim Schreiben großer Dateien (vermute ich) auf ein NAS das per NFS gemountet ist. Das Problem liegt vermutlich am Kernel 2.6.38-5 (Distrubution aptosid) oder systemnahen Paketen die upgedatet wurden.

Die Situation stellt sich folgendermaßen dar. Wenn ich eine Sicherung einer LVM-Partition mit dem dd-Kommando auf das NAS-Laufwerk schreibe hängt seit einigen Tagen das Shellscript. Die CPU-Last steigt durch das dd-Kommando auf 100% und es wird nicht mehr weiter geschrieben. Nach einer Rücksicherung (Stand 22.04.2011) des System läuft alles wieder korrekt. Nach der Rücksicherung habe ich den Kernel 2.6.38-3.slh.4-aptosid-686.

Testweise habe ich, ausgehenden von diesem Stand, nur den Kernel upgedatet (auf 2.6.38-5.slh.1-aptosid-686). Es wurden nicht nur der aptosid-Kernel aktualisiert, sondern auch der gcc und paar zugehörige Komponenten (kann ich nicht mehr genau festellen). Danach trat wieder das gleiche Fehlerbild auf.

Hat jemand von euch ähnliche Probleme oder ist das ein bekanntes Problem des aktuellen Kernels?

Hier die Paketliste nach der Rücksicherung des Systems (aptosid).

[gnude]

Ufff.
die Zieldatei von dd kannst du dir ja ansehen, wächst sie weiter?
Oder bleibt sie bei einer bekannten Grössenbeschränkung (2GB Fat, oder irgendwas anderes Dateisystemspezifisches) hängen?
Alternativ gibt es ddrescue, falls du nen kaputten Block hast, läuft das trotzdem weiter.

[bluelupo]

Ufff.
die Zieldatei von dd kannst du dir ja ansehen, wächst sie weiter?
Oder bleibt sie bei einer bekannten Grössenbeschränkung (2GB Fat, oder irgendwas anderes Dateisystemspezifisches) hängen?
Alternativ gibt es ddrescue, falls du nen kaputten Block hast, läuft das trotzdem weiter.

Hi gnude,
nein die Zieldatei wächst nicht weiter an, d.h. sie bleibt auf einer bestimmten Dateigröße. Was auffällt ist das die CPU-Last am Notebook für eine CPU dann auf 100% steigt und ihn somit unbedienbar macht. Das Dateisystem vom NAS (Synology DS211 2x 2TByte) ist ein ext4.
Wie gesagt das ganze funktioniert wieder wenn ich den Backup mit dem "alten" Kernel 2.6.38-3 und mit dem letzten Dist-Upgrade vom 19.04.2011 einspiele. Ich weiß nicht ob das mit dem Kernel direkt zusammenhängt, das ist nur eine Vermutung von mir. Defekte Sektoren kann ich ausschließen, da erstens das NAS noch keine 4 Wochen alt ist und zweitens dann die defekten Sektoren bei jeder Konstellation vorhanden wären und sich bemerkbar machen würden.