Diskussion:RAM-Disk/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:RAM-Disk/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:RAM-Disk/Archiv/1#Thema_1

Ram-Disk in Druckern?

Gibt es nicht auch RAM-Disks in Druckern? Und nicht nur in PC's?

Drucker haben i.d.R festes RAM. In der Liste habe ich noch Knoppix hinzugefügt. Es kann 16 bis mindestens 128 MB verwalten. --Saemikneu 21:47, 8. Dez. 2006 (CET)

@Trublu

Versteh's doch bitte, eine Enzyklopädie ist kein geeigneter Ort zu versuchen, anderen Deine verqueren Vorstellungen, was als Disk und was als Drive zu bezeichnen ist, aufzuzwingen. Nicht dass es eine Rolle spielen würde, denn Deine Aussagen sind (a) nicht hinreichend belegt und (b) irrelevant, da Menschen die Bezeichnungen verwenden, die sich eingebürgert haben, unabhängig davon ob sie einer zweifelhaften "inneren Logik" folgen, aber ich kann einfach nicht widerstehen, auf Deine abenteuerliche These einzugehen: Eine "Disk" ist (in der ursprünglichen Bedeutung) ein Scheibe, so weit sind wir uns glaube ich noch einig, und ein "Drive" ist ein Mechanismus, der diese Scheibe dreht (vgl. Compact Disc vs. CD drive). SSDs und RAM-Disks enthalten sicher keine Scheiben, aber sie enthalten erst recht keinen Mechanismus, der diese nicht vorhandenen Scheiben rotiert. Von daher ist es völliger Blödsinn, zu postulieren, dass die Bezeichnung "Disk" "ungenau" ist, und die Bezeichnung "Drive" so viel toller ist. Können wir dieses leidige Thema damit beenden?

Das ist nicht meine Privatmeinung, sondern die Verwebdung aus dem englischen. Zudem sind beide Begriffe gebräuchlich und es ist auch angegeben, welcher gebräuchlicher ist. "Ungenau" kommt dem auch entgegen, da ich deine Argumente gegen "falsch" verstehe. Aber gerade weil beide Begriffe gebräuchlich sind, sollte diese Unterscheidung beschrieben werden. Zum CD-Vergleich: Drive bedeutet insbesondere ansteuern (vgl Driver bzw. Treiber für sämtliche HW) und das wird auch bei SSD getan, es wird angesteuert. Gerade im USB-Bereich ist dabei jedoch die Grenze verwaschen, so dass "Drive" und "Disk" nun im selben Gehäuse sitzen. Aber durch den wegfall der Mechanik ist nur letzterer ungenau geworden. Trublu ?! 10:21, 22. Jun. 2008 (CEST)

Trotzdem ist es reichlich egal, ob man es nun RAM-Disk oder RAM-Drive (was sich irgendwie komisch anhört) nennt. Solche Haarspalterei nützt wirklich niemandem etwas und nervt einfach nur.--techpriester 20:54, 7. Jul. 2008 (CEST)

Gerade deswegen sollte man nicht kraenklich auf RAM-Disk beharren. 77.176.32.187 09:08, 30. Jul. 2008 (CEST)

In der Praxis nennen jedenfalls alle mir bekannten Programmierer/Anbieter/Hersteller sowas "RAM-Disk" - und zwar im Englischen genauso wie im Deutschen, weil das angesprochen wurde, das ist doch was, an dem man sich festhalten sollte. Wer soll denn bitte angeblich RAM-Drive sagen? --PeterFrankfurt 02:32, 2. Aug. 2008 (CEST)

Sehr seltsame Diskussion. Wo es doch eigentlich darum gehen sollte, daß der Hauptartikel samt und sonders falsch ist.

(Da jeder nur ein begrenztes Wissen / Wissensbereich / hat, kann man immer nur Teile beurteilen.

Aber ich gehe mal davon aus, daß mindestens 80% dessen, was in Wikipedia steht, ganz oder zumindest Größtenteils falsch ist - leider)

Z.B.:

=>> ist ein virtueller und temporärer Datenträger im Arbeitsspeicher eines Computers

-> virtuell

   Dieses Drive (was nichts mit Drive zu tun hat, aber über einen Laufwerksbuchstaben angesprochen wird wie ein "Laufwerk") ist nicht virtuell.
   Ob diese Speichereinheit auf magnetisierbaren Scheiben beruht, ob Daten optisch gespeichert werden oder in einem Halbleiterspeicher
   - es ist eine reale Hardware, in der gespeichert wird.

-> temporär

   Eine CD hat nur eine begrenzte Lebensdauer (Lichtschäden, chemische Veränderungen)
   Auch eine Harddisk geht irgendwann einmal kaputt.
   Alles ist daher temporär.
   Wenn eine RAM-Disk entsprechend konstruiert ist, gehen dort auch keine Daten verloren, wenn z.B. der Strom ausfällt

-> im Arbeitsspeicher des Computers

   Es gibt längst (seit zig Jahren) Hardware, welche in einem eigenen Gehäuse ist als eigenständiges "Laufwerk" angeschlossen und angesprochen wird
   und nicht im Arbeitsspeicher des Computers ist.
   Batteriepufferung und Backup auf eine Harddisk oder in einen Flash-Speicher, falls die Backup-Batterie leer wird.

In dem Hauptartikel ist praktisch alles falsch.

==>> Eine RAM-Disk verhindert Datenverlust durch versehentliches Überschreiben

-> Da wird es vollends lächerlich.

Ich denke du verwechselst da was. RAM-Disks sind tatsächlich virtuell und temporär, weil sie im flüchtigen Arbeitsspeicher existieren und nicht als tatsächliche Hardware. Möglicherweise meinst du ein Solid State Drive. Trublu ?! 09:20, 28. Aug. 2008 (CEST)

Ramdrive

Nach der englischen Wikipedia http://en.wikipedia.org/wiki/Solid-state_drive bezieht sich Ramdrive auf eine SSD mit S/DRAM

(bitte unterschreiben) Nicht alles glauben, was auf en: steht. --PeterFrankfurt 23:41, 22. Feb. 2009 (CET)

Preis

Den Satz „(was sich in Anbetracht der gesunkenen Speicherpreise jedoch relativiert haben dürfte)“ habe ich mal entfernt. Er erscheint mir nur logisch, wenn RAM immer billiger wird, aber Festplatten gleich teuer bleiben (meine natürlich jeweils spezifische Preise). Habe keine Ahnung, aber nach meiner Erfahrung wird beides immer billiger. Daher bitte Quellen. -- Pemu 21:35, 24. Jan. 2012 (CET)

RAD auf Amiga ({{Überarbeiten}})

Ich kann nur für AmigaOS bis 3.1 sprechen, aber dann würde ich hohe Beträge wetten, dass die resetfeste Ramdisk namens RAD: eine konstante Größe hat (festzulegen sogar nur als Anzahl virtueller Diskettenspuren, aber darum würde ich schon nicht mehr wetten). Als Belege habe ich auf die Schnelle nur [1] ("In the event that the default RAD size is not to your liking") und [2] (Wort "statisch", etwas dürftig).

PeterFrankfurt, bitte gib eine Quelle für eine resetfeste Ramdisk dynamischer Größe. -- Pemu 09:14, 25. Jan. 2012 (CET)

Oha, da habe ich mich tatsächlich falsch erinnert. Tschuldigung, mea culpa. Nach einigem Wühlen habe ich mein originales AOS-3.1-DOS-Handbuch gefunden, was Deine Aussage bestätigt. --PeterFrankfurt 02:17, 26. Jan. 2012 (CET)

Das mit dem Raussuchen hatte ich mir eigentlich auch vorgenommen; kann ich nun erstmal wieder lassen! \X/ -- Pemu 18:02, 26. Jan. 2012 (CET)

CPU-Cache ersetzt RAM-Disk?

Kann man bitte jemand diesen Unsinn unter Vorteile löschen? Wenn der CPU-Cache bekanntlich schon den Arbeitsspeicher nicht ersetzen kann, wie soll er dann die RAM-Disk ersetzen können, die auch aus nichts anderem besteht?

Sicher beschleunigt der CPU-Cache Prozesse, genau wie auch große Register im Prozessor und die Sprungvorhersage etc. Aber das ändert doch absolut nichts an den Benchmarks zur RAM-Disk, SSD und HDD. Die hat man doch noch nie in irgendeiner Weise mit dem CPU-Cache relativiert! --91.1.48.114 22:45, 12. Jul. 2018 (CEST)

Da steht nichts von CPU-Cache sondern nur von Cache. Das ist stinknormale RAM, was als Platten-Lese-Zwischenspeicher genutzt wird. --Denalos(quatschen) 23:19, 12. Jul. 2018 (CEST)

mich würde jetzt mal inntresieren, wo mein computer CAche hat AUSER dem CPU cache.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 23:20, 12. Jul. 2018 (CEST)

Siehe Artikel Cache und dort den Abschnitt über Laufwerkscache. Laufwerks-Caches gab's auf PCs schon in den 80igern unter MS-DOS. Heutzutage verwenden alle modernen OS den jeweils freien Speicher für einen automatisch verwalteten Laufwerkscache. In einem modernen OS gibt's somit quasi keinen ungenutzten Arbeitsspeicher mehr. --Denalos(quatschen) 00:08, 13. Jul. 2018 (CEST)

Cache kann eine RAM-Disk in keinem Fall ersetzen. Eine RAM-Disk behält die Daten immer im RAM, die Aufgabe eines Cache hingegen ist die Zwischenlagerung von Daten. Dabei wird zwischen Lese- und Schreib-Cache unterschieden. Es geht dabei um die Beschleunigung der Zugriffe auf das Speichermedium - das nicht eine RAM-Disk ist. Die Daten SOLLEN aber relativ rasch auf dem Medium landen, nicht im RAM (Cache) verbleiben. Das wäre widersinnig. Ein Teil der Beschleunigung lässt sich dabei durch Umsortierung der Zugriffe erreichen. Die Firmware z.B. der Festplatte erkennt dabei z.B., dass Schreibvorgänge #1 #4 und #6 hinereinander schneller erfolgen, weil sie in der Nähe erfolgen, und ordnet diese entsprechend um. Dann wird Schreibvorgang #3 und #5 erledigt und zum Schluss #2. Das ganze beschleunigt also die eigentlichen Zugriffe mithilfe des Cache – eine RAM-Disk hingegen braucht dies nicht umzusortieren, da der Zugriff auf jede Adresse im RAM gleich schnell erfolgen kann. Und der RAM ist auch das Medium, wo die Daten (temporär) gespeichert sind (bis zum Stromausfall).

‣Andreas•⚖ 00:14, 14. Jul. 2018 (CEST)

Ich habe zu keinem Zeitpunkt vom Cache im Controller einer Festplatte gesprochen, auch nicht vom CPU-Cache, sondern von einem Cache, der vom OS verwaltet wird. Was meine Betrachtungen in Hinblick auf den RAM-Disk-Vergleich angeht, habe ich zur Vereinfachung auch nur den Lesecache betrachtet. Ein OS mit hinreichend RAM für einen vernünftigen Cache ist extrem effizient darin, die Dinge dauerhaft im Cache vorzuhalten, die ständig von der Platte gelesen werden. Plattenlesezugriffe werden dann vom OS auch gar nicht mehr auf die Platte durchgeleitet, sondern direkt aus dem RAM bedient. Aus genau diesem Grund steht in allen Benchmark-Programm-Anleitungen auch drin, dass der Cache entweder manuell abgeschaltet oder die Größe des Testsets zwei mal so groß wie das RAM sein muss. Wenn man das nicht beachtet, dann misst man nämlich nicht den Festplattendurchsatz, sondern die RAM-Performance (siehe dazu z.B. die Anleitung von bonnie++). Das ist keine TF, sondern überall gut dokumentierte und nachlesbare Grundlagen von OS-Design. Das Studium z.B. der Doku zu den entsprechenden Linux-Sourcen ist da sehr erhellend. --Denalos(quatschen) 01:32, 14. Jul. 2018 (CEST)

Nachtrag: Der folgende Tech-Artikel bei Microsoft File Caching gibt einen guten ersten Einblick. Logischerweise beschäftigt sich der Artikel vorwiegend mit einem Schreibcache, da der technisch (Gefahr des Datenverlusts) erheblich aufwändiger ist, als ein Lesecache. Der Artikel sollte jedoch die Zweifler davon überzeugen, dass ein OS-Cache keine TF ist. OS-Caches gibt es seit Anno-Knips mit jeweils unterschiedlichen Leistungsmerkmalen. Zu MS-DOS-Zeiten war es noch ohne Probleme möglich, eine RAM-Disk sinnvoll zu konfigurieren und zu nutzen. Heutzutage ist das eine extreme Wissenschaft. Häufig benutzte Programme, Programmteile und Module in einer RAM-Disk abzulegen, bringt einfach mal gar nichts:

1) Wenn ein Programm oder eine Programmkomponente bereits im RAM vorhanden ist (also z.B. in einer anderen Instanz läuft), dann wird das Programm nicht erneut von der Platte ins RAM geladen und gestartet, sondern es wird ein Copy On Write der im RAM vorhandenen Programmstrukturen durchgeführt. Das bedeutet, dass das neu gestartete Programm exakt das gleiche RAM nutzt, wie das bereits laufende Programm. Das OS überwacht dabei, ob eines der beiden Programme eine RAM-Schreibaktion durchführt (z.B. eine Programmglobale Variable ändert). Wenn das passiert, wird genau dieser geänderte Bereich dem Programm zugewiesen. Die beiden laufenden Programme unterscheiden sich dann in nur einigen wenigen Bytes im RAM (speichertechnisch betrachtet). All das passiert rasend schnell (weil die CPUs dafür direkten Support integriert haben) und sorgt einerseits dafür, dass weniger RAM benötigt wird und andererseits nichts von der Platte geladen werden muss (Code), was schon an anderer Stelle im RAM steht. In auf Intel-Architekturen besierende OSe wurde diese Technologie Ende der 90iger Jahre implementiert.

2) Anders als vor dreißig Jahren bestehen Programme heute nicht mehr aus einer .exe-Datei (und das war's), sondern aus unglaublichen vielen Abhängigkeiten. Es gibt die Master-Exe (unter Windows) und gefühlt einige zehntausend Bibliotheken, die in diversen Verzeichnissen auf der Platte stehen. Herauszubekommen, welche Bibliotheken ein Programm tatsächlich benötigt, ist tricky. Wenn man einen "Boost" durch eine RAM-Disk haben will, dann muss man nicht nur die Programme selbst, sondern auch sämtliche Abhängigkeiten (AKA Blibliotheken AKA DLLs) ins RAM laden, denn sonst wird zwar das Programm von der RAM-Disk geladen, aber da erhebliche Teile des Codes in externen Bibliotheken steckt, wird all dies wieder von der lahmen Platte geladen). So'ne Aktionen sind was für ausgewiesene Spezialisten (die manuell exakt auseinanderfriemeln, was das Programm wirklich alles lädt, denn es ist ja nunmal nicht nur die Exe, die wichtig ist). Alle Zusatzkomponenten müssen dann auch auf die RAM-Disk; und bei einer neuen Programmversion geht das Gefummle wieder von vorne los, denn man weiß nicht, was die Programmierer in den Abhängigkeiten geändert haben.

In der Summe würde ich sowas heutzutage immer dem OS in Form des von ihm verwalteten Cache-Programms überlassen. Es gibt übrigens für Windows einige Cache-Programme, die man als Ersatz für das Windows-eigene Caching nehmen kann. Diese Programme haben verschiedene Vor- und Nachteile. Unter *IX-Systemen ist die Gesamttechnologie ohnehin schon höchst performant seit Ewigkeiten implementiert.

Bei verschiedenen Spezial-Programmen (wie z.B. Datenbanken) ist die Nutzung einer RAM-Disk i.d.R. sogar extrem kontraproduktiv, denn diese Programme haben eigene höchst getunte Caching-Algorithmen, mit denen die Festplattenzugriffe so weitreichend wie möglich minimiert werden. Jedes Byte, das man dem Rechner für eine RAM-Disk "klaut", wirkt sich da negativ aus, weil z.B. die Datenbank dieses Byte viel lieber für seinen eigenen Cache hätte.

Irgendwie erinnert mich diese RAM-Disk-Diskaussion an die "uralten" Autofahrer, die auch heutzutage vor dem Starten des Motors erst dreimal kräftig ds Gaspedal treten, um "Sprit in den Vergaser zu pumpen". Das das heutzutage kontraproduktiv ist, und den Motor sogar abwürgen kann, verstehen die i.d.R. auch nicht. --Denalos(quatschen) 13:56, 14. Jul. 2018 (CEST)

Tut mir Leid, aber das ist deswegen falsch, weil ich den vom Betriebssystem automatisch verwalteten Cache nicht beeinflussen kann. Es gibt zwar kleinere Stellschrauben, aber ich kann niemals - zu keinem Zeitpunkt - sicherstellen, dass bestimmte Daten (Dateien) im RAM verbleiben oder wann sie auf ein anderes Medium geschrieben werden.

Unter Linux ist es beispielsweise üblich, tmpfs für bestimmte Verzeichnisse zu verwenden. Was macht das? Das stellt sicher, dass dieses Verzeichnis definitiv immer nur im RAM vorgehalten wird. Warum ist das wichtig? Weil häufige Änderungen, auch nach Stunden, dazu führen würden, dass dies irgendwann einmal auf die Platte geschrieben würde, wenn es vom Betriebssystem als Schreib-/Lese-Cache selbständig verwaltet würde. Das will man aber nicht. Die Daten sind einerseits so klein und/oder andererseits zeitlich so sehr beschränkt, dass man sie auf jeden Fall im RAM behalten möchte. Die RAM-Disk ermöglicht genau das. Und sie ist somit kein Cache, und sie macht die RAM-Disk damit auch keinesfalls obsolet.

Wer sich jetzt fragt: Und was bringt das? Es verhindert zusätzliche Fragmentierung oder unnötige Schreibvorgänge auf Festplatten oder SSDs. Gerade bei Verzeichnissen wie /dev/shm, /var/run, /var/lock o.a. ist dies sehr sehr sinnvoll. Linux selbst hängt /dev normalerweise automatisch als tmpfs (=RAM-Disk) ein.

Weiterführende Beispiele: Arch Linux (Quelle), Gentoo Linux (Quelle).

‣Andreas•⚖ 23:12, 14. Jul. 2018 (CEST)

Deine Argumente sind nicht falsch, haben aber mit der ursprünglich hier "losgetretenen" Diskussion nichts zu tun. Ein (mittlerweile gesperrter) Wikipedianer versteifte sich darauf, dass es ein quasi ultimativer Weg sein, eine RAM-Disk anzulegen (was so ja nur unter Windows geht) und dort die ganzen "üblicherweise verwendeten Programme" hineinzukopieren, damit das OS nicht mehr auf die Platten zugreifen muss, ergo weniger Batterie-Strom verbraucht und schneller läuft. Auf diese Argumentation (die hier mittlerweile archiviert wurde) zielten meine Ausführungen ab. Dass es sinnvolle Einsatz-Szenarien für RAM-Disks gibt, habe ich nie bestritten, sie sind jedoch nicht "easy running, easy going", sondern setzen sehr genaues Wissen um die Dinge voraus. Du bringst hier eine RAM-Disk als temporären R/W-Speicher ins Spiel, das ist gedanklich etwas vollkommen anderes, als die RAM-Disk, die man zum "vorhalten" von Executables verwendet. Für Executables gelten meine ganzen Ausführungen (Copy on Write, Caching etc.), für dynamische Daten gelten andere Regeln. Bei dynamischen Daten muss man einem Programm ja auch erst mal sagen, wo es seine Tmp-Daten ablegen soll (wenn nicht gewisse Automatismen wie unter Linux greifen). Ursprünlich gibgs hier also um ein "Kochrezept für die Beschleunigung und längere Laufzeit" von Notebooks und dieses Kochrezept war einfach mal falsch, die genannten Einsatzszenarien waren schnell auch mal kontraproduktiv. Generell ist alles eine Abwägung. Ist es sinnvoll, sehr selten benötigt Daten in eine RAM-Disk zu schreiben, um den Zugriffsvorgang dann zu bescheuligen, wenn "alle Jubeljahre" mal drauf zugegriffen wird und das dann auf Kosten des Gesamtsystems (es steht weniger RAM zur Verfügung)? Oder ist es für die Gesamtperformance des Systems nicht besser, mehr RAM für alles (auch für's Caching) zur Verfügung zu haben und damit ab und an einige Millisekunden warten zu müssen, wenn Daten tatsächlich von der Platte geladen werden? Solche Fragen kann man nicht pauschal beantworten. Das hängt von Einsatzszenarien und Rahmenbedingungen ab. Man muss sehr detaillierte Kenntnisse haben, um da ein Finetuning durchzuführen. Hat man die nicht, schießt man sich schnell mal in's Knie.

Zurück zum Ursprung: Die Aussage: "Eine RAM-Disk, in die man manuell die "wichtigsten" Dinge reinkopiert" ist für den "Ottonormalverbraucher" einfach mal falsch. Der fährt mit dem OS-internen Cache i.d.R immer besser (die Verwendung der Linux-Ramdisks lasse ich mal außen vor, denn die sind nicht "usergetuned", sondern von OS- und Applikationsentwicklern getuned" --Denalos(quatschen) 12:06, 15. Jul. 2018 (CEST)

Diese ganze Diskussion über RAM-Disk, in dem Sinn mit "die wichtigsten Dinge...", ist eine Never-ending-Story, obendrein müßig und höchst esoterisch noch dazu. Für Otto-Normal-User ist eine RAM-Disk erstmal sinnlos. Aber der hat von jemandem gehört, der ihm erzählt hat, der von jemandem den Tipp bekommen hat...

Und dann werden Geschäfte gemacht. 12 Free RAMDisk vs SSD – Ten Times Faster Read and Write Speed via RAM Virtual Disk – vom März 2018!!!

Und dann gibt es noch diejenigen, die wirklich nicht wissen, was zur Hölle sie eigentlich tun (sollen)... Hardcore Hardware: We stuffed this PC with 128GB of cutting-edge DDR4 RAM (Juni 2015) – zu viel RAM? Na dann verwenden wir doch mal eine RAM-Disk, damit wir ihn wenigstens ansatzweise auch ausnutzen können... Nicht sehr gescheit! Zuerst denken, dann RAM kaufen...

Was bisher noch nicht angesprochen wurde, ist die Tatsache, dass RAM grundsätzlich keine gute Wahl für ein Speichermedium ist. DRAM error rates: Nightmare on DIMM street (von 2009): Sogenannte Bit-Level-Fehler können jeder Zeit auftreten. Und tun es auch. In vielen Fällen ist das aber egal, da es zwar das ausführende Programm beeinträchtig oder gar zum abstürzen bringt, aber nach einem Neustart werden die Daten ja wieder von der Festplatte geladen und der Fehler ist verschwunden. Für eine wichtige Datei, die man nur auf der RAM-Disk speichert, ist es also ebenfalls gefährlich. Das gedrehte Bit wird man vermutlich erst bemerken, wenn es schon zu spät ist... (und sich die Datei nicht mehr fehlerfrei öffnen lässt) – außer man verwendet ECC-RAM.

Was das Thema (RAM-Disk unter Windows) betrifft, so denke ich persönlich, dass die Verwendung von kostenpflichtigen RAM-Disk-Programmen – unter Windows – reine Geschäftemacherei ist. Denn wieviele gute kostenlose Programme gibt es dafür? So geht es eben leicht: es handelt sich um eine Niesche, die eigentlich keiner braucht (schon gar nicht Profis), aber einige Nutzer glauben eben es zu brauchen...

Das heißt aber nicht, das RAM-Disks im allgemeinen sinnlos wären, wie Linux zeigt. Aber da ist es in das Betriebssystem bereits integriert.

Hier nicht zu vergessen wäre auch, dass das Konzept von RAM-Disks schon eher alt ist. So gab es RAM-Disks auch bei System 6 von Apple. Auch bei GS/OS, wie hier zu lesen ist. Bis Mac OS 9 war eine RAM-Disk dann ganz einfach in den Systemeinstellungen einschaltbar. Ich kann es nur vermuten, aber das Indiz ist klar vorhanden, dass bei modernen Betriebssystemen eine RAM-Disk eher sinnfrei ist (außer in speziellen Ausnahmefällen, und für Profis, die genau wissen, was sie da tun): so ist die RAM Disk als Funktion des Betriebssystems in Mac OS X eben nicht mehr vorhanden (das ist das Indiz). Wer das trotzdem will, muss stöbern: Create a RAM Disk in Mac OS X (2007), Esperance DV Simplifies RAM Scratch Disk Creation in Mac OS X (2009), How to Make a RAM Disk Easily with TmpDisk for Mac OS X (2011), …

Über den wirklichen Nutzen dieser Art RAM-Disks habe ich nichts gefunden. Wie gesagt, es ist wohl eher einfach eine Geschmackssache – dabei scheiden sich die Geister. Fast so, wie die Tipps zum Defragmentieren zu Windows-XP-Zeiten...

Was ich mir einreden lasse, ist – genügend RAM vorausgesetzt – diversen Cache auf die RAM-Disk zu verlagern. Das vermeidet zu viele Schreibvorgänge z.B. auf SSDs (hier ein Artikel dazu) und dadurch resultierende Fragmentierung auf HDDs. Beispielsweise bietet das OS-X-Tool Esperance DV, das eine RAM-Disk einrichtet, das im Control Panel auch an, nämlich diverse Cache-Ordner in Richtung RAM-Disk zu "biegen" (per Symbolic Link).

Aber für ganze Programme? Das halte ich für wenig sinnvoll. Und wichtige Daten dahin zu speichern schon gar nicht.

‣Andreas•⚖ 20:30, 21. Jul. 2018 (CEST)

Von welchem Cache ist hier ständig die Rede, gibt es denn auch physisch? Große Dateien wie hochauflösende Photos, Audiodateien und Dokumente etc. landen in keinem Cache. Physisch gibt es nur den Prozessorcache und den Festplattencache im PC, die für die Datenspeicherung vollkommen ungeeignet sind, und den Arbeitsspeicher.

Deswegen gibt es die RAM-Disk, die kann große Dateien nämlich für die schnelle Bearbeitung über Stunden und Tage vorhalten. Das ist ihre Aufgabe, aus der RAM-Disk werden keinerlei Prozesse selber ausgeführt, sie ist nur ein reiner Datenspeicher, nur eben 6-10 mal schneller als jede SSD.

Das wird um so sinnvoller je mehr RAM man hat. Optimal also heute bis zu 128 RAM von denen man gut 100 GB als RAM-Disk reserviert. Und natürlich muss auch die RAM-Disk vor jedem herunterfahren gesichert werden, wie auch nach jedem Neustart wieder neu geladen werden.

Dafür brauch man weder irgendeine größere Vorbildung noch irgendeine Markensoftware. Ich leg nur wert darauf, dass das RAM-Disk Abbild vor dem Herunterfahren wirklich automatisch gesichert wird.

Der ganze Abschnitt Vorteile und Nachteile sollte gelöscht werden und dafür wirklich nur die Technik beschrieben werden. Wieso muss das hier solche esoterische Ausmaße annehmen? Ob die RAM-Disk für jemanden Sinn macht, muss doch jeder für sich selber entscheiden. --79.199.100.47 19:46, 22. Jul. 2018 (CEST)

Hallo Huhbuh, jetzt wieder als IP bei der Diskussion dabei? Das ändert aber nichts daran, dass Deine Argumente einfach nicht zutreffend sind. Wie bereits aufgeführt sind die Abhängigkeiten der Programme und Module untereinander sowie die benötigten Bibliotheken (aka DLLs) heutzutage dermaßen groß, dass ein normaler Anwender das nicht ohne weiteres ermitteln kann. Wenn man die essentiellen Teile vergisst (weil man sie nicht kennt), dann bringt die RAM-Disk nämlich absolut garnichts (schlicht weil diese wichtigen Module auf der Platte liegen). Viele große Programmpakete (insbesondere die wirklich dicken ERP-Systeme oder auch andere Großprogramme wie Photoshop, Mathematica, Autocad um nur einige zu nennen) haben zudem programminterne chaching-Algorithmen. Ganz besonders trifft das auch auf Datenbanken zu. Wenn du diesen Systemen das RAM für eine RAM-Disk abknappst, dann ist das extrem kontraproduktiv. Ohne intime Systemkenntnisse kann man heute nicht mehr ohne weiteres eine RAM-Disk mit den wichtigsten Programmen bestücken. All das machen die OS nämlich mit den vom OS verwalteten Caches sowie mit Copy on Write bei mehrmals gestarteten Programmen bereits selbst. Dein hier dargestellter Kenntnisstand entspricht dem der 80iger Jahre. Er hat absolut nichts mit dem Systemlayout heutiger OS zu tun. Damit dass du immer wieder den gleichen Unsinn erzählst, wird es einfach nicht wahrer. --Denalos(quatschen) 20:32, 22. Jul. 2018 (CEST)

Von welchem Cache die Rede ist? Vom Lese- und Schreib-Cache im RAM durch das Betriebssystem (Windows, Linux). Das sollte sich inzwischen aber aus dem Kontext ergeben haben, nicht?

Wichtige Daten aus einer RAM-Disk zu bearbeiten – und NUR dort – ist aus besagten Fehlern im RAM auf Bit-Level keine gute Idee. SSDs gibt es ja auch als PCIe-Ausführung, die sind um einiges schneller, wenn man das denn wirklich braucht. Außerdem bieten diese, wie du selbst schon anmerkst, ebenfalls einen Cache in Hardware. Wer es noch schneller braucht kann sich gerne 2 oder mehr PCIe-SSDs als RAID-0 zusammenhängen...

Was die Datenintegrität betrifft, so wäre ECC-RAM die einzige Alternative, allerdings ist dieser ebenfalls nicht sicher bei Stromausfällen – außer man verwendet ein UPS.

Wenn es RAM-Disk-Programme (für Windows) gibt, die Änderungen in der RAM-Disk überwachen, Fehlerkorrektur beiten, automatisches Sichern in zeitlichen Intervallen und Event-basiert (Herunterfahren, Schlafen/Hybernate/Stand-by), dann ist das sicher eine Option, aber es bleibt dennoch eine Niesche und definitiv esotherisch (heißt: man muss daran glauben... oder eben nicht).

Über die Vor- und Nachteile einer RAM-Disk zu informieren gehört schon in einen solchen Artikel.

‣Andreas•⚖ 20:47, 22. Jul. 2018 (CEST)

Auch eine PCIe-SSD kann keine RAM-Disk ersetzen. Hier mal ein Beispiel:

Guter DDR4-RAM, z.B. der "Corsair CMD32GX4M2C3200C14M 16GB" kommt im lesen gemessen aktuell auf 21,146 MB/s und schreiben auf 16,778 MB/s für Intel CPUs.

Die schnellste M.2 (PCIe) SSD, aktuell die Samsung SSD 970 PRO, kommt hingegen auf nur 3500 MB/s lesen und 2700 MB/s, wobei das sind Herstellerangaben, in der Realität mit Sicherheit nicht.

Die RAM-Disk ist hier also noch minimal sechsmal schneller!

ECC bringt für normale Anwender auch nichts, da DDR4 eh schon ein einfachen Schutz gegen Übertragungsfehler eingebaut hat, im Gegensatz zu DDR3.

Wenn ich meine Dateien also im Rahmen von z.B. einer 100 GB RAM-Disk von 128 GB RAM, bis zu sechsmal schneller lesen und schreiben kann, was ist daran verkehrt? Der reservierten 28 GB RAM Arbeitsspeicher nutzt auch eine Kombination aus Adobe Photoshop, Adobe Premiere, Firefox mit 100 Tabs und Microsoft Word + 3D Spiel im Hintergrund gleichzeitig nicht aus.

Die meisten Leute nutzen tatsächlich ja auch nur 8-16 GB RAM für alles. Wer massenweise zwischen kleinen Dateien switcht, wie eben zur Audiobearbeitung oder in großen Dokumenten, profitiert also ganz extrem von einer RAM-Disk. Das kompensiert absolut kein Arbeitsspeicher interner Prozess oder sonst eine Cacheverwaltung!

Eine RAM-Disk ist wie eine minimal sechsmal schnellere Festplatte, die auch genauso wie eine Festplatte bedient wird und sonst nichts, ich muss dafür auch nicht irgendwelche Module suchen, die genutzten Hauptprogramme sollten schlicht und einfach nur mit auf der RAM-Disk installiert sein bzw. in ihrem Festplattenabbild, das beim Neustart hochgeladen wird.

Was wird hier also auch immer um den heißen Brei erzählt und alles nur unnötig verkompliziert? --79.199.100.47 11:43, 23. Jul. 2018 (CEST)

so eine ram isk ist eh witzlos, egal wie schnell die ram disk ist, sobald der inhalt auf die hdd muss, ist die hdd wieder der flaschen hals.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 12:27, 23. Jul. 2018 (CEST)

An die IP (Huhbuh): Getretner Quark wird breit nicht stark. Viele moderne Programme sind nur noch "Loader" für andere Programme oder DLLs. Alleine das Programm (also die .EXE) in eine RAM-Disk zu laden, bringt da mal gar nichts, weil der Großteil der "Nutzmodule" schlicht woanders untergrebracht ist. Das will ich sehen, dass ein "normaler Anwender" weiß, was er alles in die RAM-Disk laden muss, damit ein Programmsystem vollständig von dort geladen wird. In der Regel werden diverse Runtimes benötigt, das gesamte .NET-Framework, wenn man pech hat auch noch Java und sonst noch diverses. Programme greifen ja nicht nur auf "mitgebrachten" code zu, sondern auch auf eine Vielzahl von Standardbibliotheken. Viel Spaß beim herausfriemeln, ob man die nun zwecks Performance-Steigerung in eine RAM-Disk laden sollte oder nicht. Bei einigen Sachen dürfte das nicht mal gehen (schlicht, weil man DLL-Pfade z.B. nicht ohne weiteres verbiegen kann). Selbst wenn man mal das meiner Ansicht nach unsinnige Szenario der 100 GB-Ram-DIsk für Programme betrachtet, dürfte man die meisten Leute damit wohl total nerven. Nehmen wir mal "realistische Idealbedingungen": Dicke SSD im Rechner und man kopiert 100 GB bei Start von der SSD in eine RAM-Disk. Bei einer Transferrate von 1 GB/sec dauert das rund 100 Sekunden; da springe ich als User doch im Dreieck, wenn sich durch einen Kopiervorgang, der mir vielleicht später einen Performancevorteil bringt, glatte eineinhalb Minuten länger warten muss, bis der Rechner vollständig gestartet ist. Wenn's nur 'ne normale Festplatte ist, dann wird's noch schlimmer: Durchsatzrate 200 MB/sec=500 Sekunden Wartezeit, bis die RAM-Disk gefüllt ist. Und dann noch die von Andreas geschilderten Bit-Fehler. Egal, wie man's dreht, es gibt so gut wie keine Konstellation, bei der die Nutzung einer RAM-Disk einfach ist und dann auch noch was bringt. --Denalos(quatschen) 14:37, 23. Jul. 2018 (CEST)

Nachtrag: ECC hat nichts mit Übertragungsfehlern zu tun, sondern damit kann festgestellt werden, ob in einer Speicherbank Bits gekippt sind. Bestimmte Bitfehlerkombinationen kann eine Speicherbank sogar selbst korrigieren. Dafür braucht's wiederum Speicher (der beim ECC-RAM zusätzlich draufgelötet wird). Deshalb ist ECC-Ram auch teurer. Dass DDR4 solche Funktionen hat, ist mir nicht bekannt. Im IEEE-Journal (habe ich grade nicht zur Hand) wurde mal nachgerechnet, wie groß die Wahrscheinlichkeit für "Bitkipper" bei dickem Speicherausbau sind. Das Ergebnis war erschreckend unerfreulich. Wenn man 128 GB RAM (und zwar stinknormales RAM) im Rechner hat, liegt die Wahrscheinlichkeit für kippende Bits im Minutenbereich. Da kommt keine Freude auf, wenn sowas bei Sachen passiert, die auf 'ner dicken RAM-Disk gespeichert sind. Genau aus diesem Grund setzt man bei Servern mit viel RAM auch ECC-RAM ein (und legt sehr viel mehr Geld dafür auf den Tisch). --Denalos(quatschen) 15:21, 23. Jul. 2018 (CEST)

Wer auf das Feature ECC wert legt, findet dafür Mainboards für den Intel Sockel 2066, mehrere sogar bis 512 GB (RDimm) Unterstützung!Die meisten tragen sogar 'Gaming' im Namen also nicht mal eine Serverplattform, damit wäre dieses Bitkipper Problem und das noch fehlender Windows-Komponenten Java, .NET-Framework usw. doch erledigt.

Es wird einfach alles inklusive Windows in die RAM-Disk installiert! Es gibt mehrere Beschreibungen im Netz dass das auch funktioniert, die RAM-Disk bzw. ihr VHD Image muss nachher nur von einem Bootmanager erkannt und in den RAM geladen werden.

Das dauert sicher länger als wie ein normaler Boot von SSD, aber den kann man sich ja auch komplett ersparen, wenn man den PC nur noch in den Standby schickt! Was spricht jetzt noch gegen die RAM-Disk?

Ein "Samsung DIMM 64GB, DDR4-2666, CL22-19-19, reg ECC" kostet aktuell ca. 500 Euro mal 8 sind wir dann bei 4000 Euro. Das ist für PC-Enthusiasten überhaupt kein Thema! Im Gegenzug kann man sich dann auch wieder mit billigsten HDD Massenspeichern eindecken statt teurerer SSD, da man auf diese eh kaum noch zugreift!

Das ist die Geschichte über den Sinn der RAM-Disk, doch einfach nur missverstanden und fehlinterpretiert! --79.199.100.47 17:11, 23. Jul. 2018 (CEST)

Sag mal was willst du hier beweisen? kein einziger user will sein windows auf einer ram disk innstallieren, windows unterstützt das noch nicht einmal. 4000 für ram noch mal 2000für eine cpu und wen das system abstürtz ist alles weg, einmal falsch geklickt, alles futsch.die nachteile und die hohen kosten sprechen gegen, alles auf ram disk nutzten.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 17:24, 23. Jul. 2018 (CEST)

Von was redest du? Windows samt aller Daten wird gewöhnlich per Grand Unified Bootloader kurz GRUB in die RAM-Disk geladen. Wenn das System abstürzt hat man immer noch die Kopie von der letzten Session und die aktuellen Kosten spielen auch keine Rolle, es geht hier schließlich um grundlegende Funktionen und den Sinn dahinter, auch wenn die hier offenbar niemand verstehen will. Da will man über technische Dinge aufklären und muss sich mit entfernt. -Squasher (Diskussion) 07:40, 24. Jul. 2018 (CEST) rumschlagen, die auch den ganzen Artikel mit reinen Ansichten zumüllen, obwohl es sich um Technik handelt, das ist wirklich eine Zumutung. --79.199.100.47 23:42, 23. Jul. 2018 (CEST)

inntresannt, für mich sieht das nemlich genauso aus, "die auch den ganzen Artikel mit reinen Ansichten zumüllen" ich sehe hier nur einen unangemedleten user, derUNBEDINGT seine Ansicht durch drücken will.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 00:45, 24. Jul. 2018 (CEST)

Da es keine neuen Argumente gibt, denke ich, kann diese Diskussion nun beendet werden. ‣Andreas•⚖ 21:18, 23. Jul. 2018 (CEST)

+1--Conan (Eine private Nachricht an mich? Bitte hier lang.) 21:25, 23. Jul. 2018 (CEST)

+1 (und ich bin dann auch mal so frei...) --Denalos(quatschen) 07:47, 24. Jul. 2018 (CEST)

Abschließender Nachtrag: Das Absurde an dieser Diskussion hier ist, dass es anfing als "einfache und nicht sehr teure Möglichkeit, die Performance eines Rechners deutlich zu steigern". Als dann gezeigt wurde, dass das nicht so einfach ist (weil div. OS schon ziemlich trickreiche performance-steigernde Mechanismen wie z.B. Caching enthalten) wurde erstmal geraume Zeit die Existenz dieser Mechanismen (also Cache) bestritten. Als dann klar war, dass man diese Techniken wohl nicht verleugnen kann, wurden sie ignoriert bzw. mit unfundiertem pseudo-blabla diskreditiert. Von Andreas wurde das korrekte Argument der Bitkipper in nicht-ECC-RAM gebracht. Das wurde dann auch erst mal versucht zu diskreditieren und als klar war, dass das Argument sehr wohl zieht, wurde gesagt, dass man dann halt ECC-RAM nehmen soll. Dem Argument, dass es für Otto-Normalanwender annähernd unmöglich ist, eine passende Kollektion der benötigten Komponenten zusammenzustellen, wurde auch dagegen ein neues Argument gebracht, indem man dann halt eine so große RAM-Disk installieren soll, dass man alles da rein kopieren kann. Die einhergehenden Probleme (von mir und von Conan aufgezeigt, wurden wiederum, diesmal mit PA diskreditiert. In der Summe bleibt eine Rechnerkonstellation, die fern ab aller rationaler Betrachtungen ist und denoch nicht zufriedenstellen funktioniert.

Das ist hier also die Zusammenfassung obiger Diskussion. Man kann jedes beliebige - untaugliche - Konzept im Nachgang so extrem aufblasen, dass es dann doch irgendwie funktioniert. Die ursprüngliche Zielsetzung (Einfachheit, Kosten) hat man dann jedoch aus den Augen verloren. Der Begriff des Concorde-Trugschlusses hat sich dafür schon mal etabliert. Besteht ein Zusammenhang damit, dass der Standort der diskutierenden IP nicht fernab vom BER liegt? --Denalos(quatschen) 08:36, 24. Jul. 2018 (CEST)

Dein ominöser Cache der eine RAM-Disk ersetzt existiert nicht andernfalls kannst du ja gerne mal versuchen zu erklären, wo dieser Cache auch eine SSD oder HDD ersetzt. Die Sockel 2066 Boards mit RDIMM Unterstützung bis 512 GB haben die RAM-Disk Einstellungen dafür schon im Bios verankert. Das sind normale Gaming Boards für Enthusiasten und keine Wissenschaft. Die existieren aber auch erst seit ca. einem Jahr für ECC-Speicher, die müssen nicht jedem geläufig sein.

Du hast einfach nicht den Unterschied zwischen temporären und statischen Daten verstanden, und versuchst aber das eine mit dem anderen zu zerreden. Mit irgendeinem vom OS verwalteten Cache. Auf welchem physischen Baustein der sitzen soll, hast du dich aber verweigert zu antworten. Logisch, denn eine RAM-Disk steht eben nicht für den aktiven Arbeitsspeicher, CPU- oder Festplattencache sondern nur für die Reserve darin für die Daten! --91.1.56.236 11:28, 24. Jul. 2018 (CEST)

neue ip, selber user, wen juckt EIN sockel mainboard? richtig! NIEMAND!--Conan (Eine private Nachricht an mich? Bitte hier lang.) 12:29, 24. Jul. 2018 (CEST)

"Das sind normale Gaming Boards für Enthusiasten" zweifle ich öffentlich an, richtige gamer setzten keineram disk ein, da wird auf viel ram, viel cpu und schnelle ssd gesetzt, nicht mehr und nicht weniger, was SIE da betreiben ist Therifindung, damit SIE recht haben, mehr ist das hier nicht mehr.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 12:32, 24. Jul. 2018 (CEST)

An die IP: Du bist schon eine echte Herausforderung mit Deinem sehr konsequent vorgetragenem Unverständnis bezüglich der Funktionsweise von Betriebssystemen. Du mischt verschiedenste Technologien zu einem Gesamtbrei zusammen, den Du dann bedarfsbezogen Interpretierst: Also nochmal zum Mitschreiben:

1) Betriebssystem startet und belegt von x-Bytes RAM nur x-n Bytes, also bleiben n Bytes frei (das nennt man Heap)

2) Betriebssystem started den Cache-Treiber, Cache-Treiber schaut nach, wie viel freien Heap es gibt und reserviert diesen Heap für sich

2.1) Cache-Treiber registriert mehrere Hooks (einen im Festplatten-Lese-Algorithmus, einen im Festplatten-Schreib-Algorithmus, einen im Low-Memory-Algorithmus)

3) Wenn eine Festplatten-Leseanforderung ankommt, springt der Cache-Hook an und schaut, ob diese Infos bereits im Cache enthalten sind, ist das der Fall, wird nicht auf die Festplatte zugegriffen, sondern die Daten werden direkt aus dem Cache (aka RAM) bedient; Zeitgleich wird ein Zähler- und Zeitstempel für diesen Zugriff gesetzt bzw. erhöht. Sind die Daten nicht im Cache, dann werden sie tatsächlich von der Platte gelesen und zusätzlich im Cache abgelegt (wiederum mit Zähler- und Zeitstempel), bevor die Daten an das anfordernde Programm weitergegeben werden.

4) Wenn der Cache voll ist, dann werden die Daten überschrieben, die am seltensten gelesen wurden (hier gibt es aber eine Vielzahl an Cache-Konsolidierungsstrategien, da steckt richtig viel Software-Knowhow drin). Somit verbleiben Daten, die häufig von der Platte angefordert werden, auch dauerhaft im Cache

5) Wenn es einen Schreib-Request gibt, können verschiedenste Varianten des Managements anlaufen, je nachdem ob der Cache Write-Through oder Write-Back ist

6) Wenn dem Betriebssystem "das RAM ausgeht", springt der Low-Memory-Hook an und der zugehörige Code schaut nach, welche Komponenten im Cache freigegeben werden können, damit der dadurch freiwerdende Speicher dem allgemeinem Heap des Rechners zugeschlagen werden kann.

In der Realität ist alles etwas komplizierter, aber das ist die Grundstruktur. Wenn die IP sich weiterhin weigert, das zu verstehen, dann gibt's nur zwei Erklärungen: Entweder das Begriffsvermögen reicht nicht aus, um technische DV-Zusammenhänge zu verstehen, oder die IP will das einfach nicht verstehen, weil sie einfach nicht einsehen kann, dass sie auf dem Holzweg ist. Auf meinem Desktop-Rechner (128 GB RAM, 2 TB SSD, und 4 TB HD) führt das dazu, dass auf das Laufwerk C nach einer Stunde "normaler" Arbeit quasi so gut wie gar nicht mehr zugegriffem wird, da nämlich alle Code-Komponenten mittlerweile im Cache liegen. Ich setze keine RAM-Disk ein. Insofern (nochmal an die IP) hör endlich auf, diesen absoluten Unsinn zu erzählen. Realität: Es gibt Konstellationen, bei denen eine RAM-Disk Sinn ergibt, die sind aber so exotisch, dass sie für den "normalen" Anwender heutzutage zu gut wie nie anwendbar sind. Unter *IX-Betriebssystemen kenne ich diese ganzen Komponenten und Überlegungen und Vor- und Nachteile sowie das Zusammenspiel schon seit den 80iger Jahren. Insbesondere die Caching-Techniken sind im Laufe der Jahrzehnte immer raffinierter geworden, und da es bei all dem auf ein höchst feingliedrigen Zusammenspiel der Komponenten ankommen, kann man als "Normal-User" mit "Hand-Tuning" (aka RAM-Disk)eigentlich nur negative Ergebnisse erzeugen. --Denalos(quatschen) 13:46, 24. Jul. 2018 (CEST)

Unterschied zwischen RAM auf den Komponenten und "allgemeinem" Computer-RAM: Es gibt diverse technische Komponenten, die eigenes RAM haben und das auch selbst für die verschiedensten Zwecke verwalten. Und es gibt das allgemeine Computer-RAM. Wenn ein OS gestartet wurde, dann verbleibt nach dem Start mehr oder weniger freies RAM. Dieses freie RAM wird vom Betriebssystem dynamisch verwaltet und den anfordernden Prozessen dynamisch zugewiesen. Ein Cache-Treiber ist nichts anderes als ein dynamischer Prozess (so wie übrigens auch eine RAM-DISK), mit dem großen Unterschied, dass die RAM-Disk dauerhaft eine Menge an x Bytes vom RAM des Rechners "abbeißt", wobei ein Cache dynamisch unterschiedlich viel RAM belegt. Wenn das OS viel freies RAM hat, dann greift sich der Cache-Treiber auch entsprechend viel RAM, geht dem OS das RAM aus, dann gibt der Cache-Treiber Bereiche seines Speichers wieder an das OS (zur anderweitigen Verwendung) zurück. Wenn der Cache-Treiber tief genug im OS verankert ist, dann wird der vom Cache belegte Speicher nicht mal als aktuell verwendet angezeigt, da er ja jederzeit vom Cache-Treiber an das OS zurückgegeben werden kann. --Denalos(quatschen) 13:55, 24. Jul. 2018 (CEST)

Zitat: "Auf meinem Desktop-Rechner (128 GB RAM, 2 TB SSD, und 4 TB HD) führt das dazu, dass auf das Laufwerk C nach einer Stunde "normaler" Arbeit quasi so gut wie gar nicht mehr zugegriffem wird, da nämlich alle Code-Komponenten mittlerweile im Cache liegen."

Und genau das ist die Unwahrheit um die es hier die ganze Zeit geht, die du hier aber verbreiten willst. Du verstehst nicht dass Programme nicht nur aus ein paar vorhersehbaren Code-Komponeten sondern vor allem auch aus Gigabyte großen Arbeitsdaten bestehen, die das OS auch niemals vorlädt. Außerdem hält nicht jeder alle Anwendungen im OS offen.

Ansonsten müsste der RAM in dem z.B. mein gerade geöffnetes Adobe Photoshop CC 2018 776 MB belegt schon vorher im RAM reserviert gewesen sein. War es aber nicht, weswegen auch der Start von der SSD gut ca. 8 Sekunden gedauert hat und nicht 1-2 Sekunden wie aus der RAM-Disk! Das ändert sich auch nicht nach mehrmaligen beenden und starten, es gibt da einfach kein Cache-Algorithmus der da stützend eingreift. Was der vorlädt, das aber schon mit Windowsstart, sind nur die üblichen Treiber.

Wenn der Cache-Treiber so intelligent wäre wie du ihn ständig darstellst, hätte man niemals etwas wie eine SSD entwickeln müssen, 32 GB RAM und eine lahme aber große HDD hätten das selbe erreicht. Der Geschwindigkeitsunterschied zwischen RAM und SSD beträgt in der Realität aber immer noch ca. 1 zu 6! Den Benchmark der ein gleichen Startverhalten von Programmen von der SSD zeigt, den gibt es einfach nicht, die Benchmarks ignorierst du hier aber noch alle! --46.89.143.175 18:08, 24. Jul. 2018 (CEST)

Hallo IP 46.89.143.175! Erstens wäre es für's Diskutieren viel leichter, wenn du dich anmelden würdest.

Zweitens – Desktop-Rechner mit 128 GB RAM, ja, das ist schon außergewöhnlich, nicht? Ich denke mal, hier ging es nur um einen Punkt, nicht darum, dass ein Standard-Desktop-Rechner soviel RAM hätte. Das ist natürlich nicht so. Heute sind 4 GB, 8 GB genauso verbreitet wie 16 GB, manchmal auch 32 GB. Profis, die den RAM wirklich benötigen, haben teilweise auch mehr.

Was den ominösen Cache betrifft: ja, genau so wie es beschrieben ist, funktioniert es auch. Wenn das bei dir nicht so ist, dann ist das eigentlich ein sehr seltsames Verhalten deines Betriebssystems. Ein Programm, das nach dem Start < 1 GB RAM belegt und dafür 8 Sekunden von der SSD benötigt, und das anschließend wieder geschlossen wird, sollte auf keinen Fall bei sofortigem erneuten Laden (Starten) noch einmal 8 Sekunden brauchen. Es sollte mindestens weniger als die Hälfte sein. Alles, was das Programm beim Starten von der SSD (oder HDD) gelesen hat, sollte bereits in diesem ominösen Cache gespeichert sein. Und dort verbleibt es so lange, bis der Speicher für wichtigere Dinge gebraucht wird.

Was ich interessant finde, ist, dass du versuchts, die RAM-Disk als Performance-Gewinn zu verkaufen und zahlreiche technische Details lieferst (scheinbar), andererseits aber die simple Logik eines Disk Cache nicht verstehst. Wenn du des Englischen mächtig bist, ließ mal das hier: Abschnitt Effects of disk cache on load times ist sehr interessant...

Manche nutzen (unter Unix) übrigend dd, um Programme und Dateien in den Disk I/O Cache zu laden: dd if=<application> of=/dev/null. Das kopiert alles in ein großes Schwarzes Loch, mit anderen Worten, die Daten in den Dateien (symbolisch als <application> hier angeführt) werden nur gelesen, landen dabei aber im I/O Cache – im RAM. Beim erneuten laden dieses Programms, <application>, sind die Daten dann schon im RAM und die Ladezeit des Programms dementsprechend schneller. (dd read into /dev/null, page cache)

Und jetzt wird es richtig lustig: RAM ist bis zu 6 Mal schneller als eine SSD? Kann sein. Das Beispielprogramm Hello World vom oben verlinkten (englischen) Artikel braucht 1.026s von der HDD, aber nur 0.022s aus dem Disk I/O Cache, also aus dem RAM. Wenn man nun eine Festplatte testen will ist dieses Verhalten kontraproduktiv! Daher fragen einige Leute sogar nach, wie man den I/O Cache leeren kann! So ominös ist dieser Cache also gar nicht, er ist sogar sehr konkret: How to purge disk I/O caches on Linux – “I need to do it for more predictable benchmarking.” schreibt der Fragesteller. Der Cache verfällscht hier das Benchmark-Ergebnis. Man muss Linux daher vorher dazu bringen, den I/O Cache zu leeren, damit es so tut, als würde es die Dateien das erste Mal lesen.

Und nochetwas zur RAM-Disk: Gehen wir mal von 64 GB RAM aus, 32 GB davon als RAM-Disk und 32 GB als Arbeitsspeicher für geladene Daten. In zweitgenannten 32 GB als Arbeitsspeicher ist dann neben dem Betriebssystem natürlich auch der I/O Cache... Das aber nur am Rande. Worum es mir geht: wenn du Photoshop aus der RAM-Disk lädst, dann ist ein Teil von Photoshop nun 3x im RAM enthalten: 1. auf der RAM-Disk, 2. im I/O Cache, solange noch RAM frei ist (sonst werden die ältesten gecachten Daten aus dem I/O Cache entfernt, solange, bis wieder Arbeitsspeicher frei ist) und 3. als geladenes Programm im Arbeitsspeicher.

Richtig gut wäre also die Verwendung von XIP: Execute in Place (englisch). Aber das funktioniert mit einem Standard-Desktop-Betriebssystem nicht ohne weiteres...

Und das alles erstmal unter außenvor lassen von Bitfehlern bei SDRAM. Denn welcher Desktop-Anwender nutzt teueren ECC-SDRAM? Fast keiner. Und welcher Gamer? Sicher keiner, da RAM mit ECC im Regelfall langsamer ist als für Gamer interessanter schneller (und oft übertaktbarer) Non-ECC-Standard-SDRAM.

Wie es bereits geschrieben wurde: ein Programm von RAM-Disk in 1-2 Sekunden zu starteten anstatt es von der SSD in 8 Sekunden zu starten bringt viel mehr Nachteile als Vorteile, da die RAM-Disk dafür nur mangelhaft geeignet ist. Die Wartezeit für das Laden verlagert sich nur und der RAM-Anteil der RAM-Disk wird festgebunden auf eine einzige Funktion, nämlich das Speichern von relativ statischen Daten, für das ja bekanntlich die Stromausfall-sicher(er)en Festplatten (HDD und SSD) entwickelt wurden. Im RAM hingegen kann, gerade durch Disk I/O Caching, der vorhandene Platz viel flexibler genutzt werden. Und wenn es dir wirklich ein Torn im Auge ist wie langsam Photoshop startet, dann "prime" dir diesen Start doch einfach, indem du die Dateien vorab in den I/O-Cache laden lässt. Unter Windows sollte ein einfaches Batch-Skript diese Aufgabe bewältigen: COPY <application> NUL: macht dasselbe wie das oben Beschriebene (für Unix/Linux), nur eben auf der Windows-Eingabeaufforderung.

Und wenn du es jetzt noch nicht verstanden hast, dann kann ich dir auch nicht mehr weiterhelfen.

Apropos: Ich verwende die Du-Form, weil es sich über Jahre so etabliert hat.

Also! Sei mutig! Aber bitte belege Änderungen bzw. belege überhaupt deine Aussagen. Sonst fällt es anderen schwer, dir zu folgen. ‣Andreas•⚖ 00:19, 26. Jul. 2018 (CEST)

@Andreas: Die IP kann sich nicht anmelden, weil es sich bei der IP um den infinit gesperrten Nutzer Benutzer:Huhbuh handelt. Diese ganzen Kommentare der IP (die mehrmals wechselte) sind überhaupt nur durch Sperrumgehung entstanden. Deine sehr sauber ausgeführten Begründungen sind zwar korrekt, werden die IP denoch nicht zum Einlenken bringen, da sie entweder nicht mal ansatzweise weiß, von was sie redet oder eben einfach nur recht haben will. --Denalos(quatschen) 07:51, 26. Jul. 2018 (CEST)

hallo Benutzer:Huhbuh sperrumgehung ist was feines, stimmts? Sie müssen software entwicker bei adobe sein, woher wüsten sie sontst wie das programm intern arbeitet?--18:46, 24. Jul. 2018 (CEST)

Das durch Huhbuh partielle unter den Tisch fallen lassen von Informationen bei immer wieder leicht abgewandeltem Einsatzszenario lässt das Argumentieren vollkommen sinnlos werden. Ich werde dazu nichts mehr sagen, das ist vergebene Liebesmüh. --Denalos(quatschen) 22:12, 24. Jul. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Denalos(quatschen) 07:47, 24. Jul. 2018 (CEST)

ich stimme dir zu und gebe den kampf gegen die windmühle auch auf--Conan (Eine private Nachricht an mich? Bitte hier lang.) 22:34, 24. Jul. 2018 (CEST)

Im Router IP alle 24h wechseln einstellen, ist weder Hexenwerk noch Speerumgehung.

Wenn mit Disk I/O Caching nur so was wie die RAM-Disk unter Linux gemeint ist, sollte man das im Artikel aber auch besser darstellen. Unter Windows versteht man unter Cache nämlich auch den CPU- und Festplattencache, die sich zur Aufnahme großer Daten eben nicht eignen. --91.1.56.56 11:57, 27. Jul. 2018 (CEST)

Sorry, das ist wieder Unsinn, den du da erzählst. Das Caching ist unter Linux nur besser dokumentiert als unter Windows, aber grundsätzlich gelten die gleichen Mechanismen und Regeln. Allerdings hat auch unter Linux das Caching nichts mit der RAM-Disk zu tun, das sind vollkommen unterschiedliche Sachen, die Du sehr offensichtlich nicht verstehst. Wenn Du dich mit OS-Design nicht auskennst, solltest Du dich hier besser nicht äußern. Abgesehen davon betreibst du schlicht eine Sperrumgehung. --Denalos(quatschen) 12:03, 27. Jul. 2018 (CEST)

Wenn ich wirklich gesperrt bin, musst du die Speere eben alle 24h erneuern oder die ganze Domain sperren, das ist doch jetzt nicht meine Arbeit.

Asus bietet übrigens RAM-Disk und RAM-Cache Einstellungen in seinem Mainboard-Bios an. Der RAM-Cache ist aber nicht schneller, der ist genauso schnell wie die RAM-Disk und basiert auf einem angelernten Verzeichnis statt Laufwerkbuchstabe. Die Lösungen existieren vollkommen parallel. https://rog-de.asus.com/asus-ramdisk-und-ramcache-erklaert/ In jedem Fall muss man sie noch vor dem OS im Bios festlegen, Windows regelt da von sich aus nichts. --79.199.98.146 12:52, 27. Jul. 2018 (CEST)

Du verwechselst oder vermengst unterschiedliche Technologien: Hardware-Caching, Hardware-RAM-DISK durch den Board-Hersteller und Software-Caching/Software-RAM-Disk durch das OS. Das ist so, als ob man ein Pedelec mit einem Fahrer einer bestimmten Trainingsklasse mit einem Fahrradfahrer einer anderen Trainingsklasse vergleiche. Man könnte auch sagen, dass Du Äpfel mit Birnen und Rosenkohl vergleichst und darauf basierend irgendwas zusammenschwurbelst. Was irgend ein Board-Hersteller an speziellen Sonderlösungen anbietet, hat nicht das geringste mit dem Artikel zu tun. --Denalos(quatschen) 13:02, 27. Jul. 2018 (CEST)

Manche UEFI-Bios bringen auch ihren eigenen Browser mit, das ist doch jetzt vollkommen nebensächlich ob die ihre Lösungen schon im Bios darbieten oder als Software für das OS nach dem Boot. Die Bios-Lösung von Asus nennt sich jedenfalls auch "RAMDisk" und legt wie auch auch schon beschrieben ein Speicherabbild auf der Festplatte ab, weil es ganz offensichtlich keinen Ersatz dafür gibt! Asus "RAMCache" ist hingegen nur die elegant selbst-lernende Version davon.

Nichts davon hätte Asus jedenfalls in Bios eingebaut, wenn Windows dafür schon was ähnliches gehabt hätte! Auf neueren MSI Bords ist das genauso.

Du leugnest hier ohne Sinn und Zweck ein bedeutendes Feature, wem soll das eigentlich zu mehr Umsatz verhelfen? Du bist die Feuerwehr dafür? --79.199.98.146 13:30, 27. Jul. 2018 (CEST)

Was bringt dich zur Annahme, dass diese Programme (ASUS ROG RAMDisk und RAMCache) irgendetwas mit dem BIOS (eigentlich UEFI, aber okay) zu tun haben? ‣Andreas•⚖ 23:26, 28. Jul. 2018 (CEST)

@Denalos warum diskutierst du mit noch mit dem Troll? Ignorie ihn doch einfach. Alles andere ist doch verschwendung.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 13:32, 27. Jul. 2018 (CEST)

Durch Hardware bereitgestellte RAM-Disk

Ich habe für den betreffenden Abschnitt einen Überarbeiten-Baustein eingefügt. Ich bitte abermals darum, dass mir gezeigt wird, was das genau sein soll. Welche Hersteller bieten wie die Möglichkeit, RAM abzuzwacken?!?

‣Andreas•⚖ 20:54, 29. Jul. 2018 (CEST)

Siehe mein Kommentar hierzu ein Kapitel drüber. Ob's sowas wirklich gibt, kann ich nicht beurteilen. Die Board-Hersteller müssten schon ziemlichen Aufwand betreiben und warum sollten sie das tun? Es gibt deutlich andere Sachen, mit denen ein Board-Hersteller punkten kann.

Sinn ergibt sowas ohnehin imho nur mit registeres ECC-RAM. Das ist bekannterweise richtig teuer und kommt bei Gamern nicht zum Einsatz (wegen der Langsamkeit). Im Serverbereich braucht man sowas auch nicht. stellt sich mir also ebenfalls die Frage "gibt's das überhaupt?". --Denalos(quatschen) 22:28, 29. Jul. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ‣Andreas•⚖ 23:00, 29. Jul. 2018 (CEST)

Resetfeste RAMs?

Zitat: "(z. B. nach einem Absturz) ist der Inhalt der RAM-Disk im Allgemeinen (außer bei resetfesten RAM-Disks) verschwunden."

Kann bitte mal jemand auch diesen Unsinn unter Nachteile löschen? Der RAM ist zwar tatsächlich nicht resetfest, allerdings bieten nahezu alle RAM-DISK Programme heute auch schlicht die Funktion an, die RAM-Disk einfach als Image-Datei auf der Festplatte zu sichern.

Resetfeste RAMs werden hier also auch gar nicht benötigt. --91.1.48.114 22:54, 12. Jul. 2018 (CEST)

Meinst du diesen Chip-Artikel? --AlternativesLebensglück (Diskussion) 23:23, 12. Jul. 2018 (CEST)

Sind ram-disks, die img datein schreiben, nicht Resetfeste?--Conan (Eine private Nachricht an mich? Bitte hier lang.) 23:25, 12. Jul. 2018 (CEST)

Mit resetfest ist auch gemeint dass die Speicherhardware die Daten selber hält, das spielt aber praktisch keine Rolle, da die Ramdiskprogramme heute auch alle ein Image auf der Platte ablegen können, so wie eben im Chip Artikel beschrieben. Deswegen ist die nicht resetfeste RAM-Disk heute auch kein Nachteil mehr.

Der Nachteil besteht nur beim booten des PC, da die Daten erst wieder von der Festplatte in die RAM-Disk geladen werden müssen, danach stehen sie aber mit ca. 10-facher SSD Geschwindigkeit zur Verfügung.

Sofern man den PC nur in den Ruhezustand schickt, bleibt die Ramdisk aber auch erhalten. Sie hat dann auch absolut keine Nachteile mehr, bis auf natürlich die immer noch benötigte Backup-Platte.

Das ganze war im gelöschten Abschnitt "Praktische Anwendung" auch schon mal beschrieben: https://de.wikipedia.org/w/index.php?title=RAM-Disk&diff=179082188&oldid=178972553

Ich weiß nicht warum man den entfernt hat. Der Artikel steht im Moment noch eher auf dem Stand von 1990, nennt keine typische Hardware dafür und erwähnt auch nicht die modernen Standby-Einstellungen von modernen 80+ Netzteilen und Mainboards. --2003:CD:7F3B:19B8:6422:BD58:5C6D:7533 01:11, 13. Jul. 2018 (CEST)

An die IP (wohl Benutzer:Huhbuh Ich habe keine Ahnung woher Du Dein unglaubliches Halbwissen her hast. Deine ganze Argumentation ist durchsetzt von fehlendem Wissen um technische Details heutiger OS. Sicherlich kann es RAM-Disk-Konstellationen geben, die sinnvoll sind. Für den Ottonormalanwender ist das jedoch mittlerweile gar nicht mehr anwendbar, da die OS so extrem tricky sind, dass sie mit sehr ausgereiften Techniken den HD-Zugriff automatisch minimieren. Zur OS-Beschleunigung taugt eine RAM-Disk heutzutage quasi gar nichts mehr, dürfte häufig sogar kontraproduktiv sein, da sie konstant RAM belegt, das z.B.von diversen Cashes besser verwendet werden könnte. Ich kenne diese Techniken und deren Entwicklungen seit über 35 Jahren auf mehr als 12 OS, und das was Du hier alles erzählst ist einfach vollkommen veraltete Wissen. Der Artikel ist so wie er ist, durchaus OK (besser kann immer alles werden) --Denalos(quatschen) 07:57, 13. Jul. 2018 (CEST)

Abbilder (aka Image) von einem Datenträger sind nie Bestandteil der Datenträgerstrategie, sondern Teil der Sicherungsmaßnahmen. RAM-Laufwerke sind in ihrer Definition schon keine Abbilder, dann würde auch ihr Vorteil verschwinden. Es gibt Slotkarten, welche aus RAM-Bausteinen zusammengesetzt sind, diese besitzen auch einen Pufferspeicher, damit bei Stromunterbrechung oder Reset diese Daten erhalten bleiben, diese zählen allerdings eher zu den Solid State Disks. Ein RAM-Drive ist egal ob Linux oder durch DRAG-Karte ein Übergangsspeicher. Der Vorteil solcher Systeme liegt in Zugriffszeit und Verarbeitungsgeschwindigkeit wie sie etwa für Datenbankserver interessant sein können, entsprechender Speicherausbau vorausgesetzt. Ebenfalls können SWAP Partitionen auf den flüchtigen Speicher ausgelagert werden, auch wenn SWAP eigentlich den Arbeitsspeicher entlasten sollen. (ist ggf. für vServer sinnvoll.) Über Sinn und Unsinn entscheidet nur der jeweilige Anwendungsfall. Der Verweis auf /dev/shm/ ist inhaltlich fragwürdig, da Shared Memory für den Datenaustausch unterschiedlicher Programme zuständig ist und nicht als Laufwerk. Viele Beschreibungen und Darstellungen dieses Artikels sind eher fragwürdig im Kontext ihres Lemmas. (Bsp: Natürlich werden beim Start eines Computers Elemente in den Speicher geladen um schneller Verfügbar zu sein etc. Das ist auch stimmig, hat nur mit RAM-Disks nichts zu tun.) So ist ein RAM-Drive ganz sicher keine Auslagerungsplattform während einer OS-Installation, da die RAM-Disk durch Software keinem Neustart des übersteht. Wobei meine Sicht sich auf Computersysteme beschränkt. Die Andeutungen können sich eher auf Amiga und Commodore beziehen. Dort könnten auch die Ergänzungen und Diskussionspunkte hinpassen. In diesem Falle sollten die Passagen im Artikel aber besser abgegrenzt werden. Ich bin für den Textbaustein Überarbeiten -- Gunnar (💬) 09:42, 13. Jul. 2018 (CEST)

Alles ist kompliziert, nichts ist einfach :-) /dev/shm ist faktisch eine RAM-DISK mit variabler - vom OS verwalteter - Größe. Man kann da alles ablegen und wenn man das denn für sinnvoll hält (isses zumeist nicht) auch Programme dort ablegen. Shared-Memory wird auf *IX-Systemen in einem Layer-System implementiert (mit Abstraktionsschicht). Wenn man Shared-Memory zwischen Programmen nutzen will, dann wird man üblicherweise mittels mmap einen Festplattenbereich in den Speicher einblenden. Wenn mehrere Programme (die passenden Rechte vorausgesetzt) den gleichen Festplattenbereich einblenden, dann hat man einen programmübergreifenden Shared-Kommunikationsbereich. mmap z.B. ist es erstmal vollkommen egal, wo dieser "Festplattenbereich" liegt. Innerhalb eines Programms greift man dann nicht auf eine Festplatte zu, sondern auf Speicher (dafür das mmap (mappe irgend einen Speicher an folgende - virtuelle - Stelle in meinem RAM). Das OS kümmert sich automatisch um die Synchronisierung. Die "Festplatte" ist dann üblicherweise eine Datei auf /dev/shm. Damit hat man einen Shared-Memory-Bereich, der sich in Form einer Datei auf einer RAM-Disk wiederspiegelt. Die Dateisystemebene (auf /dev/shm) ist jedoch eben eine andere Abstraktionsschicht als die mapping-Ebene. Die Zeiten, in denen /dev/shm nur als reines shared-Memory verwendet werden konnte/durfte sind schon seit mehr als 20 Jahren vorbei. --Denalos(quatschen) 10:04, 13. Jul. 2018 (CEST)

Ich habe nicht in Frage gestellt, dass Shared Memory durch die Logik des Systems und unixoiden Systemen addressierbar ist, jedoch hält sich der faktische Nutzen dieses Mount-Punktes als laufwerkswahrgenommene Dateiablage in engen Grenzen. Das mappen wiederum ist ein anderer Prozess, der eine beschleunigte Verarbeitung ermöglicht. Interessant wird das unter anderem wenn man Punkte im Netzlaufwerk mappt. Schnelles Arbeiten, um die Prozesse wie speichern, aktualisieren, hochladen etc. kümmert sich das System. Dennoch ist die Verwendung, bloß weil es geht es nicht unbedingt sinnvoll. -- Gunnar ^💬 20:13, 26. Jul. 2018 (CEST)

Resetfeste RAM-Disks kann es nur bedingt geben. Logisch: passiert ein Reset gerade dann, wenn die Daten vom RAM auf die Festplatte geschrieben werden (aktualisiert werden, weil z.B. eine Datei auf der RAM-Disk verändert wurde), und ist diesre Schreibvorgang unvollständig, dann ist die RAM-Disk als ganzes eben NICHT reset-fest.

Wenn ein System in der Lage ist, den RAM-Inhalt zu behalten, und das Betriebssystem beim Start in der Lage ist, dort fortzufahren, wo es zum Zeitpunkt des Reset war, dann ist die RAM-Disk ebenfalls reset-fest. Aber hat das überhaupt mit der RAM-Disk als solches zu tun?

‣Andreas•⚖ 00:07, 14. Jul. 2018 (CEST)

Wie ich bereits sagte, es gibt zeitweise resetfeste Speicher. Des Weiteren ist der von dir beschriebene Vorgang das Verhalten eines Caches, bzw. einer Anwendung in Ausführung und hat nichts mit einem als Laufwerk und Speicherbereich zugewiesenen Adressbereich im Arbeitsspeicher zu tun. Und wenn man schon diese Beschreibung auf mein Beispiel von Datenbanken anwenden will wäre hier auch noch die Technik der Transaktionen sowie Trigger zu nennen. Die auch bei Festplattencaches Anwendung finden. -- Gunnar ^💬 20:27, 16. Jul. 2018 (CEST)

Das verstehe ich nicht. Wo gibt es resetfesten RAM? Und wie hängt der mit einer RAM-Disk zusammen? Wenn du auf NVRAM anspielst, der ist doch weit nicht so schnell wie DRAM, oder? Und außerdem muss das Betriebssystem, die Firmware oder was auch immer, mit dieser Situation auch umgehen können. Was nützt resetfester RAM, wenn bei einem Neustart des Systems selbiges die dort bereits vorhandene RAM-Disk nicht erkennt, einbindet und weiterverwendet (und auf Konsistenz prüft, ähnlich einem Journaling Filesystem oder zur Gänze)... Denn sonst werden die vorhandenen Daten vom neustartenden Betriebssystem entweder ignoriert (NVRAM mit Daten, die dem System egal sind) oder überschrieben (RAM)...

Bekannt sein dürfte auch, dass bei einem Soft-Reset ansich der Inhalt im DRAM verbleibt. (Artikel z.B. hier, jedoch in Richtung Sicherheit gerichtet.) Das heißt aber nicht, dass das neugestartete Betriebssystem dort weitermachen würde, wo es vorher aufgehört hat (inkl. RAM-Disk).

‣Andreas•⚖ 20:45, 21. Jul. 2018 (CEST)

Ich spiele auf gar nichts an. Wenn ich von NVRAM spreche, nenne ich ihn und es geht hier nicht um Spielecartridges. Ich sagte, es gibt ihn. Deine Frage nach wozu solltest du dir vielleicht selbst beantworten, in dem Moment wo du dir mögliche Anwendungsfälle überlegst. Solche habe ich bereits dargelegt. Wie wäre es wenn du deine Nachfragen erst einmal von Hardware und Software trennst. Für mich ist das Schreibverhalten einer Festplatte mit seinem Cache kein Bestandteil der Thematik RAM-Disk, die Verwendung von NVRAM hat für mich ebenfalls nichts damit zu tun. Auch dass Speichermodule durch einen Neustart (Softreset) formal nicht leer sind sondern lediglich nicht referenziert sind, hat mit der Software-Ebene einer RAM-Disk nicht wirklich etwas zu tun. Die Zuordnung und Referenzierung über Journale ist in meinen Augen der falsche Ring-Level. Konklusion: RAM-Disks Hardware sind quasi SSD uä. ; RAM-Disks in Software sind allgemein flüchtig aber es gibt Sonderfälle. -- Gunnar ^💬 20:13, 26. Jul. 2018 (CEST)

Das ist aber dann keine RAM-Disk mehr. Eine RAM-Disk ist immer im RAM, daher per Design nicht reset-fest.

Reset-festen RAM, also wirklich RAM als Arbeitsspeicher, kenne ich nicht. Ich glaube nicht, dass es soetwas gibt.

‣Andreas•⚖ 22:37, 26. Jul. 2018 (CEST)

Eine resetfeste RAM-Disk kann nur in einer Kombination aus Hardware und OS funktionieren. Die Hardware müsste sicherstellen, dass während des Reset-Vorgangs die Spannungsversorgung des RAMs nicht mal wackelt und das OS bräuchte spezielle Sequenzen zum Erkennen und prüfen dieser RAM-Disk während des Starts.

Es ist also ziemlich viel custom-Kram notwendig.

Da wäre es einfacher, einen Algorithmus in Hardware zu gießen, der im Augenblick eines Master-Fails (aka reset) den Speicher der RAM-Disk auf einen persistenten Datenspeicher schreibt und nach einem erneuten regulären Start lädt das OS die Daten in eine neu erzeugte RAM-Disk zurück. Ich kann mir nicht vorstellen, dass eine echte resetfeste RAM-Disk überhaupt sinnvoll zu realisieren ist. --Denalos(quatschen) 01:15, 27. Jul. 2018 (CEST)

Als morgentlicher Gedankengang dazu: Ich denke, dass eine resetfeste RAM-Disk nicht mal sinn ergibt, bzw. sogar kontraproduktiv ist. Wenn es bei einem Computer einen Reset gibt, dann gibt es dafür üblicherweise einen Grund, der zumeist wohl nicht positiv ist, es gab also ein außergewöhnliches Ereignis. Ein Rset wird mithin durchgeführt, um einen "sauberen" Zustand herzustellen. Da ist es wohl wenig zielführend, wenn man die RAM-Disk - die ja durchaus auch für den unsauberen Gesamtzustand verantwortlich sein kann - über den Neustartvorgang hinweg erhält. Ich denke, dass sowas wie "resetfeste RAM-Disks" eher ein mittlerweile obsoleter Gedankengang sind. Zu Zeiten, als das Starten eines Rechners noch Ewigkeiten dauerte, könnte eine in Hardware realisierte RAM-Disk (die also an sich vollkommen abgekoppelt vom OS arbeitet) den Startvorgang deutlich beschleunigen. Heutzutage ergibt das jedoch keinen Sinn mehr. --Denalos(quatschen) 08:32, 27. Jul. 2018 (CEST)

Ein sinnvolles Beispiel wäre die Zuweisung durch eine DRAG Karte. Dann müsste man sich aber zuvor von der Vorstellung verabschieden, dass eine RAM-Disk immer durch das Betriebssystem erzeugt wird. Es gibt weitreichende Manipulationen, die deutlich von dem Heimcomputer abweicht. -- Gunnar ^💬 18:10, 27. Jul. 2018 (CEST)

Hardware oder nicht Hardware: Ich denke auch, dass man zwischen einer "Hardware-RAM-Disk" und einer "Software-RAM-Disk" unterscheiden müsste. Eine Software-RAM-Disk ist etwas, was vom Betriebssystem in Form von Treibern selbst erzeugt und verwaltet wird. Eine Hardware-RAM-Disk ist ein autonomes Stück Technik, dass abgekoppelt vom OS arbeitet, und sich gegenüber dem OS wie eine "normale" Disk verhält. Beides ist RAM-basierend, mit allen möglichen einhergehenden Problemen, die technologischen Unterschiede sind jedoch gewaltig. --Denalos(quatschen) 08:32, 27. Jul. 2018 (CEST)

Wenn keiner was dagegen hat, dann werde ich die "Resetfeste Ram-Disk" aus dem Artikel entfernen, sowas scheint's im "normalen Umfeld" nicht zu geben und es verwirrt den Leser eher, wenn er von einer Möglichkeit hört die eher akademischer Natur ist. --Denalos(quatschen) 12:29, 27. Jul. 2018 (CEST)

Dem Stimme ich gerne zu. -- Gunnar ^💬 18:10, 27. Jul. 2018 (CEST)

+1. Streichen. --Count² (Diskussion) 18:11, 27. Jul. 2018 (CEST)

+1--Conan (Eine private Nachricht an mich? Bitte hier lang.) 18:28, 27. Jul. 2018 (CEST)

Kann mir bitte jemand zeigen, was eine Reset-feste RAM-Disk sein soll? Ein Link zu so einem Gerät wäre für mich wirklich hilfreich... Außer ihr nehmt auf die Recoverable RAM Disk des Amiga 500 (Workbench 1.3) Bezug – die heißt zwar so, ist aber im Grunde genommen auch nicht reset-fest, allerdings soft-reset-(Warmstart)-fest... was mit einer speziellen Signatur im RAM bewerkstelligt wird, die bei jedem Neustart gefunden und als RAM-Disk erneut eingebunden werden kann. Das ist aber nicht wirklich reset-fest, und abermals in Software. ‣Andreas•⚖ 19:46, 28. Jul. 2018 (CEST)

Ich bin mir mittlerweile ziemlich sicher, dass dieses "es sei denn es ist eine Reset-feste RAM-Disk" einfach so - etwas unüberlegt - in den Artikel "hineingerutscht" ist. Ich denke, dass wir uns alle einig darüber sind, dass es sowas regulär nicht gibt. Eine RAM-Disk ist etwas, was vom OS bereit gestellt wird, und da liegt es schon in der Natur der Sache, dass die nicht Reset-Fest sein kann. Diese RAM-Disk muss unterschieden werden von einer auf RAM basierenden Disk, wie sie von spezieller Hardware - abgekoppelt vom OS - bereitgestellt wird. Blöderweise hat sich im Laufe der Zeit eine Vermischung ergeben, da - vielleicht aus Marketinggründen - die saubere Trennung nicht etabliert wurde. Ich finde es nachvollziehbar, wenn Board-Hersteller bei einem in Hardware gegossenen Feature von einer RAM-Disk sprechen, schlicht, weil sich da viele Leute was drunter vorstellen können. Mit der Tatsache, dass man da faktisch Verwirrung wegen nicht vorhandener Trennung schafft, lebt man dann einfach mal (das ist den Herstellern egal, die wollen halt Umsatz machen). Bei einer solchen Hardware-RAM-Disk halte ich es für absolut machbar, dass die resetfest ist. Die sonstigen Nachteile (potentielle Bit-Kipper) bleiben jedoch.

Ich denke, dass wir diesen Abschnitt hier schließen können, denn das Lemma beschreibt keine Hardware-Lösung, sondern etwas, was vom OS bereitgestellt in Software implementiert ist, und solche RAM-Disks sind nun mal nicht resetfest.

Also, wer setzt den erledigt-Baustein? --Denalos(quatschen) 12:43, 29. Jul. 2018 (CEST)

Nochmal: Was heißt hier "Hardware-RAM-Disk"? Eine in UEFI implementierte RAM-Disk ist ja auch in Software!

Sonst wäre nämlich das ursprüngliche Kickstart-ROM des Amiga auch nicht ein Betriebssystem, sondern Hardware.

Du machst eine Unterscheidung zwischen RAM-Disk und auf RAM basierende Disk. Das kann ich nicht nachvollziehen. Beides ist eine RAM-Disk. Ob vom Betriebssystem oder vom BIOS/UEFI (Firmware) erstellt ist egal. CD-ROM-Boot per "El Torito", oder eben per UEFI-definiertem Standard, muss vom BIOS unterstützt werden, denn das muss diese Art zu Starten zuallerest einleiten können. Beides muss allerdings vom Betriebssystem ebenfalls unterstützt werden. Wenn nämlich nicht, dann startet das OS einfach nicht. Das ist z.B. bei Windows der Fall. DOS ist eine Ausnahme: wenn die BIOS-Handler da sind, ist es DOS egal ob das ein echtes Floppy-Laufwerk ist oder nur ein emuliertes. Windows allerdings – wie alle modernen Betriebssysteme – stützt sich nicht auf die BIOS-bereitgestellten Handler, denn die wären zu langsam und zu simpel. Ein modernes Betriebssystem hat eben den Anspruch, die Hardware besser auszureizen. Nicht umsonst braucht man Grafiktreiber – sonst könnte man die BIOS-Video-Modi oder den UEFI-Framebuffer nutzen, ganz ohne Treiber.

Insofern: NEIN. Das ist schlicht nicht belegbar. Das muss raus. Es gibt nur eine Art von RAM-Disk, und die ist in Software. Wo, in welcher Software, das muss dann beschrieben werden. Und rest-fest ist sie auch nicht. Ein Sonderfall ist die Amiga-RAM-Disk, da sie softreset-fest (Warmstart-fest) ist. Das ist wirklich ein einzigartiges Feature des Amiga, der offenbar den RAM nicht löscht (was nebenbei bemerkt ein Sicherheitsrisiko per Design ist, da man nun nachschauen kann, was der Vornutzer so alles gemacht hat...).

‣Andreas•⚖ 16:48, 29. Jul. 2018 (CEST)

Nachtrag: Wen es interessiert: HPCA17-coldboot.pdf (schon wieder leider Englisch) – Zitat (Seite 1): Such data retention in DRAMs has been shown to be a security risk, as systems that rely on disk encryption and passwords often store sensitive data in DRAM under the assumption that a reboot or removal of the DRAM will destroy the data. However, in 2008, a team of researchers demonstrated that disk encryption keys could be recovered from DDR and DDR2 DRAMs …

In DDR3 und DDR4 sind daher Memory Scrambler eingebaut, die den Inhalt des RAM zufällig würflen, um genau das zu verhindern. Wenn ich also an das Design der Amiga-RAM-Disk denke, so wird schnell klar, dass dies heute, aus Sicherheitsgründen, nicht mehr funktionieren kann.

Sehr interessant ist auch Seite 6 oben, Figure 3: Visual Comparison of DDR3 and DDR4 Scramblers... (Wen's interessiert...) ‣Andreas•⚖ 17:01, 29. Jul. 2018 (CEST)

Ich denke, dass die Hardware-RAM-Disk nur etwas sein kann, was direkt vom BIOS, d.h. vor dem Start des OS zur Verfügung gestellt werden kann. Sofern das OS im Nachgang Zugriff auf diesen RAM-Bereich hat (ich meine nicht den Zugriff via Disk-I/O), ist es keine Hardware-RAM-Disk mehr. Das BIOS müsste also irgend welchen Code enthalten, der in Kombination mit Koomponenten auf dem Board das tatsächlich vorhandene RAM dieser RAM-Disk vom restlichen RAM separiert, so dass dieses RAM für das OS nicht mehr sichtbar ist. Ich weiß nicht, ob es solche Boards gibt. Da ich sowas niemals einsetzen würde, habe ich mich dafür auch nichts interessiert. Jegliche Form von RAM-Disk, die vom BIOS nur via MMU vom OS getrennt wird, wäre gemäß dieser Definition keine Hardware-RAM-Disk, denn die MMU kann ja vom OS beeinflußt werden, und dann hätte das OS Zugriff auf diesen Speicherbereich. --Denalos(quatschen) 22:24, 29. Jul. 2018 (CEST)

Ja, das klingt interessant. Aber wo gibt's sowas?

Aber ehrlich gesagt klingt das alles nach WP:TF. Ja, das könnte es geben... aber ich finde es niergendwo, also gibt es sowas wirklich? Ich denke mal: nein. Wenn, dann vielleicht im Virtualisierungsumfeld, aber dort wird es nicht von einer Firmware (BIOS, UEFI) bereitgestellt, sondern von einem minimalen auf die Aufgabe spezialisierten CoreOS. (Vgl. Xen).

Ebenso verhält es sich mit MEMDISK, hier (englisch). Alles, was über BIOS INT13h auf das RAM-"Laufwerk" zugreift, funktioniert damit. Alles andere braucht einen passenden Treiber...

Wenn es sowas wie eine Hardware-RAM-Disk also nicht gibt, dann sollte es aus dem Artikel entfernt werden. Wenn es sie gibt, dann sollte sich ein Beleg finden lassen.

Also, was darf’s sein?

‣Andreas•⚖ 22:29, 29. Jul. 2018 (CEST)

Der gesperrte Nutzer Huhbuh hat mit einer seiner vielen IP-Edits auf diverse Boards verwiesen, die angeblich solche Features haben. Ob das aber wirklich so ist, oder ob der Nutzer mangels Wissen irgend was fehl interpretiert hat, vermag ich nicht zu sagen. Ich habe derzeit weder Lust noch Zeit, mir die entsprechenden Specs und Details zu besorgen, um mich da einzulesen. Wenn's für sowas keinen nachvollziehbaren Beleg gibt, dann sollte das aus dem Artikel gelöscht werden. --Denalos(quatschen) 22:36, 29. Jul. 2018 (CEST)

Ok, dann lösche ich es raus. Wenn sich ein Beleg findet, kann man es ja gerne wieder dazunehmen, was ich persönlich aber bezweifle... Aber: Man lernt nie aus. Ich würde mich gerne eines Besseren belehren lassen.

P.S. Ich kann keine Anzeichen dafür finden, dass die von der IP erwähnten RAM-Disk-Programme irgendetwas mit der Firmware (BIOS/UEFI) zu tun haben. Es sind einfach Goodies für Käufer dieser Boards. In etwa so wie machmal die AntiVirus-Software, die Käufern diverser Computer beigelegt wird.

‣Andreas•⚖ 22:48, 29. Jul. 2018 (CEST)

ähm leute, als die linux live systeme, ist mir was eingefallen, manche live stick ersteller bieten die option einen Persistence bereich zu erstellen, ich hab das so verstanden, das da die daten gespeichert werden, die man im live linux macht, ist das dann nicht reset fester RAM? Bitte korrigiert mich, wen ich falsch liege.--

Nö. Ein Persistant-Bereich ist eine Partition auf einem R/W-Medium, z.B. einem USB-Stick. ‣Andreas•⚖ 22:37, 29. Jul. 2018 (CEST)

endschuldigung, hiergehört meine frage hin, durch den bk bin ich in die falsche bereich gerutscht. Ich boote mein live linux mit Persistence bereich, installiere wine und fahre das live runter, wen ich es jetzt wieder boote ist wine noch da, ob woll es ja ein live linux ist und ich es neu innstallieren müste.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 22:43, 29. Jul. 2018 (CEST)

Ja, das "persistance"-feature ist normalerweise eine separate Partition auf dem Live-USB-Stick. Wenn du es überprüfen willst, starte mal einen Terminal (Konsole) und poste die Ausgabe von "parted -l"

Eine Persistant Area kann jedoch auch auf einem anderen Medium sein. So kann man einen USB-Stick mit den zu speichernden Daten erstellen (persistance) und der Boot-Vorgang findet von einer CD-ROM (als nur-lesen, read-only) statt. Das funktioniert auch ganz gut.

Mit einer RAM-Disk hat das aber nichts zu tun.

‣Andreas•⚖ 22:54, 29. Jul. 2018 (CEST)

ok, endschuldigung, da hatte ich das falsch versanden..--Conan (Eine private Nachricht an mich? Bitte hier lang.) 22:56, 29. Jul. 2018 (CEST)

Hab gerade diese Anleitung (englisch) zum Ubuntu-Live-USB-Stick gefunden. Es muss nicht eine eigene Partition sein, es kann auch eine Datei sein, die als Loop device eingebunden wird. Dort werden dann die "persistent" Teile, etwa das home-Verzeichnis, gespeichert. Diese Daten bleiben erhalten, weil in diese Datei (oder auf diese Partition) geschrieben werden darf. Der Rest des Live-Systems hingegen wird read-only eingehängt, sodass ein Ändern des Systems grundsätzlich nicht möglich ist. Warum? Weil es so gewünscht ist: per Design. Denn sonst wäre es kein Live-System mehr.

Hier noch eine Anleitung (englisch) für Kali Linux.

‣Andreas•⚖ 23:06, 29. Jul. 2018 (CEST)

boa ey, ich hab doch schon geschrieben, ich lag falsch. EOD von meiner seite.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 23:16, 29. Jul. 2018 (CEST)

Wah?!? Mannomann... das war nicht so gemeint, wie es jetzt offenbar angekommen ist. Anders ausgedrückt: "habe gerade gemerkt, dass da noch was dazu zu sagen ist, dass es da noch eine Ergänzung gibt, von der ich selbst erst jetzt gelesen/erfahren habe" oder so in der Art. Also: Der Vollständigkeit halber. ‣Andreas•⚖ 21:46, 31. Jul. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Denalos(quatschen) 09:08, 1. Aug. 2018 (CEST)