RAM-Disc für Windows?
-
Nobuo T schrieb:
Objection! NTFS hat auch ein journal und steht ext in dieser Hinsicht kaum in etwas nach.
Ach, Du meinst das Metadaten- Journaling? Ja, das hat NTFS, mir war nur neu, daß ext3 auch nicht mehr zu bieten hat.
Ich hab' halt meine Linux- Kisten bevorzugt mit Reiser aufgesetzt, das hat seit V3 Full Journaling.
-
pointercrash() schrieb:
~fricky schrieb:
kann schon sein, dass linux viel festplattenschonender arbeitet. dafür sind bestimmt mehr daten futsch, wenn man 'ner linux-kiste einfach die stromversorgung kappt. windoofs ist ja für ignoranten entwickelt worden, die auch mal gern den schalter an der steckdosenleiste zum runterfahren benutzen.
Wie kommst Du auf den Unsinn?
nur 'ne vermutung. wenn die festplatte seltener rattert, dann tut sich um so mehr im RAM. schaltet man einfach aus, ist das alles weg.
-
pointercrash() schrieb:
~fricky schrieb:
kann schon sein, dass linux viel festplattenschonender arbeitet. dafür sind bestimmt mehr daten futsch, wenn man 'ner linux-kiste einfach die stromversorgung kappt. windoofs ist ja für ignoranten entwickelt worden, die auch mal gern den schalter an der steckdosenleiste zum runterfahren benutzen.
Wie kommst Du auf den Unsinn? Ab Reiser bzw. ext3 handelt es sich um Journaling Filesystems die konsistenzsichernde Maßnahmen betreiben, von denen bei NTFS nichts zu sehen ist.
Mein Fertiger hat so etwa 20 Dumpfspacken am Rechner sitzen, die ihr Win immer wieder mal mit der Steckdosenleiste "herunterfahren", in der Folge war so alle drei Wochen eine Kiste reif für die Wiederherstellung aus dem Image. Seit einem Jahr hat er diese Todesfälle mit 'ner SUSE- DVD wiederbelebt und erheblich weniger Ausfälle.Das ist kein Unsinn. Viele Linux Distros werden immernoch mit unsicheren EXT3 Einstellungen ausgeliefert. Ext3 verlässt sich dann darauf dass Daten auch genau in der Reihenfolge geschrieben werden wie sie an die HDD geschickt werden, und "spart sich" an vielen Stellen explizit die Write-Caches zu flushen.
Das führt zu deutlich schnelleren FS-Operationen, aber leider auch zu viel hübschem Datenverlust.IIRC gibt es auch einige diesbezügliche Probleme mit Software-RAID.
Generell zu behaupten Linux wäre was das angeht sicher ist genauso Unsinn wie generell zu behaupten Linux wäre was das angeht unsicher. Es kommt eben auf die Distro an. Bzw. auf das verwendete FS und die Mount-Optionen.
Wer Windows aufsetzt, und es nicht absichtlich darauf anlegt irgendwas kaputt zu machen ist hier auf der sicheren Seite. Wer ein Linux mit default Einstellungen aufsetzt ohne sich genauer zu informieren, der pokert mit der Sicherheit seiner Daten.
-
Muß mich mal selber zitieren:
pointercrash() schrieb:
Mein Fertiger hat so etwa 20 Dumpfspacken am Rechner sitzen, die ihr Win immer wieder mal mit der Steckdosenleiste "herunterfahren", in der Folge war so alle drei Wochen eine Kiste reif für die Wiederherstellung aus dem Image. Seit einem Jahr hat er diese Todesfälle mit 'ner SUSE- DVD wiederbelebt und erheblich weniger Ausfälle.
Das ist kein Vodoo, sondern pure Beobachtung, wobei ich keine Ahnung habe, ob sein Admin Reiser oder ext3 aufgesetzt hat.
hustbaer schrieb:
Das ist kein Unsinn. Viele Linux Distros werden immernoch mit unsicheren EXT3 Einstellungen ausgeliefert. Ext3 verlässt sich dann darauf dass Daten auch genau in der Reihenfolge geschrieben werden wie sie an die HDD geschickt werden, und "spart sich" an vielen Stellen explizit die Write-Caches zu flushen. ... Wer Windows aufsetzt, und es nicht absichtlich darauf anlegt irgendwas kaputt zu machen ist hier auf der sicheren Seite. Wer ein Linux mit default Einstellungen aufsetzt ohne sich genauer zu informieren, der pokert mit der Sicherheit seiner Daten.
Widerspricht eben o.a. Erfahrungsbericht. Kann noch hinzufügen, daß meine Laborkisten unter Win Stecker ziehen eher übel nehmen, als unter Linux.
Um der ganzen Sache eine praxisrelevante Note zu geben: Mein VMWare Server rennt unter SUSE 10 mit Reiser, der Fileserver unter CentOS 4.2 (RHEL) mit ext3 option "data=journal". Hab' jetzt mal nachgelesen, das sollte sicherstellen, daß auch Daten journalled werden, was eigentlich mehr sein sollte, als was NTFS tut oder überhaupt tun kann. Worauf muß ich jetzt noch achten, damit ich kein "Datenpoker" betreibe?
-
Gibt es eigentlich Steckkarten für den PC wo man seinen alten RAM weiterverwenden kann? Quasi als schnellen Ladespeicher? DDR2 1GB Riegel gibts doch schon für 10 EUR. Haut man sich 8 Stück drauf... schon sollte die Kiste abgehen. Einfach die Auslagerungsdateien und die oft benutzten Programme dort ablegen....
-
pointercrash() schrieb:
Worauf muß ich jetzt noch achten, damit ich kein "Datenpoker" betreibe?
auf ein system, dass die daten nicht minutenlang im cache hält. egal, welche ausgeklügelten selbstheilungsmechanismen ein filesystem auch haben mag; was niemals auf der platte war, lässt sich auch nicht wieder herstellen.
-
------------------ schrieb:
Gibt es eigentlich Steckkarten für den PC wo man seinen alten RAM weiterverwenden kann? Quasi als schnellen Ladespeicher? DDR2 1GB Riegel gibts doch schon für 10 EUR. Haut man sich 8 Stück drauf... schon sollte die Kiste abgehen. Einfach die Auslagerungsdateien und die oft benutzten Programme dort ablegen....
du könntest dir was basteln, das diese speicherbausteine dem pc als festplatte o.ä. vorgaukelt. sowas gibts bestimmt schon irgendwo fertig.
-
pointercrash() schrieb:
Widerspricht eben o.a. Erfahrungsbericht. Kann noch hinzufügen, daß meine Laborkisten unter Win Stecker ziehen eher übel nehmen, als unter Linux.
Welche Windows Version?
Mit 2003 R2 hatte ich so ein Problem noch nie! Mit XP SP2+ auch noch nicht. Davor zugegebenermassen schon. War aber eher die Registry im Arsch als dass das NTFS komplett hinüber gewesen wäre.Hab' jetzt mal nachgelesen, das sollte sicherstellen, daß auch Daten journalled werden, was eigentlich mehr sein sollte, als was NTFS tut oder überhaupt tun kann. Worauf muß ich jetzt noch achten, damit ich kein "Datenpoker" betreibe?
barrier=1
Lies mal da den vorletzten Absatz ("No checksumming in journal"):
http://en.wikipedia.org/wiki/Ext3
-
~fricky schrieb:
pointercrash() schrieb:
Worauf muß ich jetzt noch achten, damit ich kein "Datenpoker" betreibe?
auf ein system, dass die daten nicht minutenlang im cache hält. egal, welche ausgeklügelten selbstheilungsmechanismen ein filesystem auch haben mag; was niemals auf der platte war, lässt sich auch nicht wieder herstellen.
Es geht nicht darum welche Änderung es noch auf die Platte geschafft hat, sondern darum dass das FS nicht korrupt wird. Also dass z.B. nicht einfach Files verschwinden die garnicht offen waren, oder gar das ganze FS nichtmehr gemountet werden kann. Oder lustig anfängt Daten zu vernichten.
-
Was ext3 kann oder nicht kann hat inzwischen wenig(er) Relevanz, da ext4 nun stable ist. Und ext4 hat standardmäßig journal checksumming.
-
hustbaer schrieb:
Welche Windows Version?
Überwiegend W2K, aber die XP- Rechner hat's auch schon ein paar mal zerlegt.
hustbaer schrieb:
War aber eher die Registry im ***** als dass das NTFS komplett hinüber gewesen wäre.
Naja, mit dem Bart PE kriegt man's manchmal wieder hin, ist aber unter Linux auch nicht anders - Totalschaden am Dateisystem hatte ich da noch nie.
hustbaer schrieb:
barrier=1
Heikel. Die Kiste läuft mit einer Uptime von 14 Monaten, aber leider ist beides drauf, wovor der Artikel warnt, daß es zu Unverträglichkeiten kommen könnte: RAID 5 und LVM2.
Wird beim nächsten Server vor "productive" gecheckt. Upps, da kommt ja schon ext4 ...
-
pointercrash() schrieb:
Mein Fertiger hat so etwa 20 Dumpfspacken am Rechner sitzen, die ihr Win immer wieder mal mit der Steckdosenleiste "herunterfahren", in der Folge war so alle drei Wochen eine Kiste reif für die Wiederherstellung aus dem Image.
dann ist doch die naheliegende lösung, die steckdosenleisten mit schalter einzuziehen.
-
Sys-Admin schrieb:
Was ext3 kann oder nicht kann hat inzwischen wenig(er) Relevanz, da ext4 nun stable ist. Und ext4 hat standardmäßig journal checksumming.
1. ext4 ist zu ext3 nicht abwärtskompatibel.
2. Nur weil es nicht mer "EXPERIMENTAL" ist, ist es noch lange nicht stabil.
-
hustbaer schrieb:
~fricky schrieb:
pointercrash() schrieb:
Worauf muß ich jetzt noch achten, damit ich kein "Datenpoker" betreibe?
auf ein system, dass die daten nicht minutenlang im cache hält. egal, welche ausgeklügelten selbstheilungsmechanismen ein filesystem auch haben mag; was niemals auf der platte war, lässt sich auch nicht wieder herstellen.
Es geht nicht darum welche Änderung es noch auf die Platte geschafft hat, sondern darum dass das FS nicht korrupt wird. Also dass z.B. nicht einfach Files verschwinden die garnicht offen waren, oder gar das ganze FS nichtmehr gemountet werden kann. Oder lustig anfängt Daten zu vernichten.
eigentlich alle halbwegs modernen filesystems speichern redundante informationen, machen atomare transaktionen, oder was auch immer, um sich nach 'nem stromausfall o.ä. wieder schnell in einen konsistenten zustand zu versetzen. das ist nicht das ding. massiver datenverlust durch ein angekratztes dateisystem ist heute eher selten, wenn man nicht gerade FAT benutzt.
volkard schrieb:
pointercrash() schrieb:
Mein Fertiger hat so etwa 20 Dumpfspacken am Rechner sitzen, die ihr Win immer wieder mal mit der Steckdosenleiste "herunterfahren", in der Folge war so alle drei Wochen eine Kiste reif für die Wiederherstellung aus dem Image.
dann ist doch die naheliegende lösung, die steckdosenleisten mit schalter einzuziehen.
es liegt wohl weniger an den steckdosen. die 'dumpfbacken' surfen bestimmt gern durch virenverseuchte pornoseiten und installieren irgendwelche games aus zwielichtigen quellen. das macht eine windows-box nicht lange mit.
-
~fricky schrieb:
hustbaer schrieb:
~fricky schrieb:
pointercrash() schrieb:
Worauf muß ich jetzt noch achten, damit ich kein "Datenpoker" betreibe?
auf ein system, dass die daten nicht minutenlang im cache hält. egal, welche ausgeklügelten selbstheilungsmechanismen ein filesystem auch haben mag; was niemals auf der platte war, lässt sich auch nicht wieder herstellen.
Es geht nicht darum welche Änderung es noch auf die Platte geschafft hat, sondern darum dass das FS nicht korrupt wird. Also dass z.B. nicht einfach Files verschwinden die garnicht offen waren, oder gar das ganze FS nichtmehr gemountet werden kann. Oder lustig anfängt Daten zu vernichten.
eigentlich alle halbwegs modernen filesystems speichern redundante informationen, machen atomare transaktionen, oder was auch immer, um sich nach 'nem stromausfall o.ä. wieder schnell in einen konsistenten zustand zu versetzen. das ist nicht das ding.
Das wäre das Ding, wenn es bei allen "halbwegs modernen filesystems" auch korrekt implementiert wäre.
Wenn man einen dicken Server mit hübsch batteriegepuffertem RAID Cache hat, dann ist schnell mal was sicher, was sonst nicht sicher ist. Wenn man dagegen einen normalen PC mit normalen Platten und ohne batteriegepuffertem Irgendwas hat, dann eben nicht.
-
hustbaer schrieb:
Das führt zu deutlich schnelleren FS-Operationen, aber leider auch zu viel hübschem Datenverlust.
Kann theoretisch, ja. Habe das auf vielen, vielen Rechnern in ziemlich langer Praxis allerdings noch nie erlebt. Du schon? Unter welchen Umständen genau?
IIRC gibt es auch einige diesbezügliche Probleme mit Software-RAID.
Wie oben. Und selbst da eher nur ohne USV.
Wer ein Linux mit default Einstellungen aufsetzt ohne sich genauer zu informieren, der pokert mit der Sicherheit seiner Daten.
Sehr gewagte und trollige Behauptung.
-
Wenn man einen dicken Server mit hübsch batteriegepuffertem RAID Cache hat, dann ist schnell mal was sicher, was sonst nicht sicher ist. Wenn man dagegen einen normalen PC mit normalen Platten und ohne batteriegepuffertem Irgendwas hat, dann eben nicht.
Haperts dann am Filesystem oder am writecache ?
-
Knuddlbaer schrieb:
Wenn man einen dicken Server mit hübsch batteriegepuffertem RAID Cache hat, dann ist schnell mal was sicher, was sonst nicht sicher ist. Wenn man dagegen einen normalen PC mit normalen Platten und ohne batteriegepuffertem Irgendwas hat, dann eben nicht.
Haperts dann am Filesystem oder am writecache ?
Naja, Du kannst entweder Barriers aktivieren, oder eben den Write Cache deaktivieren. Normalerweise ist ersteres um Größenordnungen billiger als zweiteres. Wie groß der Performancehit ist, hängt vom FS ab.
-
Knuddlbaer schrieb:
Wenn man einen dicken Server mit hübsch batteriegepuffertem RAID Cache hat, dann ist schnell mal was sicher, was sonst nicht sicher ist. Wenn man dagegen einen normalen PC mit normalen Platten und ohne batteriegepuffertem Irgendwas hat, dann eben nicht.
Haperts dann am Filesystem oder am writecache ?
Es hapert am User.
Wenn das FS mit aktiviertem Write-Cache klarkommt, dann ist alles OK. Wenn nicht, dann geht man ein Risiko ein.Wenn das FS freilich damit beworben wird mit aktiviertem Write-Cache klarzukommen, es aber nicht tut, dann hapert es am FS.
Wenn der Write-Cache vorgibt gepuffert zu sein, und immer brav alles "in order" zu schreiben, es aber nicht ist, dann hapert es am Write-Cache.
Ist doch eigentlich alles ganz logisch, nicht
-
nman schrieb:
hustbaer schrieb:
Das führt zu deutlich schnelleren FS-Operationen, aber leider auch zu viel hübschem Datenverlust.
Kann theoretisch, ja. Habe das auf vielen, vielen Rechnern in ziemlich langer Praxis allerdings noch nie erlebt. Du schon? Unter welchen Umständen genau?
IIRC gibt es auch einige diesbezügliche Probleme mit Software-RAID.
Wie oben. Und selbst da eher nur ohne USV.
Wer ein Linux mit default Einstellungen aufsetzt ohne sich genauer zu informieren, der pokert mit der Sicherheit seiner Daten.
Sehr gewagte und trollige Behauptung.
Hast du beim Autofahren den Gurt an? Ich hab den nämlich noch nie gebraucht. Anlegen tu' ich ihn trotzdem, und wenn ich nur 20m am Parkplatz fahre.
Oder: schützt du Modifikationen an Shared-Memory mit Mutexen, auch wenn's nur 2-3 kleine Integers sind die atomar modifiziert werden müssen? Ich tue es, obwohl man bei 90% der Stellen Monatelange Testläufe machen kann, ohne auch nur einen Fehler zu bekommen.
Und um das nochmal zu einer klaren und einfachen Antwort zusammenzufassen:
Habe das auf vielen, vielen Rechnern in ziemlich langer Praxis allerdings noch nie erlebt.
So what?
----
Ich finde nicht dass es eine gewagte und trollige Behauptung ist. Die Theorie sagt es kann passieren, und es passiert auch. Oft genug. Mal ist es ein Fehler in der Implementierung, mal ein Fehler in der Hardware, mal ein Anwenderfehler. Manchmal hätte man es vermeiden können, manchmal nicht. Manchmal kann es Sinn machen geringere Sicherheit in Kauf zu nehmen, wenn man dafür deutlich mehr Geschwindigkeit bekommt. Bloss sollte man sich darüber im Klaren sein. Daraus ein allgemeines "ist eh egal, passiert ja eh nix" abzuleiten, finde ich aber einfach nur dumm.
