"Delayed Write Failed" Fehlermeldung bei Windows XP

[KlausZettel]

Hi,

ein Windows XP-Rechner dient nebenbei als File-Server (Am Rechner ist ein externes RAID5-SCSI-System angeschlossen mit 1,8 TB Festplattenplatz).

Leider hat die Schreibleistung zuletzt arg nachgelassen. Und wenn man nun lokal Dateien koppiert kommt die Fehlermeldung: Windows "Delayed Write Failed". Die genaue Fehlermeldung habe ich leider in der Firma liegen lassen, aber es geht darum, dass die Datei f:\$BitMap nicht kopiert werden konnte, und die Daten nun verloren sind, wegen eines Hardware oder Netzwerkfehlers.

Bei MS findet man einen entsprechenden Artikel in der Datenbank.

Danach liegt der Fehler beim Schreibcache:

CAUSE

This issue may be caused if any of the following conditions exist:

• The "Enable write caching on the disk" feature for your disk is turned on.

Spielt UDMA bei SCSI Festplatten (Systempartition) eine Rolle? Und leidet die Datenrate beim Kopieren nicht, wenn man den Schreibcache ausschaltet?

[TobiK]

Moin,

Write Caching ist per default meistens eingeschaltet. Wir haben das bei unseren DC's und Exchange-Servern immer ausgeschaltet.

Der SCSI-Controller nimmt die zu schreibenden Daten entgegen und packt sie in seinen RAM. Danach versucht er sie auf die Platte(n) zu schreiben. Wenn das aus irgendeinem Grund fehl schlägt, erscheint diese Meldung.

Ich würde es zum Testen einfach mal abschalten und gucken, ob das Problem immer noch auftritt. Wenn ja, ist warscheinlich eine der Platten hinüber, oder das Raid inkonsistent.

P.S. Windows XP als Fileserver halte ich für keine so gute Idee

[hommling]

Spielt UDMA bei SCSI Festplatten (Systempartition) eine Rolle? Und leidet die Datenrate beim Kopieren nicht, wenn man den Schreibcache ausschaltet?

UDMA bedeutet Ultra-Direct-Memory-Access und ist ein Zugriffsprotokoll des ATA-Standards. Das hat erstmal nichts mit SCSI zu tun. Bei SCSI verwendete Zugriffsprotokolle lauten SCSI-1, SCSI-2 bzw. Fast-SCSI oder Wide-SCSI, SCSI-3 bzw. Ultra-SCSI, Ultra2-SCSI, Ultra3-SCSI bzw. Ultra160-SCSI, Ultra320-SCSI und theoretisch Ultra640-SCSI. Letzters hat sich nicht durchgesetzt und wurde von SAS (Serial Attached SCSI) abgelöst.

Aber zurück zur Frage: Ich denke, dass es davon abhängt, inwiefern das System mit weiteren Prozessen ausgelastet ist. Der Schreibcache nimmt ja die Schreibbefehle, die letzendlich von der CPU kommen, entgegen und sagt der CPU: "Kümmer Du Dich bereits um andere Aufgaben. Ich schreibe die Daten gleich auf die Platte!". Es soll also die CPU dabei entlastet werden. Ich habe jedoch in anderen Foren bereits gelesen, dass durch Aktivierung des Schreib-Caches die Datenraten auch schon gesunken sein sollen. Am Besten probierst Du es aus und misst die Ergebnisse mit einem Benchmark-Tool.

P.S. Windows XP als Fileserver halte ich für keine so gute Idee

Warum denkst du das?

Gruß

hommling

[TobiK]

Warum denkst du das?

Da fällt mir z.B. ein:

Userverwaltung ist unpraktisch, und nur mit lokalen Usernamen machbar

Offiziell nicht vorgesehen (sagt aber noch nicht viel aus)

Höhere Grenzen der unterstützten Hardware

Aus Prinzip (Desktop-OS bleibt für mich ein Desktop-OS )

Grüße,

Tobi

[hommling]

Hi!

O.K. Nicht alles einleuchtend, kann mann aber stehen lassen.

Also ich würde anführen, dass XP maximal 10 Verbindungen zulässt. Der elfte schaut also in die Röhre. :hells:

Gruß

hommling

[KlausZettel]

Erstmal vielen Dank für eure Antworten!

Der Rechner dient eigentlch als Grafik-Workstation für die Auswertung von Mikroskopieaufnahmen von Zellen. Jede xte Millisekunde wird ein Bild gemacht, so dass man sehen kann wie die Zellen wachsen oder zerfallen, das ganze in 3D.

Dabei fallen große Datenmengen an, die auf dem RAID gespeichert werden müssen.

Da noch etwas Platz ist, ist der Gruppenleiter auf die Idee gekommen, den RAID auch noch als Speicherplatz für die Gruppendokumente zu verwenden.

Insgesamt greifen jetzt max. 1 Linux-Rechner, 1 Windows-Rechner und 3 Macs auf die Daten auf dem RAID zu. Das ist mit XP Prof noch handelbar, denke ich.

Wäre die Datenrate beim Zugriff der Daten nicht so schlecht geworden, hätten wir davon auch nichts mitbekommen.

Aber nun zum Problem.

Beim externen RAID (F:\) kann man nicht auswählen, ob man den Schreibcache ausschalten will, der Reiter ist nur grau, bei der SCSI (C:\) und der SATA (E:\) geht's.

Bei beiden abgeschaltet und danach wollte WIndows einen Neustart.

Nach dem Neustart hat dann Windows erst mal nicht mehr gebootet, bis ich bei der SCSI C:\ Partition ein CHKDSK in der Wiederherstellungskonsole hab laufen lassen.

Danach ging es wieder.

Nun habe ich testweise vom e:\ und f:\ große Dateien auf den Desktop kopiert, was auch nun sehr gut klappte. (Beim Koppieren innerhalb von f:\= RAID kommt die "Delayed Write Failed" Fehlermeldung immer noch).

Nach einem weiteren Reboot, (einfach um zusehen, ob es diesmal geht) kam nun die Meldung, dass unter anderem die Dateien wininit.dll und explorer.exe korrupt wäre und ein chkdsk erforderlich wäre.

Das chkdsk habe ich dann ausgeführt mit dem Resultat, dass chkdsk die wininit.dll gelöscht hat.

Windows bootet zwar. Aber nach dem Anmelden kann man nicht arbeiten, weil die explorer.exe nicht geladen wird.

Morgen kopiere ich die explorer.exe und die wininit.dll wieder über die Wiederherstellungskonsole. Vielleicht klappt das ja und Windows ist wieder funktionsfähig bis zum nächsten Reboot.

[hommling]

Hi!

Morgen kopiere ich die explorer.exe und die wininit.dll wieder über die Wiederherstellungskonsole. Vielleicht klappt das ja und Windows ist wieder funktionsfähig bis zum nächsten Reboot.

Entweder das oder Du nimmst, bei Versagen der Wiederherstellungskonsole, die Notfallreparaturkonsole und installierst Windows XP einfach drüber. Anschließend nicht vergessen, das aktuelle Service Pack zu installieren.

Gruß

hommling

[KlausZettel]

Noch habe ich nicht ganz aufgegeben.

Das Kopieren der wininet.dll Datei in der Wiederherstellungskonsole hat nicht funktioniert. Danach habe ich wieder Windows hochgefahren, mich angemeldet und mit dem Task-Manager die cmd-Shell gestartet (Da die Explorer.exe nicht funktioniert hat man keine Desktop-Umgebung, das verhalten ist so wie bei twm).

Diesmal kam beim Kopieren der wininet.dll eine error Fehlermeldung.

Beim nächsten chkdsk, aus diesem Modus kommt man gar nicht mehr raus, wurde dann die shell32.dll gelöscht. Damit hat sich die Benutzer-Anmeldung auch erledigt.

Wegen den Meldungen: "filesegments 35036 - 35039"are "unreadable" und "38756-38759" are "unreadable". läuft gerade der Drive Fitness Test von Hitachi. Vielleicht hat die SCSI-Festplatte eine Schaden.

Irgendwie habe ich mich jetzt etwas arg von der ursprünglichen Fragestellung entfernt, ich werde nochmals darauf zurückkommen, wenn ich Windows neu installiert habe.

[KlausZettel]

Disk Fitness Test meldet einen Festplattensektorfehler. "Sektor Repair" funktioniert nicht. "Erase Disk" würde ich mir gerne ersparen und würde wahrscheinlich auch nichts bringen

Es wird wohl darauf hinauslaufen, dass ich die Platte über den Händler umtauschen lassen muss.

Immerhin ist das mal eine Gelegenheit "Data Rescue II PC" auszuprobieren.

Zum Glück ist bald verlängertes Pfingstwochenende.

[TobiK]

Was ist das für ein Raid-Controller?

Normalerweise kopiert ein Raidcontroller den Datenmüll nicht mit auf die noch funktionierenden Festplatten.

Hab das nur schon öfters bei Promise, etc. beobachtet.

[KlausZettel]

Das RAID ist von Infortrend . Zu diesem RAID haben wir einen Supportvertrag dazugekauft. (Wir haben noch ein baugleiches Modell von einem anderen Händler ohne diesen Supportvertrag.)

Am Dienstag rufe ich mal beim Service an und frage mal nach.

[KlausZettel]

Die Fehlermeldung "Delayed Write Failed" kam in meinem Falle tatsächlich von der defekten SCSI-Systemplatte. Mit der neuen Platte gibt es diese Fehlermeldung vom RAID nicht mehr.

Die Transferraten sind nun auch wieder besser. Mal sehen was sich da noch rausholen läßt.