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?
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.
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.
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.
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.
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.
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).
@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.
