Filesystem grätscht bei stundenlangen (USB-)Transaktionen

0xdeadbeef

Neuling
Thread Starter
Mitglied seit
26.10.2003
Beiträge
220
Hallo,

ich habe gerade ein SEHR merkwürdiges Problem mit einem neu aufgesetztem XP nach heftigem HW-Update.
Und zwar verabschieden sich bei heftigen Zugriffen auf USB-Platten Teile (?) des Dateisystems.

PC:
Core i7-920, 3x2GB Corsair Dominator, Gigabyte EX58-UD4P (F9C), Gainward GTX 285 DualFan 1GB

USB-Platten
Maxtor 500GB (NTFS), WD MyBook 1TB (NTFS), WD MyBook 2TB (NTFS), PopCorn Hours A-110 mit WD Caviar Green 1TB (EXT3 über Ext2FSD eingebunden)

Eventuell problematische Software u.a.:
Kasperspy KIS 2010 (9.0.0.459/9.0.0.463), Daemon Tools Pro Advanced, SecuROM 7 (über Divinity II), Ext2FSD 0.48

Ich habe XP mittels Slipstream (SP3, SATA-Treiber, Chipsatz-Treiber) installiert.
In der Systemsteuerung werden 3GB RAM und "Physikalische Adresserweiterung" angezeigt.

Zunächst mal lief das System wirklich sehr stabil. Habe z.B. stundenlang bei hohen Raumtemperaturen Divinity II gespielt ohne jede Probleme.
Ich habe auch bereits mehrfach stundenlang alle drei Partitionen meiner beiden internen Platten (2x Samsung Spinpoint 250GB) defragmentiert und diverse stundenlange Videotranskodierungen laufen lassen. Alles kein Thema.
Die einzige Auffälligkeit war zunächst, daß mich Windows sporadisch zum Einlegen der Installations-CD aufgefordert hat, weil "einige Systemdateien durch unbekannte Versionen ersetzt wurden". Das habe ich auf die Slipstream-Installation geschoben und gehe eigentlich nach wie vor davon aus, daß das nichts mit dem Problem zu tun hat.

Problematisch wurde es, als ich angefangen habe, eine Datensicherung von meiner Popcorn-Hour auf die neue 2TB-Platte durchzuführen. Immer so nach ca. 200GB wurde der Kopiervorgang mit unterschiedlichen Fehlermeldungen abgebrochen. Danach war auch kein normaler Zugriff mehr auf die Platte möglich.

Zunächst mal habe ich das auf die Platte geschoben, aber über mein Netbook läuft die Kopieraktion ohne Probleme. Und dort sind ebenfalls KIS 2010 und Ext2Fsd installiert. Ein typisches Hardwareproblem der USB-Schnittstellen ist es wohl auch nicht, denn die Platten bleiben verbunden. Ich habe zwischen den beiden WD-Platten auch schon Kabel und Netzteile über Kreuz getauscht, aber das hat auch nichts geholfen. Habe natürlich auch ansonsten schon Kabel und USB-Ports getauscht und benutze die USB-Ports am Mainboard.

Meistens kann man auch noch Teile der Ordner öffnen und sogar auf viele der Dateien zugreifen. Aber Teile der Dateisysteme sind einfach verschwunden oder es kann nicht mehr darauf zugegriffen werden. Nach einem Reboot ist wieder alles in Ordnung.

Außerdem habe ich inzwischen festgestellt, daß im Fall des Falles alle Dateisysteme aller Platten (also auch der internen!) betroffen sind. Je nachdem ist es auch mehr oder weniger Zufall, ob zuerst die 2TB-Platte ausssteigt, auf die geschrieben wird, oder ob ein Lesefehler von einer anderen Platte zuerst gemeldet wird.

Zusammengefaßt habe ich also bei stundenlangen parallelen Dateioperationen zwischen diversen sehr großen Platten früher oder später Probleme mit dem Zugriff auf das Dateisystem aller Platten, obwohl es nicht physikalisch beschädigt ist. Obwohl das Problem früher oder später immer auftritt, ist es halt nur sehr zeitaufwendig zu reproduzieren. Tendenziell scheinen parallele Transaktionen zwischen den Platten früher zu Problemen zu führen als ein einfaches Kopieren von A nach B, aber auch das reicht tendenziell, wenn es nur lange genug dauert. Daher neige ich dazu thermische Probleme auszuschließen und es bleiben folgende Verdachtsmomente:

1) Meine gigantischen Platten und evtl. Ressourcenlecks in Windows/KIS führen dazu, daß XP interne Ressourcen ausgehen und sich das Filesystem aufhängt.
2) Heftige Last auf den USB-Kanälen führt bedingt durch Hardware oder Treiber zu einem Absturz des Filesystems.
3) Die physikalische Adreßerweiterung funktioniert nicht richtig und sobald Windows auf Speicher jenseits der 2GB (?) zugreift, kommt es zu Problemen.

Eigentlich neige ich dazu, Punkt1 anzunehmen (und ich fahre gerade seit zwei Stunden einen Test nach Update des KIS2010 auf 9.0.0.463), aber weil die Testerei so extrem zeitaufwendig und nervig ist, hätte ich halt gerne mal gewußt, ob jemand schon mal ähnliche Probleme hatte und wie er sie lösen konnte.

---------- Beitrag hinzugefügt um 16:33 ---------- Vorheriger Beitrag war um 13:06 ----------

Kleines Update: der letzte Test ist auch fehlgeschlagen. Wieder mit der Meldung "Nicht genügend Systemressourcen, um den angeforderten Dienst auszuführen".

Habe deshalb ein wenig recherchiert und in der Tat scheint es so zu sein, daß "normale" Kopierprogramme, also nicht nur der Explorer, sondern auch alternative wie Total Commander usw. beim Kopieren sehr großer Dateien (mit in meinem Fall mit 'zig oder bis zu 100GB) früher oder später den Kernel-Speicher erschöpfen, was zu einem (Teil-)Absturz des Betriebssystems führt.

In der Tat habe ich mal mit dem Process Explorer den "Kernel Memory" mitgemessen und der war nach der Fehlermeldung noch am Limit. Also kann man wohl davon ausgehen, daß er das Limit beim Auftreten des Problems überschritten hatte.

So eine richtig saubere Lösung scheint es für dieses Problem wohl auch nicht zu geben. In einschlägigen Abhandlungen wird die Verwendung von Robocopy oder TeraCopy empfohlen, die auf das Kopieren sehr großer Dateien optimiert sind. Ich teste gerade mal mit TeraCopy. Mal sehen, wohin das führt.

Ansonsten kann man wohl in der Registry neue Grenzwerte eintragen, aber das verschiebt ebenfalls nur das Problem, statt es zu beheben.

Immerhin scheint es dann wohl doch kein Hardware- oder Treiberproblem zu sein. Trotzdem irgendwie mal wieder reichlich unbefriedigend.
Es wird wirklich langsam Zeit auf Windows 7 mit 64bit zu wechseln...

Hier noch ein paar Links:
http://blogs.technet.com/markrussinovich/archive/2009/03/26/3211216.aspx
http://blogs.technet.com/askperf/ar...-management-understanding-pool-resources.aspx
http://technet.microsoft.com/de-de/library/cc976157(en-us).aspx
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
3) Die physikalische Adreßerweiterung funktioniert nicht richtig und sobald Windows auf Speicher jenseits der 2GB (?) zugreift, kommt es zu Problemen.

Wozu brauchst du PAE? Bei 3GB RAM bewirkt es gar nichts, außer du hast so viel Peripherie, dass der freie Adressraum innerhalb der 32 Bit für Speicher um 1/4 schrumpft. Und auch bei 4GB bringt der /PAE Switch meist nichts.
 
Eigentlich wird überall davon abgeraten, PAE ohne Not abzuschalten, weil man dabei u.a. auch die "Data Execution Prevention" verliert. Die 6GB kann ich mit und ohne PAE nicht benutzen, weil die 32bit-Versionen von Windows die PAE nicht wirklich sinnvoll nutzen. Die 6GB waren teils ein Vorgriff auf Windows 7 (64bit) und teils wegen des Triple-Channel-Zugriffs (3GB-Sets gab's irgendwie keine bezahlbaren).

Nebenbei bemerkt existiert das Problem natürlich auch bei abgeschalteter PAE. Nur halbiert die PAE anscheinend quasi den Speicherbereich bzw. jedes gepufferte Byte bei einem Dateizugriff verbraucht doppelt soviel Speicher im Kernel-Bereich.

Das ist wohl auch genau der Grund, warum ich das Problem bei meinem Netbook (2GB, kein PAE) noch nicht reproduzieren konnte. Dort steigt selbst mit TeraCopy der "Paged Kernel"-Verbrauch beim Kopieren großer Dateien genauso stetig wie auf meinem großen PC - nur halt deutlich langsamer. Großteils liegt das wohl daran, daß keine PAE aktiv ist - ein bißchen aber möglicherweise auch daran, daß das schwachbrüstige Teil einfach etwas langsamer kopiert.

[EDIT]
Obwohl es Berichte gibt, die behaupten, daß /nopae und /noexecute kombinierbar sein sollten, scheint meine ursprüngliche Annahme zu stimmen, daß "/nopae" nur mit "/noexecute=alwaysoff" zusammen funktioniert.
"/noexecute=optin /nopae" schaltet die PAE jedenfalls definitiv nicht aus.

[EDIT2]
Ok, nach einigen Fehlversuchen ist es mit mit "/EXECUTE" gelungen, PAE (und DEP) auszuschalten. Das sollte das Problem etwas entschärfen. Aber wie gesagt: weg ist es damit nicht. Auf meinem Netbook (auf dem ich gerade nebenbei wieder von der PCH auf die 2TB-Platte kopiere), ist der "Paged Kernel Memory" schon wieder auf über 212000 Bytes gestiegen - nach dem Kopieren von ca. 90GB per TeraCopy. Das Limit sind 364544 Bytes.
 
Zuletzt bearbeitet:
Ja - das Problem hab ich auch schon bemerkt beim Kopieren von sehr großen Dateien (mehrere 100 GByte). Mit Abschalten des PAE kann man es etwas lindern, aber eine wirkliche Lösung gibt es wohl nicht unter XP.

Da hilft wohl nur ein 64-Bit-OS, dann gibt es das Problem nicht mehr und die 6 GByte können auch sinnvoll genutzt werden !
 
Laut einer der verlinkten Seiten müßte das Problem bereits in Vista 32bit behoben bzw. extrem entschärft sein, weil dort der "Paged Kernel" dyamisch verwaltet wird und bis zu 2GB groß werden darf.

Wobei ich nach wie vor nicht verstanden habe, warum XP nicht mit einem Puffer von ein paar MB pro Kopieraktion auskommt, sondern der verwendete Kernelspeicher mit der Dateigröße linear wächst. Ist ja nicht memory mapped, sondern nur ein blöder Kopierpuffer.

Völlig unverständlich ist aber, daß der Speicher dann nicht mehr freigegeben wird. Selbst mehrere Stunden nach solch einer Kopieraktion ist der beutzte Kernelspeicher nur geringfügig gesunken - wenn überhaupt.

Diese beiden Punkte sind ja das eigentliche Problem.
 
Der belegte Speicher dürften die PTE's (Page-Table-Entries) sein, die der Festplatten-Cache aus irgendwelchen Gründen für die gecacheten Daten aufhebt. Ist vermutlich irgend ein Desgin-Problem im Windows-Kernel. Genaueres können wohl nur die Microsoft-Entwickler sagen.

Ob das jetzt im 32-Bit-Vista nicht mehr auftritt, kann ich nicht sagen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh