... steht zumindest auf: https://kowabit.de/firefox-verkuerzt-das-leben-einer-ssd/
Überrascht mich nicht. Aber das trifft im Prinzip für jedes Programm zu welches dauernd Daten schreibt. Beim Firefox ist es eben der Cache und die Cookies, beides wird dauernd "beackert". Eigentlich wundert es mich überhaupt dass SSDs funktionieren da man sein System eigentlich gar nicht so perfekt konfigurieren kann dass auf dem Systemvolume nur wenig Schreib- zugriffe stattfinden (die Swap-Datei wäre das Mindeste was es auszulagern gälte).
Taktluhser schrieb: > Eigentlich wundert es mich überhaupt dass SSDs funktionieren > da man sein System eigentlich gar nicht so perfekt > konfigurieren kann dass auf dem Systemvolume nur wenig Schreib- > zugriffe stattfinden (die Swap-Datei wäre das Mindeste was es > auszulagern gälte). seit die SSD sinnvolle größen erreicht haben ( >= 256GB) spielt das alles kaum noch eine Rolle, weil einfach genug Flash-Zellen vorhanden sind. Ich betreibe auch Datenbanken und VMs auf SSDs, selbst nach 3 Jahren bin ich noch sehr weit weg von dem "max-write" vom Hersteller.
Jep, gerade auch unter Windows wird doch praktisch ständig irgendwo auf die Festplatte geschrieben, sei es der Indexer, irgendein Update-Task, Auslagerung irgendwelche Logs... Also ich sehe da die 15 Sekunden von Firefox als relativ harmlos an :-) Zumal ja auch nicht gesagt ist, dass die Daten jedesmal an genau die gleiche Stelle geschrieben werden. Dafür kenne ich aber NTFS zu wenig und hängt sicher auch ab wie es in FF realisiert ist. Aber ich halte es für eher unwahrscheinlich das dadurch die Lebensdauer wirklich merklich verkürzt wird.
Da steht etwas mehr und auch ein Kommentar von Samsung: http://www.spiegel.de/netzwelt/web/ssds-firefox-schreibt-mehrere-gigabyte-pro-tag-a-1114379.html
Markus M. schrieb: > Dafür kenne ich aber NTFS zu wenig > und hängt sicher auch ab wie es in FF realisiert ist. das spielt überhaupt keine Rolle, weil die SSD es selber verteilt. Auch wenn du ständig auf den gleichen Sektor schreibst, wird die SSD es verteilen. > Jep, gerade auch unter Windows wird doch praktisch ständig irgendwo auf > die Festplatte geschrieben, sei es der Indexer, irgendein Update-Task, > Auslagerung irgendwelche Logs... die Frage ist, was davon wirklich an der Platte ankommt. Es gibt ja einen Festplatten Cache.
Das macht nicht nur der Firefox. Das machen vermutlich sehr viele Programme. Und ich könnte mir vorstellen das auch Windows permanent daten verändert und neu schreibt. Auch ich betreibe Datenbanken auf SSDs und bin sehr zufrieden. Die Ausfälle der Festplatten in unseren Servern sind ich nenne es mal Berechenbar geworden. Seit SSD haben wir weniger Spontane Ausfälle. Die SSD's lagern ja die Daten auf unterschiedliche Flashzellen um so das eine ungefähr gleichmäßige Alterung aller Zellen möglich ist. Bei SSD's ist es aber noch wichtiger Raid Systeme aus unterschiedlichen Platten (Hersteller) zu verbinden.
Ja, FileFox ist so was von einem schlechten Dateisystem, boah ey!
Peter II schrieb: > das spielt überhaupt keine Rolle, weil die SSD es selber verteilt. Auch > wenn du ständig auf den gleichen Sektor schreibst, wird die SSD es > verteilen. Dies habe ich schon so oft gehört und es klingt verdammt nach Entschuldigung, Herausreden. Erstens werden die Speicherzellen ja trotzdem verschleissen, zweitens scheint diese Begründung als Rechtfertigung dafür zu dienen überhaupt nichts mehr gegen das ständige Schreiben auf SSD tun zu müssen. Ich durfte schon beobachten wie sich ein SSD-Begeisterter "heimlich" (er wollte es seinen Kritikern nicht sehen lassen) nach recht kurzer Zeit wieder eine neue eingebaut hat - sicherlich nicht weil die alte ihm zu klein geworden ist. Nun wird das alles sehr vom Einzelfall abhängen - ich denke bei solchen Gelegenheiten an den klugen Spruch eines Franzosen: -- your mileage may vary ---
Das ist unter Linux ja alles noch viel schlimmer, weil Linux mit den ganzen Logs noch viel mehr Datenmüll produziert. Der Ausweg ist aber auch längst bekannt aus einem c't-Projekt, dem einseitig abgeklebten Optokoppler. Da muß man das Nulldevice draufmappen. Sollte von der Grundidee her auch für die Firefox-Problematik gehen.
Nop schrieb: > Der Ausweg ist aber auch längst bekannt aus einem c't-Projekt, dem > einseitig abgeklebten Optokoppler. Aprilheft?
Taktluhser schrieb: > Aber das trifft im Prinzip für jedes Programm zu welches > dauernd Daten schreibt. Eben. Also am besten den PC gar nicht mehr einschalten. Obwohl, selbst dann hält so eine SSD nicht ewig. Oliver
Taktluhser schrieb: > Peter II schrieb: >> das spielt überhaupt keine Rolle, weil die SSD es selber verteilt. Auch >> wenn du ständig auf den gleichen Sektor schreibst, wird die SSD es >> verteilen. > > Dies habe ich schon so oft gehört und es klingt verdammt nach > Entschuldigung, Herausreden. > > Erstens werden die Speicherzellen ja trotzdem verschleissen, > zweitens scheint diese Begründung als Rechtfertigung dafür > zu dienen überhaupt nichts mehr gegen das ständige Schreiben > auf SSD tun zu müssen. Naja, was heißt "nichts mehr"? Auf den Festplatten hat das ja nie eine Rolle gespielt. Erst seit SSDs im Einsatz sind, ist das aktuell geworden. Aber es stimmt schon. Ich denke, das Problem ist, dass man SSDs nicht als solche betreibt und die dafür passenden Dateisysteme entwickelt. Stattdessen emuliert eine SSD auf ihrem Controller aufwändig eine Festplatte. Bei den modernen PCIe-SSDs sorgt das dafür, dass die nach kurzer Zeit ihre Geschwindigkeit drosseln müssen, weil der Controller so hoch ausgelastet ist, dass er eine Temperatur von 100 °C erreicht hat.
Sven schrieb: > Das macht nicht nur der Firefox. Das machen vermutlich sehr viele > Programme. Und ich könnte mir vorstellen das auch Windows permanent > daten verändert und neu schreibt. Die Registry ist so ein Kandidat.
Rolf Magnus schrieb: > Bei den modernen PCIe-SSDs sorgt das dafür, dass die nach > kurzer Zeit ihre Geschwindigkeit drosseln müssen, weil der Controller so > hoch ausgelastet ist, dass er eine Temperatur von 100 °C erreicht hat. http://www.golem.de/news/samsung-950-pro-im-test-die-beste-m-2-ssd-fuer-consumer-1510-117008-2.html [...] Bei konstanter Schreiblast mit 128-KByte-Blöcken und einer Warteschlangentiefe mit einem Befehl liefert die 950 Pro für gut drei Minuten rund 900 MByte pro Sekunde. Dann erreicht sie knapp 80 Grad Celsius, die Schreibrate bricht auf 700 MByte pro Sekunde ein. [..] das wird wohl der Grund dafür sein, das Firefox nach 3 Minuten so langsam wird. (99.99% der Anwendung schaffen es überhaupt nicht ihre SSD an das Limit zu bringen)
Jack schrieb: > Die Registry ist so ein Kandidat. .... und jede Menge Dateien die User-bezogen im Verzeichnis "Dokumente und Einstellungen" liegen. Die man - im Gegensatz zur Swap-Datei - auch nicht so einfach auslagern kann.
Nop schrieb: > Das ist unter Linux ja alles noch viel schlimmer, weil Linux mit den > ganzen Logs noch viel mehr Datenmüll produziert. Im Web findet man oft Tipps, wie man bei Linux auf einer SSD die Logs woanders platzieren kann. Für Windows findet man solche Tipps nicht. Das liegt aber nicht an einer hohen Schreibrate in Linux. Sondern weil man es in Linux sehr einfach machen kann, in Windows jedoch nicht. Auch Windows schreibt Logfiles.
Oliver S. schrieb: > Eben. Also am besten den PC gar nicht mehr einschalten. Obwohl, selbst > dann hält so eine SSD nicht ewig. Ganz besonders nicht jene SSDs, die dann nach vielleicht 1-2 Jahren den Inhalt verlieren. Weil der wiederaufgefrischt werden muss.
Taktluhser schrieb: > Die man - im Gegensatz zur Swap-Datei - auch nicht so einfach > auslagern kann. die Swap-Datei sollte auf der SSD liegen. Es wird zu 90% gelesen und 10% geschrieben. Lasst ihr eurer Auto auch zu Hause stehen, damit es sich nicht abnutzt? SSD verkraften jeden tag über 50GB an schreibenden Daten 3 jahre lang. Kein normale Anwender kommt nur ein die nähe davon, das ganze ist doch nur Panik machen.
Peter II schrieb: > die Swap-Datei sollte auf der SSD liegen. > Es wird zu 90% gelesen und 10% geschrieben. Your mileage may vary. Jeder ist seines eigenen Glückes Schmied. .... wenn ich eine so offensichtliche Stelle nicht selbst in die Hand nehme und vermeide was zu vermeiden ist ....
Taktluhser schrieb: > .... wenn ich eine so offensichtliche Stelle nicht selbst > in die Hand nehme und vermeide was zu vermeiden ist .... man fragt sich warum du überhaupt eine SSD einsetzt. Ich mache mir weniger Gedanken und freu mich über einen schnellen PC. Dieser PC läuft seit 3 Jahren (24/7) und darauf laufen 4 VMs mit Windows und alles auf einer SSD.
Taktluhser schrieb: > .... wenn ich eine so offensichtliche Stelle nicht selbst > in die Hand nehme und vermeide was zu vermeiden ist .... eventuell mal andere Zeitschriften lesen.. http://www.pc-magazin.de/ratgeber/ssd-mythen-tipps-wahr-falsch-2945484.html
Peter II schrieb: > man fragt sich warum du überhaupt eine SSD einsetzt. Woher weisst du dass ich das tue? Solid State wurde früher gerne bei den Elektronik-Geräten der Japaner als "Qualitätsmerkmal" eingesetzt. Das hat bei mir Spuren hinterlassen. Nein ich verwende keine SSDs. Es reicht schon wenn im normalen DDR ab und zu ein Bitchen umkippen kann.
Taktluhser schrieb: > Nein ich verwende keine SSDs was glaubst du was in dein Handy steckt.... oder hast du auf Festplatte umgerüstet?
Kingston KC400 in Office PC, 24x7 eingeschaltet, wird zu den üblichen Bürozeiten praktisch durchweg in Win7 genutzt. Die smartmontools verraten:
1 | 9 Power_On_Hours -O--C- 100 100 000 - 4927 (205 Tage) |
2 | 233 Flash_Writes_GiB PO-R-- 100 100 000 - 1495 (1,5 TB) |
3 | 241 Lifetime_Writes_GiB -O--C- 100 100 000 - 1033 (1 TB) |
4 | 242 Lifetime_Reads_GiB -O--C- 100 100 000 - 4425 |
Bei einer offiziellen Lebensdauer von 300 TBW reicht das je nach verwendeter Basis (233 oder 241) für hochgerechnet 100-160 Jahre.
A. K. schrieb: > Bei einer offiziellen Lebensdauer von 300 TBW reicht das je nach > verwendeter Basis (233 oder 241) für hochgerechnet 100-160 Jahre. Dann kann das ja mit dem Firefox nicht so schlimm sein. Peter II schrieb: > was glaubst du was in dein Handy steckt.... Welches Handy?
A. K. schrieb: > Bei einer offiziellen Lebensdauer von 300 TBW reicht das je nach > verwendeter Basis (233 oder 241) für hochgerechnet 100-160 Jahre. dann würde ich sofort alles abschalten was ständig auf der SSD rumschreibt. Wie willst du sonst das System an deine Enkel vererben.
Taktluhser schrieb: > Das hat bei mir Spuren hinterlassen. > > Nein ich verwende keine SSDs. Das verstehe ich. Ich bleibe auch meinem 486er treu. Seit dem Divisionsbug beim Pentium kann mir dieses neumodische Zeug gestohlen bleiben. Und Probleme mit Firefox habe ich daher auch keine. </ironie>
Nop schrieb: > Das ist unter Linux ja alles noch viel schlimmer, weil Linux mit den > ganzen Logs noch viel mehr Datenmüll produziert. Die Systemdisk eines recht gut verwendeten Linux-Produktionsservers verzeichnet während seiner Arbeitszeit statistisch ca. 1 Schreibvorgang pro Sekunde und eine mittlere Schreibrate von 36 KB/s (aus VMware Statistik). Anwendungen und deren Protokolle liegen woanders, das ist also wirklich nur das System und seine Logs.
:
Bearbeitet durch User
A. K. schrieb: > Noch was aus der Praxis. Die Systemdisk eines recht gut verwendeten > Linux-Produktionsservers verzeichnet während seiner Arbeitszeit > statistisch ca. 1 Schreibvorgang pro Sekunde und eine mittlere > Schreibrate von 36 KB/s (aus VMware Statistik). Anwendungen und deren > Protokolle liegen woanders, das ist also wirklich nur das System und > seine Logs. wer hätte das gedacht. Linux wo das System Read-Only gemoutet ist, schreibt sogar 0kb/S auf die Disk. Auch eine Linux-Live-CD schreibt nichts - schon erstaunlich was Linux alles schafft.
entwicklungs-PC, läuft ca 10h/d
1 | 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4336 |
2 | 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 365 |
3 | 177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 7 |
dieser firefox-bug scheint hier nicht einzuschlagen.
Bei mir sind jetzt 2 SSDs(240GB) nach knapp 3 Jahren am Ende ihrer Lebenszeit, eine SSD hat vor einigen Tagen ihren Dienst eingestellt und die Andere hat noch eine Restlebenszeit von 2%. Allerdings hängen/hingen diese als RAID-1 Cache vor einem 12TB RAID-6.
Das war natürlich kein r/o root, sondern das komplette System ohne die Anwendungsdaten, aber mit Systemlogs etc.
Thorsten schrieb: > Allerdings hängen/hingen > diese als RAID-1 Cache vor einem 12TB RAID-6. Das ist freilich ein recht extremer Betrieb. Dafür sind 3 Jahre ok. > die Andere hat noch eine Restlebenszeit von 2% Das offenbart denn auch ein sehr spezifisches Problem einer RAID 1 Konfiguration mit SSDs. Wenn die Dinger durch sind, dann beide praktisch gleichzeitig.
:
Bearbeitet durch User
A. K. schrieb: > Das war natürlich kein r/o root, sondern das komplette System ohne die > Anwendungsdaten, aber mit Systemlogs etc. was hättest du denn da anderes erwartet? Woher hätte denn die Schreibvorgänge kommen sollen?
Peter II schrieb: > was hättest du denn da anderes erwartet? Nein, ich nicht. Das war eine Antwort auf "Nop", und er hat etwas anderes behauptet.
:
Bearbeitet durch User
A. K. schrieb: > Das ist fast die Höchststrafe. Dafür sind 3 Jahre ok. Ich beschwer mich auch nicht. Der Geschwindigkeitszuwachs ist enorm, da nehme ich es gern in Kauf alle 2-3 Jahre die SSDs zu tauschen. Aber es zeigt doch, dass man eine SSD doch in recht kurzer Zeit an ihre Grenzen bekommt, wenn man sie derart ge-/missbraucht.
Thorsten schrieb: > Aber es zeigt doch, dass man eine SSD doch in recht kurzer Zeit an ihre > Grenzen bekommt, wenn man sie derart ge-/missbraucht. Klar. Wer beruflich Videobearbeitung macht, evtl. in unkomprimiertem Rohformat, der bringt das auch schnell zustande. Aber auch dem wird das keine grauen Haare bereiten. Um freilich mit üblicher Firefox-Nutzung eine normale SSD auszulutschen muss man schon recht alt werden.
:
Bearbeitet durch User
...bei Linux (nicht nur auf SSD) würde ich auf jeden Fall die Option "noatime" in der /etc/fstab mit aufnehmen (mache ich sowieso für alle FS immer). Sonst würden die Inodes für oft zugegriffene Files ja relativ oft aktualisiert...
:
Bearbeitet durch User
Markus M. schrieb: > ...bei Linux (nicht nur auf SSD) würde ich auf jeden Fall die Option > "noatime" in der /etc/fstab mit aufnehmen (mache ich sowieso für alle FS > immer). Sonst würden die Inodes für oft zugegriffene Files ja relativ > oft aktualisiert... Manche Linux-Distros verwenden bereits von Haus aus "relatime". Das reduziert solche Updates erheblich, ohne nennenswert an Funktionalität einzubüssen. Bei obigem Linux-Server ist das beispielsweise so eingestellt. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/Relatime.html Ein Pendant zu noatime gibts in Windows ebenfalls. Siehe NtfsDisableLastAccessUpdate.
:
Bearbeitet durch User
Peter II schrieb: > Bei konstanter Schreiblast mit 128-KByte-Blöcken und einer > Warteschlangentiefe mit einem Befehl liefert die 950 Pro für gut drei > Minuten rund 900 MByte pro Sekunde. Dann erreicht sie knapp 80 Grad > Celsius, die Schreibrate bricht auf 700 MByte pro Sekunde ein. In der c't wurde auch mal eine Samsung getestet. Da war das meiner Erinnerung nachher etwas extremer. Aber auch wenn man es schafft, dass der Controller nicht drosseln muss, würde ich es für sinnvoller erachten, in der SSD nicht eine Festplatte zu emulieren.
Rolf Magnus schrieb: > Aber auch wenn man es schafft, dass > der Controller nicht drosseln muss, würde ich es für sinnvoller > erachten, in der SSD nicht eine Festplatte zu emulieren was meinst du damit? kein Blockdevice? Als was soll sie sich denn sonst darstellen?
Peter II schrieb: > was meinst du damit? Dass man ein Dateisystem benutzt, welches sich auf die Gegebenheiten einer SSD anpasst, statt eine SSD sich auf die Gegebenheiten 20 Jahre alter Dateisysteme anpassen zu lassen.
Jörg W. schrieb: > Dass man ein Dateisystem benutzt, welches sich auf die Gegebenheiten > einer SSD anpasst, statt eine SSD sich auf die Gegebenheiten 20 Jahre > alter Dateisysteme anpassen zu lassen. finde ich nicht. Ein BS soll nicht wissen was sich hinter den device steckt. Was ist wenn eine Samsung andere als eine Intel angesprochen werden muss? So etwas sollte man der Firmware überlassen. Nur sie kennt die echte Hardware und deren Eigenschaften. Was ist wenn als nächsten der Magnet-[irgendwas] Speicher kommt, wieder ein neues Dateisystem?
Jörg W. schrieb: > Peter II schrieb: >> was meinst du damit? > > Dass man ein Dateisystem benutzt, welches sich auf die Gegebenheiten > einer SSD anpasst, statt eine SSD sich auf die Gegebenheiten 20 Jahre > alter Dateisysteme anpassen zu lassen. Ja genau. Eine Festplatte kann Sektoren wahlfrei einzeln lesen und überschreiben. Genau so werden sie auch angesteuert, und dafür sind die Dateisysteme ausgelegt. Der Flash-Speicher in den SSDs dagegen kann das nicht. Beim Lesen geht das vielleicht noch, aber geschrieben werden kann nur in erheblich größeren Blöcken, und vor dem Schreiben muss der Inhalt auch erst gelöscht werden. Dazu kommt dann das Thema mit der Abnutzung. Die Controller in den SSDs haben nun ordentlich damit zu tun, diese ganzen Untersdchiede zu verbergen und on the Fly Sektoren umzusortieren, so dass der PC sie immer noch so ansteuern kann, als wäre sie eine Festplatte.
> Dass man ein Dateisystem benutzt, welches sich auf die > Gegebenheiten einer SSD anpasst, Das ist doch längst der Fall! Sowohl Linux (ext3 und ext4) als auch Windows (ntfs) haben Anpassungen speziell für SSD erhalten. Dafür brauchte es in beiden Fällen kein komplett neues Filesystem, sondern nur kleine Änderungen an Details. Der Wear-Levelling Algorithmus gehört meiner Meinung nach ohnehin in die SSD weil er spezifisch auf die verwendeten Speicherchips zugeschnitten sein muss.
Peter II schrieb: > finde ich nicht. Ein BS soll nicht wissen was sich hinter den device > steckt. Naja, manchmal muss man eben die Geräte an neue Technologien anpassen. Als die Disketten kamen, hat man sich auch neue Dateisysteme überlegt, die für Disketten besser geeignet waren, als für die davor verwendeten Datasetten. Und irgendwann haben Grafikkarten, die digital ein Bild erzeugen und LCD-Monitore, die es dann auch digital verarbeiten, auch eine digitale Schnittstelle dazwischen bekommen, weil es irgendwie sinnfrei ist, das dazwischen nach analog und wieder zurück zu wandeln, nur damit man die Schnittstelle nicht ändern muss. > Was ist wenn eine Samsung andere als eine Intel angesprochen werden > muss? Das Prinzip ist doch immer das gleiche. Die Parameter sind vielleicht unterschiedlich, aber die könnte die SSD dem Rechner ja mitteilen. > So etwas sollte man der Firmware überlassen. Nur sie kennt die > echte Hardware und deren Eigenschaften. Könnte man auch machen. Aber dann sollte man dennoch ein paar Eigenschaften, die bei allen SSDs vorhanden sind, gleich auf der Rechnerseite berücksichtigen, statt das immer kunstvoll während der Zugriffe umzukonvertieren. > Was ist wenn als nächsten der Magnet-[irgendwas] Speicher kommt, wieder > ein neues Dateisystem? Wenn das einen Vorteil bringt, warum nicht? Stefan U. schrieb: > Das ist doch längst der Fall! Sowohl Linux (ext3 und ext4) als auch > Windows (ntfs) haben Anpassungen speziell für SSD erhalten. Dafür > brauchte es in beiden Fällen kein komplett neues Filesystem, sondern nur > kleine Änderungen an Details. Das geht meiner Meinung nach noch lange nicht weit genug. > Der Wear-Levelling Algorithmus gehört meiner Meinung nach ohnehin in die > SSD weil er spezifisch auf die verwendeten Speicherchips zugeschnitten > sein muss. Sicher? Ich könnte mir gut vorstellen, dass da einige Parameter vom konkreten Speicher abhängig sind, aber der Algorithmus selber nicht.
Den Browsercache auf einer SSD zu haben bringt meiner Meinung nach einen deutlich gefühlten Geschwindigkeitsschub. Wenn ich es auf eine HDD lege, fühlt sich das Surfen schon merkbar träger an. Die SSD war der größte "Geschwindigkeitsschub" für meinen PC. Da nehme ich es auch in Kauf, dass sie "Verbraucht" wird. Es ist schließlich ein Gebrauchsgegenstand. Wobei ich es noch nicht geschafft habe, eine SSD "totzuschreiben" in einem normalen Internet/Office PC. Vorher wird ehr der Rechner erneuert. Selbst meine alte SSD, ca 4 Jahre alt, lebt noch Auf der SSD habe ich nur das Betriebssystem und die Programme. Meine persönlichen Daten speichere ich weiterhin auf einer HDD, die ich als "Datengrab" im Rechner habe, sowie auf externen USB Festplatten als Backup.
Es gibt längst Filesysteme dafür, wie JFFS2, LogFS, UBIFS, YAFFS, F2FS. Android verwendete früher yaffs, wechselte dann aber auf ext4. Manche neueren verwenden angeblich f2fs - mir begegnete das mal in custom Firmware. Ein Problem dabei: Die normalen Linux-Filesysteme werden schneller besser als die speziell an Flash angepassten. So ist es nicht ratsam, auf einem 8-Core Gerät ein Filesystem zu verwenden, dass ein globales Lock verwendet, wenn ein viel besser granular lockendes Universal-Filesystem zur Verfügung steht. Da mit eMMCs sowieso Flash mit Wear Levelling zur Verfügung steht, scheint es am Ende performanter zu sein, effizente Universal-Filesysteme mit Wear Levelling zu verwenden als speziell an Flash angepasste.
Sven schrieb: > Den Browsercache auf einer SSD zu haben bringt meiner Meinung nach einen > deutlich gefühlten Geschwindigkeitsschub. Ihn ganz rauszuwerfen auch. ;-)
A.K dauert das Cache Lookup länger als das erneute Herunterladen der Datei?
Die Verwaltung von hundertausend kleiner Files wird durch eine SSD zwar schneller, ist aber hinderlich. Und spätestens beim Backup bremst das mehr aus, als es jemals eingespart hat. Die Komponenten von Webseiten sind sowieso weit überwiegend non-cachable. Und der Kram der aktiven Seiten ist im RAM-Teil vom Cache. Es geht nur um den Disk-Teil des Caches.
:
Bearbeitet durch User
Peter II schrieb: > Ein BS soll nicht wissen was sich hinter den device steckt. Dann hättest du die bisherigen Dateisysteme auch ablehnen müssen. Die waren/sind nämlich auf klassische Festplatten optimiert (Minimierung von Kopfbewegungen). OK, wenn man mal von FAT absieht, das war einfach nur pessimiert … Dass man tatsächlich hardwarespezifische Dinge innerhalb des jeweiligen Lowlevel-Controllers vornimmt, ist natürlich auch klar.
Da hier speziell vom Firefox gesprochen wird.. Hier wird für Linux beschrieben, wie man das in den RAM auslagern kann. https://wiki.ubuntuusers.de/Firefox/Tipps/#Verlagerung-des-Browser-Caches Das gilt aber prinzipiell für viele Dateien bei Linux, welche man in den RAM auslagern kann.. Je nach Geschmack :)
Rolf Magnus schrieb: >> Was ist wenn als nächsten der Magnet-[irgendwas] Speicher kommt, wieder >> ein neues Dateisystem? > > Wenn das einen Vorteil bringt, warum nicht? du sieht vermutlich nur ein paar Windows und Linux Kisten. SSD kommen auch ein Raid Systemen vor. diesen müssten auch angepasst werden. Dann gibt es Datenbanken die direkt auf RAW devices schreiben die müssten auch angepasst werden. alten Windows Versionen bekomme eh kein neues Dateisystem. Ich sehe es als viel einfacher wenn die SSD so tut als ob sie eine Festplatte das schränkt ihre Verwendung dann nicht ein. Die Optimierungen die eventuell für alte Festplatten vorgenommen wurden stören zumindest bei einer SSD nicht, von der Seite sehe ich keine Nachteile. Die Firmware kann scheinbar mit über 1200Mbyte/s umgehen für die Verteilung der Daten auf die Sektoren, was soll also ein neues Dateisystem für Vorteile bringen? Wenn das Dateisystem auf die SSD angepasst ist, und es neu formatiert wird dann gehen die Infos verloren welchen Sektor wie oft schon überschrieben wurde? `
Peter II schrieb: > Wenn das Dateisystem auf die SSD angepasst ist, und es neu formatiert > wird dann gehen die Infos verloren welchen Sektor wie oft schon > überschrieben wurde? Nein, weil diese Info unterhalb des Dateisystems seitens der SSD gespeichert wird - die weiß nämlich selber am besten, was sie gemacht hat. SSDs haben keine Sektoren, sie tun ja nur so als ob.
A. K. schrieb: > Es gibt längst Filesysteme dafür, wie JFFS2, LogFS, UBIFS, YAFFS, F2FS. > Android verwendete früher yaffs, wechselte dann aber auf ext4. Manche > neueren verwenden angeblich f2fs - mir begegnete das mal in custom > Firmware. > > Ein Problem dabei: Die normalen Linux-Filesysteme werden schneller > besser als die speziell an Flash angepassten. MMhh, das verwirrt mich etwas. F2FS ist doch speziell für flash-basierte Massenspeicher. Samsung hat es genau deswegen entwickelt. Ansonsten finde ich es witzig vom vielen Logging von Linux zu sprechen. Windows loggt auch alles mögliche, der Anwender sieht es nur nicht (so einfach).
Jetzt mal ne ganz dumme Frage: Wie kommt man auf solche Datenmengen? Ich meine 35 GB Pro Tag, das sind auf die angegebenen 15 Sekunden runtergebrochen noch über 6 MB = 6.000.000 Byte! Selbst bei ewig langen Adressen, nehmen wir die Größe die die meisten Server maximal erlauben, sagen wir von 8192 Zeichen, müssten da dauerhaft über 24h noch über 700 Tabs geöffnet sein, jeder mit einer so langen Adresse. Ich glaube solche Datenmengen kriegt man kaum zusammen, wenn man jede 15 Sekunden alle geöffneten Webseiten komplett auf dem PC abspeichert, zumal man ja auch nicht 24/7 am surfen ist. Klärt mich auf.
Gerd schrieb: > Selbst bei ewig langen Adressen, nehmen wir die > Größe die die meisten Server maximal erlauben, > sagen wir von 8192 Zeichen, müssten da dauerhaft > über 24h noch über 700 Tabs geöffnet sein, jeder mit > einer so langen Adresse. Das Problem ist nicht die Adresse, sondern a) die Art der Datenspeicherung: In einer JSON-Datei. Diese muss jedes mal komplett neu geschrieben werden. Das ist also nicht wie der normale Seitencache, wo nur neue Inhalte neu geschrieben werden müssen weil jeder Seitenteil (Bilder, js, etc.) in seiner eigenen Datei landet. b) die Zusatzinformationen: Es wird nicht nur gespeichert, auf welcher Adresse du gerade unterwegs bist, sondern auch einige Metadaten: Referrer, Charset, welche Zeile(n) du gerade im Bildschirm hast etc. damit die Sitzung exakt so wiederhergestellt werden kann, wie vor dem Crash. Du kannst dir die Datei gern mal im Texteditor ansehen, JSON ist "menschenlesbar". Es geht entweder um eine "sessionstore.json" oder um den Inhalt des "sessionstore-backups" Verzeichnisses im Firefox-Profil. Bei mir ist eine session so ca. 150kiB, das sind so ca. 20 Tabs mit statischem Inhalt (ohne große Bilder, ohne Werbung...) die sich quasi nie ändern. Diese 150kiB aller 15s zu schreiben summiert sich, zumal der sessionstore in mehreren Versionen auf der Platte liegt (mindestens noch 1x *.bak-Datei). Außerdem speichern Mozilla-Browser noch relativ viel je Seite/URL in SQLITE-Dateien ab (history, cookies, Zoomstufe, Seitenberechtigungen...) was auch nicht besonders schreibeffizient ist, die Dateien werden beim Update / erneuten Indizieren zu großen Teilen neu geschrieben. Die places.sqlite alleine ist 10+MiB, zuzüglich write-ahead-log. Das ist aber nicht direkt Bestandteil des geschilderten Problems, da ging es ja nur um den sessionstore - trägt aber unzweifelhaft dazu bei. Dadurch, dass relativ viele Dateien involviert sind, die auch gern mal geändert werden gibt es auch einen nicht unerheblichen Mehraufwand durch das Dateisystem: Berechtigungen, Zeitstempel etc. Dafür kann Firefox zwar nichts, aber auch das erhöht das Schreibvolumen.
Cablecar schrieb: > ... steht zumindest auf Hi, interessant aber warum spekulieren, guck doch mal nach z. B. Linux? (Habe aber eh keine SSD an diesem Compi) $lsof -c firefox-bin |grep -reg | awk 'NR==1 || $4~/[0-9][uw]/' schon hast du eine Liste der zum schreiben und lesen+schreiben von firefox geoeffneten regulaeren Dateien. Aktuell hier 16 offene Dateien die meisten davon sqlite. Man koennte das in Teilen aber auch komplett in ein tmpfs im Hauptspeicher verfrachten. https://www.verot.net/firefox_tmpfs.htm mal gucken wieviel Platz das derzeit beansprucht, root@xxxx:$du -chs /home/xxxx/.mozilla/firefox/xxxxxx.default/ 116M total wenige hundert MB sollten sich doch heutzutage leicht vom Hauptspeicher abzwacken lassen, spaetestens dann sollte das keine nennenswerte Auswirkungen mehr haben. Dann weiters unabhaengig vom verwendeten nixoidem FS in ein tmpfs /tmp /var/run /var/lock /var/log /var/tmp /usr/tmp ausser evtl /log kann das ohne zurueckzuschreiben beim runterfahren ohne Probleme geloescht werden. Bei KDE quillt es froehlich unter /var/tmp/kdecache-xxxxx Benutze gelegentlich eine Live-Distro, Slax vom USB-Stick Kleine 1Gb Partition eingerichtet, nach dem alle Pakete Programme Tools eingerichtet waren blieben so 200MB frei, nichts damit gemacht ausser eine Woche lang gesurft schwupps war er weg der freie Platz, wobei heute nat. Speicherplatz eigentlich kaum noch eine Rolle, jdf. keine dominante, spielt. ggf. ~/.adobe, ~/.macromedia halten ~/.thumbnails weg damit --- Unter Windows pruefen was los ist? handles.exe evtl. openfiles.exe Oder gefenstert mit resmon, cpu -> assoc. handles Einen SSD Killer sehe ich da aber irgendwie erstmal nicht.
xxxxxx.default schrieb: > $lsof -c firefox-bin |grep -reg | awk 'NR==1 || $4~/[0-9][uw]/' Oups, so gehts $lsof -c firefox-bin |grep -i reg | awk 'NR==1 || $4~/[0-9][uw]/'
hink schrieb: > MMhh, das verwirrt mich etwas. F2FS ist doch speziell für flash-basierte > Massenspeicher. Das sollte keine Disqualifizierung von f2fs sein. Es ist nur einfach so, dass in generischen Lösungen auf Dauer oft mehr Erfahrung und auch Optimierung steckt als in spezifischen Lösungen für spezielle Probleme. Die Weiterentwicklung ist aktiver und wird von mehr Leuten betrieben. Das von Android früher verwendete yaffs2 ist ein Beispiel dafür. Es wurde von der Entwicklung der Systeme und des Kernels überholt, so dass es in Android letztlich von ext4 abgelöst wurde.
:
Bearbeitet durch User
A. K. schrieb: > es in Android letztlich von ext4 abgelöst wurde. Das liegt dann aber eher an so etwas wie Verbreitungsgrad, Robust- o. Fehlerfreiheit des Code, ... Ext4 braucht wenigsten vier schreibzugriffe pro Datei, FAT32 zwei, f2fs und nilfs2 begnuegen sich mit einem. SD(HC)-Karten, zu SSDs weiss ich leider nichts, koennen je nach Controller auf 4 bis 24 Stellen gleichzeitig zugreifen. ---- Das war jdf. mal einem Vortrag aus 2015 zu entnehmen. www.nicta.com.au/pub-download/slides/8311/ Das PDF findet sich noch, die Seite von Peter Chubb bei nicta ist aber weg.
Rolf Magnus schrieb: > Jörg W. schrieb: >> Peter II schrieb: >>> was meinst du damit? >> >> Dass man ein Dateisystem benutzt, welches sich auf die Gegebenheiten >> einer SSD anpasst, statt eine SSD sich auf die Gegebenheiten 20 Jahre >> alter Dateisysteme anpassen zu lassen. > > Ja genau. Eine Festplatte kann Sektoren wahlfrei einzeln lesen und > überschreiben. Genau so werden sie auch angesteuert, und dafür sind die > Dateisysteme ausgelegt. Das muss nicht mehr unbedingt der Fall sein. Stichwort: Advanced Format und 512e. Moderne Festplatten arbeiten mit 4096 Byte großen Sektoren, aus Kompatibilitätsgründen gibt es 512e (e = emulation) d.h. das OS/BIOS/Whatever liest wie eh und je 512 Bytes, die HD liest allerdings 4096 Bytes und liefert die passenden 512 zurück. Beim Schreiben ist Read-Modify-Write angesagt (Block lesen, passende Stelle überschreiben und dann den ganzen 4 kiB-Sektor wieder zurückschreiben)
A. K. schrieb: > Nop schrieb: >> Das ist unter Linux ja alles noch viel schlimmer, weil Linux mit den >> ganzen Logs noch viel mehr Datenmüll produziert. > > Im Web findet man oft Tipps, wie man bei Linux auf einer SSD die Logs > woanders platzieren kann. Für Windows findet man solche Tipps nicht. Es gibt genug tipps wie man WIN für SSD optimal einstellt. https://www.thomas-krenn.com/de/wiki/Windows_f%C3%BCr_SSDs_optimieren Logfiles verschieben ist zwar nicht darunter, vielleicht kann man durch regelmäßiges Löschen derselben die so klein halten das der Schreib-cache die Logs vor der SSD "abfängt. Wobei Logfile-updaten i.d. Regel kein volles Schreiben sondern ein Anhängen (Append) ist. Also der Grossteil des Logfiles bleibt unverändert und wird bei cleveren SSD-Managment auch nicht neugeschrieben, sondern nur der Block mit den neuen Daten. Dann sollte "Log-kleinhalten" auch keinen grossen Nutzen bringen. Die im Artikel genannte Menge von mehrenen Gigabytes pro Tag firefox-Müll ist IMHO schon exorbitant hoch, das per Logdatei zu erreichen dürfte schwierig werden.
xxxxxx.default schrieb: > Das liegt dann aber eher an so etwas wie Verbreitungsgrad, Robust- o. > Fehlerfreiheit des Code, ... Manche Filesysteme leiden unter Performanceproblemen bei Multitasking, ganz besonders auf Multicore-CPUs, weil deren Filesystem-Aktivitäten von einem einzigen globalen Kernel-Lock abgesichert werden. Das führt beispielsweise zu dem berühmten Ruckeln. Auf f2fs wird das wohl nicht zutreffen, aber es erklärt, weshalb yaffs2 vom viel granularer arbeitenden ext4 abgelöst wurde.
:
Bearbeitet durch User
Arc N. schrieb: > Das muss nicht mehr unbedingt der Fall sein. Stichwort: Advanced Format > und 512e. Oder das "shingled magnetic recording" einiger derzeitiger HDDs hoher Kapazität. Da werden beim Schreiben die Nachbartracks mit beeinflusst. Was zu interessanten Methoden bei wahlfreiem Schreiben von Blöcken führt, denn das geht nicht direkt. Im Grunde bräuchte man dafür auch wieder ein speziell optimiertes Filesystem.
:
Bearbeitet durch User
Arc N. schrieb: > Das muss nicht mehr unbedingt der Fall sein. Stichwort: Advanced Format > und 512e. Moderne Festplatten arbeiten mit 4096 Byte großen Sektoren, > aus Kompatibilitätsgründen gibt es 512e (e = emulation) d.h. das > OS/BIOS/Whatever liest wie eh und je 512 Bytes, die HD liest allerdings > 4096 Bytes und liefert die passenden 512 zurück. Beim Schreiben ist > Read-Modify-Write angesagt (Block lesen, passende Stelle überschreiben > und dann den ganzen 4 kiB-Sektor wieder zurückschreiben) da aber die meisten Dateisystem eh mit 4k Clustern arbeiten, ist das wieder egal. Es darf nur kein Versatz gehen, daran kümmern sich aber seit jahren schon Fdisk & CO.
Arc N. schrieb: > Das muss nicht mehr unbedingt der Fall sein. Stichwort: Advanced Format > und 512e. Moderne Festplatten arbeiten mit 4096 Byte großen Sektoren, > aus Kompatibilitätsgründen gibt es 512e (e = emulation) d.h. das > OS/BIOS/Whatever liest wie eh und je 512 Bytes, die HD liest allerdings > 4096 Bytes und liefert die passenden 512 zurück. Beim Schreiben ist > Read-Modify-Write angesagt (Block lesen, passende Stelle überschreiben > und dann den ganzen 4 kiB-Sektor wieder zurückschreiben) Aber auch nur früher, und wenn's ganz schlecht läuft. Außerdem teilen die Festplatten dem Rechner nicht nur die emulierte, sondern auch die tatsächliche interne Blockgröße zurück. Leider gab es in der Vergangenheit da Festplatten, die einen Bug hatten und für letzteres 512 Bytes genannt haben, obwohl sie intern 4k-Sektoren hatten. Die Dateisysteme arbeiten in der Regel aber sowieso auch mit 4k-Blöcken. Das einzig wichtige ist ein passendes Alignment, was leider bei klassischer DOS-Partitionstabelle per Default nicht gegeben ist, da die erste Partition aus irgendeinem Grund standardmäßig bei Sektor 63 anfängt. Diese Emulations-Geschichte ist aber auch nur für veraltete Systeme nötig, die nicht darauf ausgelegt sind, auch mit anderen Sektorgrößen als 512 umgehen zu können. Es gibt auch Festplatten, die diese Emulation nicht machen, trotz 4k-Sektoren. Die Betreibssysteme wurden eben einfach daran angepasst. A. K. schrieb: > Oder das "shingled magnetic recording" einiger derzeitiger HDDs hoher > Kapazität. Da werden beim Schreiben die Nachbartracks mit beeinflusst. > Was zu interessanten Methoden bei wahlfreiem Schreiben von Blöcken > führt, denn das geht nicht direkt. Ist aber vom Verhalten eigentlich ähnlich dem, was bei den SSDs passiert. Da kommt man nur trotzdem damit klar, weil der Flash-Speicher so schnell ist, dass mit einem entsprechend leistungsfähigen Controller die dafür nötige on-the-fly-Umsortierung immer noch performant ist. > Im Grunde bräuchte man dafür auch wieder ein speziell optimiertes > Filesystem. Aktuell werden die ja wegen dieser Einschränkungen nicht für die allgemeine Verwendung empfohlen, sondern eher für Archivierung und generell Aufgaben, wo nur selten geschrieben wird. Das ließe sich mit einem passenden Filesystem bestimmt erheblich verbessern.
Bei den SSDs ist es ja so dass die Unternehmen immer weiter versuchen pro Zelle mehr Bits zu speichern. Ursprünglich war es so: SLC-Speicher = eine Zelle = 1 Bit / 100k Schreibzyklen MLC-Speicher = eine Zelle = 2 Bit / 10k Schreibzyklen TLC-Speicher = eine Zelle = 4 Bit / 1k Schreibzyklen Es ist zwar so dass das Wearleveling im Moment etwas besser optimiert worden ist, so dass es weniger wahrscheinlich ist dass eine Zelle zu oft beschrieben wird, aber trotzdem hölt eine Zelle heutzutage ein hundertstel so lange. Eine 256GByte SSD kann also im Idealfall mit einem Schreibvolumen von 256TByte aufwarten. Das Problem bei diesen Multi-Level-Zellen ist eben dass sie ihre Daten mit der Zeit verlieren können, also sollte die SSD möglichst immer an einer Spannungsversorgung hängen damit die Zellen ab und zu aufgefrischt werden. zum Thema ... Einträge in "about:config" des Firefox-Browsers um die Schreibtätigkeit auf die SSD/Festplatte zu verringern: network.prefetch-next;false browser.sessionstore.interval;86400000 browser.sessionstore.max_resumed_crashes;0 browser.sessionstore.restore_on_demand;false browser.sessionstore.resume_from_crash;false services.sync.prefs.sync.browser.sessionstore.restore_on_demand;false browser.cache.disk.parent_directory;/tmp browser.cache.memory.enable;true Habt ihr noch ein paar bessere Einstellung die ihr in eurem Firefox einstellt?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.