Hallo Leute, Habe in der SUFU folgendes gefunden: http://www.eterlogic.com/help/vdsdk/CSharpPage.html Okay nun zu meiner Fragestellung: Das erste Ziel ist ein eigenes RAMDisk-Programm zu entwerfen und eine Grundlage zu schaffen damit ich für zukünftige Projekte drauf aufbauen kann. Was mir wichtig dabei ist, dass jeder Schritt nachvollziehbar bleibt und nicht 1:1 abgekupfert werden soll, weil viele Wege führen nach Rom :) Es soll auch zunkünftigen Leuten helfen auf eine Grundbasis aufbauen zu können. Also die Grundfunktionen wie schreibe/lade ich etwas in den RAM und lese es per Dateipfad aus und lösche/überschreibe es bei bedarf per Hand/Befehl. Ich verwende ein WIN 7 64bit System und verwende C#
Patrick schrieb: > Das erste Ziel ist ein eigenes RAMDisk-Programm zu entwerfen und eine > Grundlage zu schaffen damit ich für zukünftige Projekte drauf aufbauen > kann. Und das soll unter Windows laufen? Hat das dann auch noch einen anderen Zweck als als Lehrstück für Dich zu dienen?
Patrick schrieb: > Okay nun zu meiner Fragestellung: Äh, und? Viel (belangloses) Geschreibsel, aber kein Fragezeichen. Was also ist die Frage? Oliver
:
Bearbeitet durch User
Rufus Τ. F. schrieb: >> Patrick schrieb: >>> Das erste Ziel ist ein eigenes RAMDisk-Programm zu entwerfen und eine >>> Grundlage zu schaffen damit ich für zukünftige Projekte drauf aufbauen >>> kann. >> >> Und das soll unter Windows laufen? >> >> Hat das dann auch noch einen anderen Zweck als als Lehrstück für Dich zu >> dienen? Ja genau, primär erst mal unter Windows, ich würde natürlich das Grundkonzept mit Funktionen erweitern versuchen, je nachdem wie viel Aufwand jeweilige Features haben, gestaltet sich das Ziel. Überladen darf es am Ende natürlich nicht sein. Sollte eine Basis bilden worauf man aufbauen kann. Oliver S. schrieb: >> Patrick schrieb: >>> Okay nun zu meiner Fragestellung: >> >> Äh, und? >> >> Viel (belangloses) Geschreibsel, aber kein Fragezeichen. >> >> Was also ist die Frage? >> >> Oliver Hmm Stimmt das Fragezeichen habe ich wohl vergessen, danke für den Hinweis ;) Zur Frage: Die Grundfunktionen, wie schreibe/lade ich etwas in den RAM und lese es per Dateipfad aus und lösche/überschreibe es bei bedarf per Hand/Befehl? Anmerkung: Ich verwende ein WIN 7 64bit System und verwende C#
In PC-Intern war mal ne RAMDISK beschrieben. Ich hab das modifiziert, damit man zur Laufzeit die Größe ändern kann. Der residente Teil war ~400Byte groß und wurde in der Config.sys installiert.
Patrick schrieb: > Zur Frage: > Die Grundfunktionen, wie schreibe/lade ich etwas in den RAM und lese > es per Dateipfad aus und lösche/überschreibe es bei bedarf per > Hand/Befehl? Verstehe ich nicht. Wenn dieses Programm läuft und du die RamDisk erzeugt hast (und alles klappt), dann gibt es in deinem Windows ein Laufwerk mit dem Kennbuchstaben 'Z'. Jedes andere Programm kann das dann wie ein ganz normales Laufwerk benutzen, so wie jedes andere Laufwerk auch. D.h. du verwendest in anderen Programmen die ganz normalen Datei-Behandlungsfunktionen. Nur dass du deine Dateien also zum Beispiel nicht auf "C:\\test.txt" speicherst, sondern eben auf "Z:\\test.txt". Das ist ja der Sinn einer RamDisk, dass sie sich wie ein ganz normales Laufwerk präsentiert und niemand wissen muss oder soll, dass sich da gar keine Festplatte dahinter verbirgt. Um den ganzen Rest wie Dateiverwaltung, Blockzuteilung etc. kümmert sich schon Windows. > Was mir wichtig dabei ist, dass jeder Schritt nachvollziehbar bleibt und nicht 1:1 abgekupfert werden soll, weil viele Wege führen nach Rom Da brauchst du nicht viel abkupfern, denn den schwierigen Teil, nämlich die Einbindung ins Windows bzw. ins Filesystem hat dir eh schon jemand abgenommen. Du benutzt nur noch deren Manager um diesem Teil zu sagen: Ich will ein Laufwerk erzeugen, dieses Laufwerk soll den Kannbuchstaben 'X' haben und es soll so gross sein. Und ach ja, wenn du einen Block lesen oder schreiben willst, dann gib Bescheid. Um den Rest kümmert sich dann der Unterbau auf dem du aufsetzt.
:
Bearbeitet durch User
Allerdings ist heutzutage der Sinn einer RamDisk mehr als zweifelhaft. Denn entweder hast du den RAM frei, dann ballert Windows diesen RAM sowieso mit Cache-Speicher voll oder du hast den RAM voll, dann bringt dir aber auch eine RAM Disk keinen Geschwindigkeitszuwachs mehr, eben weil ja der RAM schon voll ist. Du magst dann zwar Dateien in der RAM Disk vorliegen haben, aber dafür müssen andere Systembestandteile anstatt auf das RAM auf die Festplatte ausgelagert werden. RAM Disks hatten ihre Berechtigung, solange Speicher ungenutzt brach lag. Aber das ist bei heutigen Windows Systemen nicht mehr so. Brachliegender Speicher wird von Windows sofort zum Cachen von Festplattenzugriffen eingesetzt.
:
Bearbeitet durch User
Eine RAM-Disk kann in Einzelfällen Sinn ergeben. Etwa wenn man Altsoftware damit beschleunigen kann, die unangenehm intensiv auf der Disk rumrattert und das in für eine SSD unpraktischer Weise. Aber für neue Programme gibt es genug bessere Wege, auch grosse Daten im RAM zu parken. Man kann RAM-Disks auch als Basis für Systeme verwenden, die von sowas wie einem USB-Stick oder einer SD-Karte gestartet werden. Das Systemlaufwerk von Windows direkt darauf zu platzieren macht selbst dann keinen Spass, wenn man es schafft. Das wäre jedenfalls das Pendant zur Arbeitsweise mancher Systeme auf Linux-Basis. Da ist eine RAM-Disk als Systemdisk nicht selten.
A. K. schrieb: > Eine RAM-Disk kann in Einzelfällen Sinn ergeben. Etwa wenn man > Altsoftware damit beschleunigen kann, die unangenehm intensiv auf der > Disk rumrattert dachte ich auch mal. Hab mich aber dann belehren lassen, dass an dieser Stelle sofort die Windows verwalteten Platten Caches den Löwenanteil abfangen.
Karl H. schrieb: > Hab mich aber dann belehren lassen, dass an dieser Stelle sofort die > Windows verwalteten Platten Caches den Löwenanteil abfangen. Das findet Grenzen, wenn in hohem Umfang Metadaten-Operationen anfallen. Wenn es also um extrem viele kleine Files geht, die massenhaft auftauchen und verschwinden. Oder wenn der Programmierer es geschafft hat, das Programm so zu dressieren, dass der Windows Cache die Flinte ins Korn wirft und allenfalls der Cache der HDD die Situation rettet. Dieses Problem hatte ich mal auf dem Tisch. Wie er das geschafft hat weiss ich nicht. Ich hatte versucht, es mit eigener Programmierung nachzustellen, bin diesem Meister aber nicht auf die Schliche gekommen. In XP wars ok, in Win7 hing die Startzeit eines Programms in extremer Weise vom HDD Hersteller ab. In den Traces von Win-API und Diskzugriff war in Win7 im Gegensatz zu XP keinerlei Caching zu sehen und alles hing davon ab, ob der Cache in der HDD die Daten nach Verwendung noch aufbewahrt oder gleich verwirft. Was die Hersteller unterschiedlich handhaben. Im inakzeptablen Fall war jedesmal eine Umdrehung der HDD dazwischen. Letztlich wurden die Rechner der Anwender so rochiert, dass die Anwender dieser Software den richtigen Typ drin hatten. Mit dieser Software hätte man auf Dauer wahrscheinlich SSDs gekillt.
:
Bearbeitet durch User
A. K. schrieb: > Karl H. schrieb: >> Hab mich aber dann belehren lassen, dass an dieser Stelle sofort die >> Windows verwalteten Platten Caches den Löwenanteil abfangen. > > Das findet Grenzen, wenn in hohem Umfang Metadaten-Operationen anfallen. > Wenn es also um extrem viele kleine Files geht, die massenhaft > auftauchen und verschwinden. > > Oder wenn der Programmierer es geschafft hat, das Programm so zu > dressieren, dass der Windows Cache die Flinte ins Korn wirft und > allenfalls der Cache der HDD die Situation rettet. Sieht man das eigentlich im Task-Manager von Win 8.1? Der hat ja so nen netten Chart, der irgendwas mit I/O anzeigt. Sind das die I/O-Operationen, die von der Software angefordert werden, oder die tatsächlichen Plattenzugriffe? Ich denke da nämlich grad dran, dass ich mehr als gelegentlich die Test-Suite von Git durchlaufen lasse. Da werden Tausende Dateien erzeugt und wieder gelöscht. Das könnte mir die SSD ruinieren...
tictactoe schrieb: > Sieht man das eigentlich im Task-Manager von Win 8.1? Der hat ja so nen > netten Chart, der irgendwas mit I/O anzeigt. Für die Analyse verwendet ich zwei Tools, die die Operationen des Windows File-APIs und die Disk-Operationen tracen. Nagel mich nicht drauf fest, aber es waren wohl FileMon und DiskMon von den PsTools. Letztlich hatte die Software zigtausend kleine Datensplitter aus vielen Files eingesammelt und in einem Datenbankfile konzentriert. Nur leider nicht im Speicher, sondern in zigtausend Schreibzugriffen von einigen Bytes Grösse auf ein einziges File. In XP fing das der Windows Cache komplett ab, es blieben nur die Disk-Schreibzugriffe auf komplette Fileblöcke übrig. In Win7 tauchte jeder solche File-API Schreibzugriff als ein Read und ein Write eines Disk-Blocks auf. Der immer gleiche Block zigmal hintereinander, so lange bis er voll war. Die "gute" HDD war dabei wesentlich schneller als eine Crucial m4 SSD.
:
Bearbeitet durch User
Peter D. schrieb: > In PC-Intern war mal ne RAMDISK beschrieben. Ich hab das modifiziert, > damit man zur Laufzeit die Größe ändern kann. Der residente Teil war > ~400Byte groß und wurde in der Config.sys installiert. hast du das schön Dokomentiert? Wie gesagt ich suche ein Grundmodell worauf man Aufbauen kann. @ Karl Heinz (kbuchegg) (Moderator) speziell momentan wenn SSD's noch einen Problematischen Wear Level besitzen, ich persönlich verwende Normale Festplatten und profitiere von RamDisk stark, ich möchte aber das Feature in eine Applikation integrieren die sich selbst verwaltet, jedoch schlank genug ist und wirklich nur die nötigsten Features an den Tag legt. Dem Enduser einfach ein Erlebnis presentieren dass er staunen kann, weil es einen unterschied macht 9 Sekunden zu warten oder über eine Minute, sofern er genug Arbeitsspeicher besitzt ;) Speziell zum Programmieren ist es fein eine RamDisk zu haben, läuft einfach flott, überhaubt wenn es zum Datenbanken verwalten kommt. Am Ende das Spiegeln nicht vergessen ;)
Ich habe im Zusammenhang mit dem Übersetzern von "großen" Programmen (mit vielen Dateien) schon gelesen das eine RAM Disk einen Vorteil bei der Compilezeit bringen kann. Hat da jemand Erfahrungen?
tictactoe schrieb: > Sieht man das eigentlich im Task-Manager von Win 8.1? Im PerfMon, heute wohl über den Task Manager erreichbar, kann man sich die Statistik der physikalischen Disk-Writes und deren mittlere Grösse anzeigen lassen. Das wär schon ein Anfang.
Patrick schrieb: > speziell momentan wenn SSD's noch einen Problematischen Wear Level > besitzen, wo hast du das gelesen, ich verwende sie seit 3 Jahren (mehr als 10 stück ein Einsatz (24/7) und noch keinen Ausfall. Würde mir nichts anderes mehr kaufen. > ich persönlich verwende Normale Festplatten und profitiere von > RamDisk stark dann liegt das aber an dir. > ich möchte aber das Feature in eine Applikation > integrieren die sich selbst verwaltet, jedoch schlank genug ist und > wirklich nur die nötigsten Features an den Tag legt. damit schafft du dir nur neue Probleme. - mehre Anwendungen parallel, - Multiuser-System (Windows-Terminal-Server), - berechtigungs Probleme, - Anpassung an das nächste Windows usw. > Dem Enduser einfach > ein Erlebnis presentieren dass er staunen kann, weil es einen > unterschied macht 9 Sekunden zu warten oder über eine Minute, sofern er > genug Arbeitsspeicher besitzt ;) wozu braucht man dafür eine Ramdisk? Reicht nicht einfach normal den Speicher zu nutzen, warum muss darin ein Filesystem stecken? Man kann auch alle Dateien die man braucht in eine Datei legen und die beim Start einfach in dem Ram laden.
Karl H. schrieb: > Allerdings ist heutzutage der Sinn einer RamDisk mehr als zweifelhaft. Anscheinend nicht: http://www.pcwelt.de/ratgeber/Windows_doppelt_so_schnell_-_so_geht_s-Exklusives_PC-WELT-Tool-8342553.html Aber kann sich noch wer an die Win-NT Installation erinnern? Da beschleunigte eine Ramdisk die Installation gewaltig und das "CD-zersaegen" war auch fast weg... ;)
W. M. schrieb: > Anscheinend nicht: > http://www.pcwelt.de/ratgeber/Windows_doppelt_so_schnell_-_so_geht_s-Exklusives_PC-WELT-Tool-8342553.html > Ein Windows in der Ramdisk ist für alle Aufgaben geeignet, bei denen es > auf hohes Tempo ankommt. Es lässt sich ohne Risiko neben einem > vorhandenen Windows einrichten und ist vor Veränderungen geschützt. ein Read-only Windows mag ja für einige Anwendungen OK sein, aber zu 99% ist das einfach unpraktisch. Nach jedem Update oder einer Programminstallation muss man wieder die Ramdisk erzeugen. Dann doch lieber eine SSD. So ein System bootet in 10-15 Sekunden. Das ist (mir) schnell genug.
Patrick schrieb: > ich möchte aber das Feature in eine Applikation integrieren die sich > selbst verwaltet, Dann nimm keine Dateien und eine Ramdisk, sondern eine im Speicher liegende Datenbank. Sehr schick, performant und gut handhabbar ist hier SQLite.
Falls es weniger um das Warum als das Wie geht, würde ich z.B. mal hier reinschauen: https://support.microsoft.com/en-us/kb/257405 Um eine RAMdisk zu programmieren, muss ein Gerätetreiber geschrieben werden, welcher ein Blockdevice erzeugt. Das ist für den Einstieg nicht die leichteste Übung, dafür aber mit unheimlich steiler Lernkurve. Ich kann mir aber auch nicht vorstellen, warum ich für "zukünftige Projekte" eine RAMdisk benötigen sollte. Du hast da jedenfalls keine Marktlücke entdeckt. Pro Tipp: Man kann auch einfach Speicher im RAM allokieren, wenn es mal eng wird.
Patrick schrieb: > Speziell zum Programmieren ist es fein eine RamDisk zu haben Dann benutz doch einfach eine - es besteht nicht der geringste Grund, das selber zu programmieren. Richte dir eine Ramdisk ein, meinetwegen als Laufwerk R, und verwende sie wie andere Platten auch. Georg
Patrick schrieb: > hast du das schön Dokomentiert? Das war alles genau in dem Buch "PC-Intern" beschrieben. Aber es nutzte das DOS-API und war 16Bit. Bis W98 lief es wohl noch, wurde dann aber nicht mehr als RAM-Disk erkannt, sondern als Wechseldatenträger. Was hast Du gegen ein fertiges RAMDisk-Programm?
> Was hast Du gegen ein fertiges RAMDisk-Programm? Vor allen Dingen: Was hast du gegen den Virtual Drive SDK, den Eterlogic verkauft? Du glaubst doch hoffentlich nicht im Ernst, dass du so etwas einfach so aus dem Ärmel schüttelst, nur weil die Demo recht kurz ist? Die ganze Magie in dieser Demo steckt in den von dieser Firma zur Verfügung gestellten Basisklassen. Die Demo zeigt nur, wie man die benutzt. Das ist nun mal Wissen, dass sie sich bezahlen lassen. Das finde ich auch legitim, denn da ist mindestens einer eine ganze Zeit lang gesessen und hat sich das Wissen angeeignet um so etwas machen zu können. Der lebt auch nicht von Luft und Liebe. http://www.eterlogic.com/Products.VirtualDriveSDK.html (Schön langsam nimmt dieses 'Ich kanns zwar nicht, will aber - hat da wer mal Code für mich?" erschreckende Ausmasse an).
:
Bearbeitet durch User
@Peter Dannegger (peda) Danke für die Info ;) Wie Eddy Current (chrisi) kurz und pregnant es formuliert hat: Eddy C. schrieb: > Falls es weniger um das Warum als das Wie geht, würde ich z.B. mal hier > reinschauen: > > https://support.microsoft.com/en-us/kb/257405 > > Um eine RAMdisk zu programmieren, muss ein Gerätetreiber geschrieben > werden, welcher ein Blockdevice erzeugt. Das ist für den Einstieg nicht > die leichteste Übung, dafür aber mit unheimlich steiler Lernkurve. > > Ich kann mir aber auch nicht vorstellen, warum ich für "zukünftige > Projekte" eine RAMdisk benötigen sollte. Du hast da jedenfalls keine > Marktlücke entdeckt. > > Pro Tipp: Man kann auch einfach Speicher im RAM allokieren, wenn es mal > eng wird. Danke für den Hineweis und deines "Pro Tipp's, wie würde man das realsieren, mit welchen Einschränkungen müsste ich dabei rechnen? Karl H. schrieb: >> Was hast Du gegen ein fertiges RAMDisk-Programm? > > Vor allen Dingen: Was hast du gegen den Virtual Drive SDK, den Eterlogic > verkauft? > Du glaubst doch hoffentlich nicht im Ernst, dass du so etwas einfach so > aus dem Ärmel schüttelst, nur weil die Demo recht kurz ist? > Die ganze Magie in dieser Demo steckt in den von dieser Firma zur > Verfügung gestellten Basisklassen. Die Demo zeigt nur, wie man die > benutzt. Das ist nun mal Wissen, dass sie sich bezahlen lassen. Das > finde ich auch legitim, denn da ist mindestens einer eine ganze Zeit > lang gesessen und hat sich das Wissen angeeignet um so etwas machen zu > können. Der lebt auch nicht von Luft und Liebe. > > http://www.eterlogic.com/Products.VirtualDriveSDK.html > > (Schön langsam nimmt dieses 'Ich kanns zwar nicht, will aber - hat da > wer mal Code für mich?" erschreckende Ausmasse an). Ich persönlich habe nichts gegen ein RAMDisk Programm, ich verwende auch ein RAMDisk Programm. Inwiefern nimmt das erschreckende Ausmaße an? Ich werde es kaum aus meinen Fingern saugen können ohne eine Grundlage zu besitzen, irgendwo muss man ja anfangen.
Patrick schrieb: > Danke für den Hineweis und deines "Pro Tipp's, wie würde man das > realsieren, mit welchen Einschränkungen müsste ich dabei rechnen? Zu allererst solltest Du ungefähr eingrenzen, wozu Du konkret eine RAMdisk einsetzen willst, und was das mit "zukünftigen Projekten" zu tun hat. Wenn es darum geht, prozessübergreifend Daten auszutauschen, kannst Du stattdessen beispielsweise sog. named Pipes benutzen. Innerhalb eines Prozess reicht eine einfach Speicherallokierung per "new", aber das sollte Dir eigentlich bereits klar sein. Jedenfalls macht es keinen Sinn (ausser als Übungsprojekt), die Lösung zu programmieren, bevor man das Problem kennt.
Eddy C. schrieb: > Wenn es darum geht, prozessübergreifend Daten auszutauschen, kannst Du > stattdessen beispielsweise sog. named Pipes benutzen. Da kann man auch shared memory verwenden (wenn man anderweitig für Zugriffsynchronisation sorgt). Named pipes hingegen haben den Vorzug, auch im Netzwerk, d.h. zwischen unterschiedlichen Rechnern genutzt werden zu können, was aber bei der Fragestellung "Ramdisk" offensichtlich nicht das Thema ist ...
Eddy C. schrieb: > Wenn es darum geht, prozessübergreifend Daten auszutauschen, kannst Du > stattdessen beispielsweise sog. named Pipes benutzen. Unter Windoof ist TCP/IP mehrere Größenordnungen schneller, auch wenn Sender und Empfänger auf derselben Maschine sind. Deswegen nimmt man dort Named oder Unnamed Pipes eher ungern. Rufus Τ. F. schrieb: > Da kann man auch shared memory verwenden Da muss man sich aber eine Synchronisation ausdenken, was mit 2 Prozessen nicht mehr trivial ist. Man will Deadlocks und Starvation vermeiden.
Jim M. schrieb: > Da muss man sich aber eine Synchronisation Wenn Du mich vollständig zitiert hättest ... Wobei so irrwitzig kompliziert das unter Windows auch nicht ist; es gibt in der Win32-API prozessübergreifende Synchronisationsobjekte, die schon seit über 20 Jahren ihren Dienst verrichten, u.a. Mutex und Semaphore.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.