Forum: PC Hard- und Software Firefox verkürzt das Leben einer SSD.


von Cablecar (Gast)


Lesenswert?


von Taktluhser (Gast)


Lesenswert?

Ü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).

von Peter II (Gast)


Lesenswert?

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.

von Markus M. (adrock)


Lesenswert?

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.

von test (Gast)


Lesenswert?


von Peter II (Gast)


Lesenswert?

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.

von Sven (Gast)


Lesenswert?

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.

von Dateimänädtscher (Gast)


Lesenswert?

Ja, FileFox ist so was von einem schlechten Dateisystem, boah ey!

von Taktluhser (Gast)


Lesenswert?

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 ---

von Nop (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nop schrieb:
> Der Ausweg ist aber auch längst bekannt aus einem c't-Projekt, dem
> einseitig abgeklebten Optokoppler.

Aprilheft?

von Nop (Gast)


Lesenswert?

Jörg W. schrieb:
> Aprilheft?

Ja klar. :-)

von Oliver S. (oliverso)


Lesenswert?

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

von Rolf Magnus (Gast)


Lesenswert?

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.

von Jack (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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)

von Taktluhser (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von Taktluhser (Gast)


Lesenswert?

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 ....

von Peter II (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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

von Taktluhser (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

Taktluhser schrieb:
> Nein ich verwende keine SSDs

was glaubst du was in dein Handy steckt.... oder hast du auf Festplatte 
umgerüstet?

von (prx) A. K. (prx)


Lesenswert?

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.

von Taktluhser (Gast)


Lesenswert?

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?

von Peter II (Gast)


Lesenswert?

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.

von Jan H. (j_hansen)


Lesenswert?

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>

von (prx) A. K. (prx)


Lesenswert?

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
von Peter II (Gast)


Lesenswert?

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.

von c.m. (Gast)


Lesenswert?

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.

von Thorsten (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Das war natürlich kein r/o root, sondern das komplette System ohne die 
Anwendungsdaten, aber mit Systemlogs etc.

von (prx) A. K. (prx)


Lesenswert?

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
von Peter II (Gast)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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
von Thorsten (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Markus M. (adrock)


Lesenswert?

...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
von (prx) A. K. (prx)


Lesenswert?

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
von Rolf Magnus (Gast)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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?

von Rolf Magnus (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

> 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.

von Rolf Magnus (Gast)


Lesenswert?

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.

von Sven (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Sven schrieb:
> Den Browsercache auf einer SSD zu haben bringt meiner Meinung nach einen
> deutlich gefühlten Geschwindigkeitsschub.

Ihn ganz rauszuwerfen auch. ;-)

von Sven (Gast)


Lesenswert?

A.K dauert das Cache Lookup länger als das erneute Herunterladen der 
Datei?

von (prx) A. K. (prx)


Lesenswert?

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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Blubb (Gast)


Lesenswert?

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 :)

von Peter II (Gast)


Lesenswert?

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?
`

von Nop (Gast)


Lesenswert?

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.

von hink (Gast)


Lesenswert?

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

von Gerd (Gast)


Lesenswert?

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.

von LOL (Gast)


Lesenswert?

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.

von xxxxxx.default (Gast)


Lesenswert?

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.

von xxxxxx.default (Gast)


Lesenswert?

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]/'

von (prx) A. K. (prx)


Lesenswert?

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
von xxxxxx.default (Gast)


Lesenswert?

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.

von Arc N. (arc)


Lesenswert?

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)

von Checker (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Peter II (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Mike J. (linuxmint_user)


Lesenswert?

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
Noch kein Account? Hier anmelden.