GPT Loader verlangsamt System beim Kopieren durch volle RAM-Auslastung bis auf 4MB

Durfte bei einem Kunden ein Kopierproblem an mehreren PC analysieren und konnte ihren Treiber als Ursache ausmachen.

Der Ursache auf die Spur zu kommen war zu erst nicht ganz einfach, da man auch vermuten könnte, daß Registry Einstellungen wie Largesystemcache usw. unter Windows der Grund sein könnten, da der Systemcache bzw. Dateicache extrem anwächst und der verfügbare Ram bis auf die minimalen 4MB für den Windowskernel voll aufgebraucht wird.

Dem ist jedoch nicht so.

Tatsache ist, daß sich das Verhalten explizit gezielt reproduzieren läßt. Die eine PC Hardware ist sehr modern z.B.
ASROCK FM2A88M-HD+ mit A10-7800 APU und die Festplatten sind alle Sata3. Da der GPT Treiber nur im IDE Kompatibilitätsmodus arbeitet, kann leider nicht die volle AHCI Durchsatz erreicht werden aber trotzdem ist die Ursache eindeutig, da bei 2 anderen 6 Jahre ältere PCs hingegen genau dasselbe Phänomen auftrat. Es werden auch nur die Standard MS Treiber (Standard-Zwei-Kanal-IDE-Controller) genutzt, wie von ihnen gefordert. Denn mit anderen Controller Treibern arbeitet ihr GPT Loader ja nicht zusammen. Er benötigt den IDE Modus, die MS Standardtreiber und darf nur an einem direkten IDE/SATA Port des MBoard-Chipsatzes hängen. Also kein JMicroncontroller. All dies ist erfüllt und funktioniert auch.

Erst das Kopieren von großen Datenmengen ab 4GB (also über die Größe des verbauten RAM Speichers hinaus) auf oder von der 3TB GPT Festplatte führt dazu, daß unter WinXP 32bit der Systemcache extrem bis auf 2,5GB anwächst, während der verfügbare RAM bis auf 4MB runter geht also die 4GB RAM ausgeschöpft sind. Kann man gut im Taskmanager verfolgen, sobald man einen Ordner kopiert mit entsprechend großem Inhalt. Da XP kein GPT von Haus aus unterstützt, wird also für die Dateioperationen der mit dem Paragon Diskmanager 12 mit installierte GPT Loader Treiber benutzt.

Das Problem fällt zuerst auch nicht auf, wenn man immer nur einzelne Dateien kleiner 4GB kopiert, da der RAM nach dem Kopieren bzw. dem Schreibvorgang wieder frei wird und im Taskmanager der zuvor belegte RAM-Wert wieder dem verfügbaren RAM als zugewiesen angezeigt wird, obwohl der Systemcache(Dateicache) weiterhin bei 2,5GB verweilt. Das System wirkt nur ein wenig Träge aber nach einer Minute kann man gleich Programme wieder starten. Füllt man die 3TB Festplatte also mit der Zeit nach und nach fällt einem dies wohl nicht auf. Doch kopiert man dann auf einen Schlag z.B. 20GB oder mehr auf eine andere Festplatte, dann fällt einem auf, daß der Kopiervorgang am Anfang angeblich wahnsinnig schnell ist bei gutem RAM (2400Mhz) und dann plötzlich sich schlagartig verlangsamt und das gesamte System gleich mit. Selbst das Startmenü braucht Minuten zum Aufklappen, solang der Kopiervorgang läuft. Der PC reagiert nicht. Das Wechseln zu anderen offenen Anwendung ist fast unmöglich. Neue Programme zu starten, funktioniert erst nach Ende oder Abbruch des Kopierdialogs.

Dieses Verhalten tritt genau in dem Moment auf, wenn nur noch 4MB freier RAM verfügbar ist. Bricht man den Kopiervorgang ab, reagiert das System noch immer einige Zeit träge, obwohl angeblich schon viele Dateien kopiert wurden. Doch der Kopiervorgang ist ja noch gar nicht beendet. Obwohl nun der Kopiervorgang abgebrochen ist, leuchtet nämlich noch immer die Festplatten LED und zeigt munter Schreibzugriffe an. Sobald die Festplatten-LED am PC-Gehäuse nicht mehr blinkt, reagiert das System wieder normal.

Bedeutet also, daß ihr GPT Loader Treiber die zu kopierenden Dateien zuerst, soweit RAM verfügbar ist, wie wild in diesen freien RAM schaufelt, bis nichts mehr geht und gar nicht sofort auf die Festplatte schreibt, sondern erst nach und nach aus dem RAM auf die Platte überträgt.
Dies zeigt auch das Verhalten im Taskmanager, da der RAM während des Kopiervorgangs zeitweise auch wieder verfügbar ist, wenn wohl die Schreibzugriffe für die zuvor gecachten Dateien abgearbeitet wurden. Aber diese Freigabe währt nur kurz, da sofort danach wieder der RAM mit den noch nicht kopierten Dateien erneut voll befüllt und das System wieder nicht reagiert, bis diese kopiert bzw. geschrieben wurden und die nächsten nachgeschoben werden, bis das Kopieren vollständig abgeschlossen ist.

Dabei ist es egal, ob von der 3TB GPT HD zu einer USB oder internen SATA3 320GB Platte kopiert wird. Hingegen das Kopieren von einer anderen MBR 320GB Platte auf eine USB MBR Platte und umgekehrt beläßt die RAM-Auslastung unverändert. Auch ist das Kopieren von anderen MBR Datenträgern erheblich schneller untereinander, wie man es auch normal erwarten würde. Auch friert das System dann nicht kurzfristig ein, bis die nächste Datei gelesen oder geschrieben wurde. Es liegt also nicht an der Hardware. Jedenfalls solange ihr GPT Treiber nicht beteiligt ist, verhält sich das Kopieren unter Windows normal und ohne Nutzer Einschränkungen. Programme können parallel benutzt werden.

Auch die 3TB Festplatten sind fehlerfrei und in einer durchgehenden GPT Partition unter Windows Vista zuvor eingerichtet und worden und unter WinXP verbaut worden. Also eine Fehlformatierung oder Fehlausrichtung der Sektoren kann auch nicht vorliegen.

Nur beim Kopieren von großen Datenmengen mit ihrem GPT Loader beschriebenen 3TB oder 4TB Platte tritt das Problem beim Kopieren auf. Das ist in sofern ärgerlich, da sich keine weiteren Programme mehr öffnen oder nutzen lassen, solange der Kopiervorgang nicht abgeschlossen ist, wenn der RAM erstmal voll gelaufen ist.

Glücklicherweise kopiere ich Daten und vergleiche diese nachträglich binär anstatt diese auszuschneiden und einzufügen. Denn dann wäre es schon ziemlich fatal, wenn bei kleineren Datenmengen angeblich der Kopiervorgang fertig ist, obwohl die Festplatten-LED blinkt. Wer hier statt eines Schreibzugriffs, der ja offensichtlich der Grund für das Blinken trotz angeblich fertigem Kopieren ist, nun bloß einen Lesezugriff darin sieht und das System ausschaltet, hat einen Datenverlust. Auch bei einem Stromausfall wären die Daten möglicherweise verloren, da der Windowsdialog zum Kopieren schon längst geschlossen ist, wenn die Dateien im RAM gelesen wurden und obwohl diese nun erst geschrieben werden. Strom weg, gleich RAM-Inhalt auch weg aber Windows hat beim Verschiebedialog die Originaldateien auch schon gelöscht. Sehr fatal, weshalb ich den Kunden auch auf diese Möglichkeit hingewiesen habe, da ich nicht genau weiß, wie ihr GPT Loader nun tatsächlich arbeitet. Jedoch das bisherige RAM verhalten und die weiter bestehenden Schreibzugriffe trotz geschlossenem Kopiervorgang sprechen für sich.

Es mag zwar sinnvoll sein, den RAM-Speicher zum Cachen von Dateien zu benutzen aber der Kopiervorgang von großen Datenmengen sollte das System nicht derart ausbremsen und der Windowskopierdialog sollte nicht vorzeitig geschlossen werden, wenn die Daten in Wirklichkeit noch gar nicht fertig geschrieben wurden.

Dieses Auslastungsphänomen konnte ich an 3 PCs mit unterschiedlicher Hardware reproduzieren. Dabei ist zu vermerken, daß nur der RAM voll ausgelastet ist. Die CPUs werden nicht belastet.

Prinzipiell ist es schon mal sehr lobenswert, daß dieser Treiber tatsächlich funktioniert und auch 3TB und größere Festplatten unter XP im GPT Format vollwertig unterstützt. Nur scheint ihre auf der SCSI Schnittstelle basierende Lösung wohl noch einiger Optimierungen zu bedürfen, da die Durchsatzgeschwindigkeit bei gerade mal 8,33 MB/sekunden liegt. Das soll wohl das Cachen im Ram kaschieren. Doch sobald der RAM voll ist, wird es sehr deutlich. Vielleicht sollten Sie eine Begrenzung einbauen, so daß wenigstens noch 500MB freier Ram für andere Anwendungen unangetastet bleiben.

Aber bei einer Auslastung bis auf 4MB macht das Kopieren und arbeiten mit dem PC definitiv keinen Spaß. Da kann man eigentlich nur über Nacht den Kopiervorgang starten aber jedoch parallel keine Programme laufen lassen. Wozu ich dem Kunden aktuell auch nur raten konnte, da ich nirgends GPT Loader Einstellungsmöglichkeiten finden bzgl. des RAM-Ausnutzungsverhaltens.

Die verwendete GPT Loader Version entstammt wohl dem Paragon Festplatten Manager Suite v12.

Da ich bisher keine Hinweise auf dieses Verhalten im Internet finden konnte, wollte ich mal hier um eine Stellungnahme dazu bitten, da ich auch überhaupt keine Möglichkeit gefunden habe, irgendwelche Einstellungen am GPT Loader vornehmen zu können, da er ja einfach wohl nur mit dem Disk Manager 12 mit installiert wird.

Wurde der GPT Loader vielleicht noch seit der Version 12 in den neueren Festplattenmanager Version 14 oder 15 weiter entwickelt und diesem Verhalten schon entgegen gewirkt?

Danke für eine Rückmeldung.

Hallo,

Nachdem Sie sich ja auch an mein blog (hardwarefetish.com) gewendet haben, hier mal das, was ich bis jetzt als Grund dafür ausmachen konnte. Ich habe zwar sehr wenig Hoffnung, dass bei Paragon den Treiber noch jemand repariert, nachdem selbst mein zuletzt gefundener Fehler samt Patch meiens Wissens nach bis Dato nicht repariert wurde, aber hier mal die vorläufige Fehleranalyse, wobei ich keine Ahnung habe, wie der Fehler zu beseitigen ist.

Im Windows NT Cache Manager werden von der Speicherverwaltung Cacheseiten für die Quelldatei reserviert, die dann bei einem Page Fault durch Anforderung an den Storage Treiber befüllt werden. Der Cache Manager fordert also ein Einlesen der Speicherseiten an. Hierzu wird ein IRP_MJ_READ Request abgesetzt. Der Paragon gpt_loader reiht das IRP in der Dispatch Routine in seinen internen Workerthread ein, sofern es sich um einen Zugriff handelt, welcher über die Diskgrenze hinausgeht und damit speziell behandelt werden muss. Soweit ja bekannt aus meinem Blog.
Im Arbeitsthread wird dann der Zielpuffer mit MmGetSystemAddressForMdlSafe(Irp->MdlAddress, HighPagePriority) als virtuelle Zieladresse referenziert (also ein PTE auf die MDL gelegt, damit man was reinkopieren kann). Diese Adresse wird dann als Zielpufferadresse im ATA_PASS_THROUGH_DIRECT struct für einen IOCTL_ATA_PASS_THROUGH_DIRECT IOCTL angegeben und ein ATA 48bit DMA read (oder write, je nach Anforderung) angestoßen, der dann den Zielpuffer bei Read befüllen sollte und dies auch tut.
Die MDL braucht man nach erfolgtem Lesevorgang nicht separat freigeben, das macht der IO Manager für uns.
So, nachdem nun in die MDL (den Zielpuffer) gelesen wird, wird dieser in der Seitentabelle als "Modified" markiert und hat somit das dirty-bit gesetzt. Nachdem der Cache Manager nun von seinem IoReadFile zurückkehrt und gewartet hat, bis die Seite befüllt ist, dereferenziert er die Seite wieder (nt!MiDecrementReferenceCount). Nachdem keine Referenzen mehr drauf sind, wird hierbei die Seite entweder in die StandbyPageList (Seite kann wiederverwertet werden) eingeschlangt, oder, wenn diese schmutzig (modifiziert) ist, in die ModifiedPageList.
Hier beginnt nun unser Drama: Die Seite landet in der ModifiedPageList. Dies veranlasst den LazyWriter des Cache Managers dazu, die Seite langsam im Hintergrund wieder auf die Disk zurückzuflushen!
Man kann sich das auch wunderbar im Sysinternals Process Monitor ansehen: Das System beginnt doch tatsächlich, die gelesene Datei gemütlich wieder auf die GPT Disk zurückzuschreiben, was natürlich völlig unnötig und idiotisch ist. Nicht nur, dass hier unnötige Arbeit gemacht wird, solange die Seiten nicht geflusht sind, wird der RAM natürlich okkupiert und nachdem der Lazywriter nicht sehr schnell ist und das im Hintergrund erledigt, dauert das seine Zeit, bis der RAM wieder zurückkommt.
Damit nicht genug wird hiermit auch der Schutz des Cache Manager ausgehebelt, der eigentlich ein Write throtteling bei Schreibvorgängen macht, damit der RAM eben nicht übervoll wird, denn hier werden die Leseseiten als zu cachende Schreibseiten verwendet und da gibts natürlich kein Write Throtteling.
Das ist also der Grund für dieses komische Phänomen. Allerdings weiß ich selber nicht, wie das bei normalen Disktreibern ist, die müssten meiner Meinung nach ja auch die Speicherseite modifizieren, wenn Sie die zu lesenden Daten in den Puffer transferieren. Aber offensichtlich führt die Art, wie der darunterliegende Treiber für ATA-Passthrough das Ganze handhabt dazu, dass die Cacheseiten als Dirty markiert werden.
Viell. könnte sich das mal wer bei Paragon ansehen? Die haben da sicher mehr Ahnung davon als ich... Die Hoffnung stirbt zuletzt :)

Lg.

Hallo, ATLAN und leecher,

vielen Dank für Eure Mühe und Eure Beschäftigung mit dem Treiber.

Aber ich will mal ganz offen sein: Leider hat leecher mit seiner Vermutung recht. Unsere Entwicklung stellt für Änderungen/Eingriffe/Korrekturen am GPT Loader keine Ressourcen mehr bereit. Dies liegt natürlich an dem Status, den XP inzwischen hat. Als damals die ersten 3-TB-Platten herauskamen, gab es noch ziemlich viele XP-Nutzer, und auch die wollten diese Platten nutzen. Da Platten größer als 2,2 TB nur mit GPT betrieben werden können, was XP nicht kann, haben wir den GPT Loader geschrieben, der XP GPT beigebracht hat. Damit waren alle erstmal zufrieden.

Der Treiber hatte natürlich Bugs - welche Software hat das nicht. Einige wurden korrigiert, andere nicht. Den Bug, den leecher auf seiner Seite beschrieben und gepatcht hat, habe ich schon vor ziemlich langer Zeit an unsere QA weitergeleitet. Das wurde zur Kenntnis genommen. Aber - wie gesagt - die Prioritäten liegen anderswo.

Neue Technologien gehen halt über alte Betriebssysteme hinweg. Da hilft dann irgendwann auch Flickwerk wie der GPT Loader nicht mehr.

Tut mir wirklich leid, Euren Enthusiasmus so frustrieren zu müssen.

Hallo,

Ich weiß jetzt glaub ich, was es ist und wie man es beheben könnte. Ich schreib dann am Wochenende mal einen Patch (leider ist das halt schwer zu testen und gerade wenn man in so eine wichtige Routine wie die Lese/Schreiberoutine eingreift muss man natürlich besonders vorsichtig sein).
Wenns der Hersteller nicht macht, muss es der Benuzter halt selber machen ;)
Stay tuned... :)

Gar nicht mitbekommen, daß es hier antworten gab. Hatte tatsächlich momentan nur noch mal den blog (hardwarefetish.com) aufgerufen.

Ja, einige Annahmen oben waren nicht ganz richtig, wie ich bei einigen Test nun herausgefunden habe. Die Dateien wurden scheinbar am Ende schon geschrieben aber es braucht bis zu 6min, bevor der Speicher wieder freigegeben wird. Dadurch wirkt es, als ob noch Daten weiter geschrieben werden müßten, da man während dieser Zeit kaum etwas machen kann, kann ich mir aber auch nicht sicher sein, ob wirklich schon alle Dateien nicht nur angelegt sondern auch inhaltlich komplett sind. Was da im Hintergrund abläuft schein Leecher besser zu verstehen. Im Explorer tauchen alle Dateien nach erfolgtem Kopierdialog jedenfalls wohl auf. Aber die Speicherfreigabe läßt lang auf sich warten.

Es ist auch so, daß der Schreibprozeß auf die 3TB Platte kein Problem birgt. Auch nicht über den 2TB Bereich hinaus. Dieser Fehler mit dem Speicherüberlauf findet nur statt, wenn Dateien von der 3TB Platte woanders hin kopiert werden. Und auch nur, wenn die zu kopierenden Dateien im Bereich von über 2TB bis 3TB oder größer gespeichert sind und somit von dort ausgelesen werden müssen. Als muß er diese erst neu Adressieren und im RAM zwischen lagern?
In den Bereich über 2TB neue Dateien zu speichern, ist also kein Problem und wird korrekt ausgeführt, ohne das System zu behindern. Nur das wieder weg kopieren ist problematisch.

Also die Dateien wieder aus diesem Bereich auszulesen halt. Beim Aufruf von einzelnen Dateien fällt dies auch nicht auf, daß diese offensichtlich in den RAM geladen werden. Selbst 2GB Filme werden bei entsprechend schnellem RAM zügig geöffnet. Wenn man aber auf einen Schlag viele dieser Dateien aus diesem Bereich aufruft, wie es beim Kopieren halt geschieht und alle zusammen gerechnet über der Größe des Verfügbaren Speichers liegen, dann kommt es zu diesem ärgerlichen Effekt. Mit jeder Datei wird entsprechend ihrer Größe der verfügbare RAM aufgebraucht, bis nur noch die 4MB Reserve für den WinXP Kernel bleibt und dann ist natürlich alles schlagartig langsam und das System hängt. Läßt man es arbeiten, wird alles ordentlich kopiert aber es braucht Zeit und ein Laie ist schnell versucht, den Resetknopf zu drücken.

Hab mal den genauen Effekt in einem Word-Dokument mit Bildern zusammengefaßt und die Probleme bzw. Effekte und den Ablauf dokumentiert.
Wenn es interessiert, kann sich das Dokument hier ansehen.
http://www.file-upload.net/download-...oblem.doc.html


@Leecher
Falls Du ein Testsystem benötigst, kann ich dies wohl veranlassen, wie ich schon im anderen Blog schrieb. Würde mich freuen, wenn Du da etwas genaueres herausfindest. Schreib mich einfach hier an.

Letztlich ist es natürlich toll, was Paragon hier geleistet hat und sich damals des Problems überhaupt angenommen hat und das sogar erfolgreich. Doch schade ist es auch, wenn dann Patches tatsächlich nicht mehr einfließen, wenn diese schon von anderen gut analysiert wurden.

Aber dies scheint wirklich ein Problem zu sein, daß leider sich erst sehr spät zeigt.

Nachdem ich nun Leechers Ausführungen nochmals gelesen habe, irritiert mich dies ein wenig. Soll das bedeuten, daß Dateien, welche man von der 3TB GPT Platte auf eine andere Festplatte kopiert, letztlich 2 mal geschrieben werden?
Also einmal auf die Zielfestplatte und ein weiteres mal wieder zurück in die Originaldateien auf der 3TB GPT Platte? Der 2te Schreibvorgang wäre dann ja eigentlich ein Überschreiben der zu kopierenden Originaldateien. Das macht nicht wirklich Sinn.

Hallo liebe Leidensgenossen,

Ich habe nach eingehender Analyse nun auch für dieses Problem einen Patch geschrieben. In meinen Tests hat er funktioniert, trotzdem garantier ich natürlich für nichts.
Zu finden in meinem Blog unter:
http://hardwarefetish.com/612-gpt_lo...e-read-problem

Dort habe ich nun auch genau dokumentiert was zu dem Fehler führt. Es war bestimmt keine Absicht von Paragon sondern das Ganze ist ein Seiteneffekt der Funktionsweise des NT-Cachemanagers, an den ich wahrscheinlich auch nicht gedacht hätte, hätte ich den Treiber geschrieben. :)

Quote:

---

Originally Posted by ATLAN

Nachdem ich nun Leechers Ausführungen nochmals gelesen habe, irritiert mich dies ein wenig. Soll das bedeuten, daß Dateien, welche man von der 3TB GPT Platte auf eine andere Festplatte kopiert, letztlich 2 mal geschrieben werden?
Also einmal auf die Zielfestplatte und ein weiteres mal wieder zurück in die Originaldateien auf der 3TB GPT Platte? Der 2te Schreibvorgang wäre dann ja eigentlich ein Überschreiben der zu kopierenden Originaldateien. Das macht nicht wirklich Sinn.

---

Ja, das hast Du richtig verstanden! Ist natürlich unbeabsichtigt.
Um es kurz zusammenzufassen: IOCTL_ATA_PASS_THROUGH_DIRECT verlangt einen pointer auf eine virtuelle Adresse, wo es die Daten hinliefern soll, keine MDL, macht aus diesem Zeiger dann wieder intern eine MDL und das bewirkt dann, dass die Speicherseite dort als Schmutzig markiert wird, was dann wiederum den NT Cache Manager dazu veranlasst, die Seiten mit dem Lazywrite zurückzuflushen. Nachdem dieser IOCTL sinnvollerweise nur für Zugriffe über der 2TB Grenze aufgerufen wird, tritt der Effekt folglich auch nur für Daten auf, die hinter dieser Grenze liegen.
Bei normalen Disktreibern wird die MDL durchgehend verwendet und dadurch ist es egal, dass die Speicherseite beschrieben wird, weil hier eben dem Kernel bekannt ist, dass das keine Cacheseite ist, die zurückgeschrieben werden muss (sprich das Modified-Flag wird da dann quasi ignoriert).
Nähere Erkärungen sind im Blog.

Lg. und noch ein schönes Wochenende.