mikrocontroller.net

Forum: PC Hard- und Software SSDs defragmentieren, macht das Sinn?


Autor: Mirsen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir zu Weihnachten mal den Luxus SSD gegönnt.
Jetzt habe ich alles installiert, die Karre läuft so wie sie soll und 
nun quält mich eine Frage:

Macht es eigentlich noch einen Sinn SSDs zu defragmentieren?
Durch die "Interne Fragmentierung" und die sehr strammen Zugriffszeiten 
könnte das doch eher nachteilig sein weil ich eh nur die endlichen 
Schreibzyklen pro Speicherzelle verbrate.

Oder mach ich da gerade einen Denkfehler?

Autor: Andi ... (xaos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BLOS NICHT !!! das ist das schlimmste, was du den dinger antun 
kannst...nimm eine die trim unterstützt und gut

Autor: Klugscheißer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mal zur Erklärung:
eine Festplatte ist eine drehende Scheibe wo ein einzelner Lesekopf die 
Dateien abruft - wie eine Schallplatte. Wenn eine Datei nun fragmentiert 
ist, muss der Lesekopf für diese eine Datei an verschiedene Stellen 
springen um die Datei vollständig lesen zu können.

Eine SSD hat keine mechanisch bewegbaren Teile, also auch keinen 
Lesekopf - da gibt es nur Speicheradressen hinter dennen die Teile der 
Datei abgelegt sind. Ähnlich wie beim RAM.
Ob die Speicheradressen dieser einen Datei nun aufeinanderfolgend oder 
willkürlich verteilt sind spielt keine Rolle, jede Speicherzelle ist 
einfach nur ein einzelner Lese- bzw. Schreibbefehlt

Ein defragmentieren hätte zur Folge dass du unnötig Schreibbefehle auf 
die SSD gibts (und zwar ganz schön viele!!)
Dieses unnötige beschreiben verringert die Lebensdauer deiner SSD, den 
eine SSD ist ein "Verschleißteil" und hat nur eine begrenzete Anzahl an 
Schreibvorgängen je Speicheradresse bevor sie defekt ist! Genau gleich 
wie beim USB-Stick.

Autor: Mirsen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klugscheißer:
Danke für den langen Text der sicher vielen Leuten eine Hilfe ist 
(Wirklich sehr verständlich geschrieben, Respekt!)

Aber ich behaupte einfach mal das ich "etwas" mehr Ahnung von HW habe 
als die meißten anderen Menschen, mir ging es nur darum mich nochmal zu 
vergewissern ob ich nicht doch evtl. einen Denkfehler drinnen hatte. 
(Man weiß ja nie).
Aber du und auch dein Vorposter haben es mir bestätigt, damit wäre die 
Waffel dann gegessen und der Fred kann geschlossen werden.

Und vielen dank nochmal an die schnellsten Antworten die ich je in einem
Forum gesehen habe!

Autor: Mirsen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andi D.
hab mir die "billigere" X18-M 80Gb gekauft, die kann zwar trim aber ich 
kann jetzt auch die schnelle nicht ergurgeln ob XP i386 SP3 das 
unterstützt?
Kannst du mir das schnell beantworten?
Wenn nicht dann gurgel ich weiter.....

Danke

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
XP kann offenbar nicht. Aber da es nichts gibt, für das nicht irgendwer 
einen Hack gefunden hat, geht es eben irgendwie doch. Offenbar spaziert 
dann ein Daemon durch das Filesystem und TRIMt alle freien Blöcke:
http://www.myce.com/news/ocz-first-to-introduce-tr...

Autor: Markus Gräb (ghost91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit eine SSD auch länger hält, defragmntiert sich sogar die Festplatte 
selber. Sie versucht möglichst über den ganzen Flash die Daten so zu 
verteilen, dass jede Flashzelle gleichviel genutzt wird.

Autor: Mirsen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das klingt ja seeehr interessant, mal abwarten wann irgendwer das tool 
für die Intels "umbastelt" oder Intel mal selber auf den Trichter 
kommt.....

Autor: Mirsen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus Gräb:
Das ist ja in Fachkreisen bekannt, nur wie effektiv die Firmware dabei 
ist steht auf einem anderen Blatt.....

Autor: Gäst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist erschreckend, dass selbst in einem Elektronikforen solche Fragen 
gestellt werden. Wo doch spätestens nach 3 Sekunden googeln und 
Hirnbenutzen klar ist, dass man SSDs nicht defragmentieren soll. Es ist 
schon schlimm genug, irgendwelche Geräte zu kaufen ohne sich vorher über 
ihre Eigenschaften, Features, Vorteile und Mängel informiert zu haben.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch, die soll man defragmentieren. Das ist gut für die Wirschaft.

Autor: bla bla bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja für die asiatische... ;)

Autor: klugscheißer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gäst schrieb:
>Es ist erschreckend, dass selbst in einem Elektronikforen solche
>Fragen gestellt werden.

Wo soll man sie sonst stellen? im Radio bei Alexander Borell!?

Ach ne ich hab ne Idee: Wir löschen alle Foren im internet und setzen 
die DNS konsequent auf google! - noch besser: wir verbrennen alle Bücher 
und ersetzen sie durch Googleausdrucke!

Es kotzt mich wirklich an wenn in jedem Forum irgendwer dahergesch...en 
kommt und meint auf google verweisen zu müssen!
Hast du für google einen Schrein zuhause eingerichtet - betest du 
täglich zu google!?

Jetzt fehlt nur noch dass du sagst, mit Linux hätte man dieses Problem 
nicht!

...soviel kann ich garnicht fresse wie ich kotzen möchte wenn ich sowas 
lese!

Autor: Mirsen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@klugscheißer:
Ich danke dir, besser hätte ich es auch nicht formulieren können! :-)

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Defragmentieren verursacht doch nur einen einzigen Schreibzugriff je 
Zelle. Bei 100.000-facher garantierter Wiederbescheibbarkeit sollte das 
also kein Problem sein.

Autor: Bitte einen Namen eingeben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Es ist erschreckend, dass selbst in einem Elektronikforen solche
>>Fragen gestellt werden.

>Wo soll man sie sonst stellen?

Google und eigenes Hirn benutzen hätte genügt und wäre schneller 
gegangen als hier eine Frage zu formulieren und die Antworten 
abzuwarten. Wenn in allen Foren die gleichen Fragen gestellt werden, 
weil die Fragesteller zu dumm oder zu faul zum denken sind, sind bald 
die meisten Foren nicht mehr lesbar, weil mit Müll zugemüllt. Es hat 
auch etwas mit gutem Benehmen zu tun, erst mal eine Suchmaschine und 
sein Hirn zu benutzen und sich erst mal selber zu bemühen bevor man 
ein Forum belästigt. Will man dann noch tiefer in Materie einsteigen und 
fragt spezielles, gibt es sicher niemand, der sich über die 
Fragestellung aufregt.

Autor: Sense (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klugscheißer schrieb:
> Es kotzt mich wirklich an wenn in jedem Forum irgendwer dahergesch...en
> kommt und meint auf google verweisen zu müssen!

Ich schlage vor, alle Fragen, die durch Google (oder eine andere 
Suchmaschine) in wenigen Sekunden beantwortet werden können, 
grundsätzlich nicht zu beantworten und den Thread schnellstmöglich zu 
löschen.

Sowas Dummdreistes wie Dich hab ich echt lange nicht mehr erlebt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Helmert schrieb:

> das Defragmentieren verursacht doch nur einen einzigen Schreibzugriff je
> Zelle. Bei 100.000-facher garantierter Wiederbescheibbarkeit sollte das
> also kein Problem sein.

Einem NTFS Defragger habe ich mal bei der Arbeit zugesehen. Während 
DOS/FAT Defragger am Filesystem vorbei optimierten und damit auch 
zusammenpackten, analysierte dieser NTFS Defragger lediglich die 
bestehende Fragmentierung der Files und kopierte zu sehr fragmentierte 
solange mit normalen Betriebssystemmechanismen in der Landschaft herum, 
bis entweder das Ziel oder eine Grenze erreicht war. Da NTFS bei 
vorneweg gegebener Filegrösse ganz gut alloziert funktioniert das 
leidlich. Aber nicht selten sind vor allem bei grossen Files etliche 
Anläufe drin.

Dazu kommt, dass jede solche Aktion aus Konsistenzgründen synchron 
arbeiten muss. Alle Veränderungem am Filesystem, wie frei/belegte 
Blöcke, Filenodes, Dir-Einträge usw. werden ebenfalls mit jeder solchen 
Aktion geschrieben, manches pro Aktion mehrfach.

Ohne TRIM Funktion führt das insbesondere bei Defragging von grossen 
Files (z.B. Disk-Images aus Virtualisierung) noch dazu, dass aus Sicht 
der SSD das Filesystem stärker belegt erscheint als es tatsächlich ist. 
Das Wear-Levelling also mehr Arbeit hat als nötig, denn der von der SSD 
als frei bekannte Bereich ist dafür sehr wichtig.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich schlage vor, alle Fragen, die durch Google (oder eine andere
> Suchmaschine) in wenigen Sekunden beantwortet werden können,
> grundsätzlich nicht zu beantworten und den Thread schnellstmöglich zu
> löschen.

Das wäre mal ein guter Vorschlag.

Im Hausfrauen- oder Technikanalphabetenforum könnte man obige Frage ja 
noch tolerieren. Aber doch nicht in einem Elektronikforum wo man einen 
gewissen mindest-IQ samt einigem technischen Basiswissen voraussetzen 
sollte.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bisher nicht erwähnt: das wear levelling soll ja die Zugriffe 
gleichmässig über die ganze Kapazität verteilen, man kann also auch 
sagen, wear levelling fraktioniert absichtlich. Ein Defrag-Programm 
dagegen versucht alles am Anfang der Platte zu sammeln. Ich bin der 
Meinung, dass Defrag nicht nur wegen des Zugriffs ohne bewegliche Teile 
nichts nützt, sondern sogar massiv dadurch schadet, dass das wear 
levelling konterkariert wird.

Gruss Reinhard

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>sagen, wear levelling fraktioniert absichtlich. Ein Defrag-Programm

Fragmentiert.

>dagegen versucht alles am Anfang der Platte zu sammeln. Ich bin der
>Meinung, dass Defrag nicht nur wegen des Zugriffs ohne bewegliche Teile
>nichts nützt,

Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn 
man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus 
verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch 
langsamer.

> sondern sogar massiv dadurch schadet, dass das wear
>levelling konterkariert wird.

Nun ja, das ist halt so ein legacy Problem. Die normale Software weiss 
nix von wear leveling und kann damit bisweilen ziemlich dazwischen 
funken.
Ideal wäre ein von grund auf geschlossen entwickeltes Filesystem, 
welches direkt auf die speziellen Anforderungen von FLASH ausgelegt 
wäre. Ist aber aus Kompatibilitätsgründen so nicht machbar. Aber ich 
meine, die bestehenden Lösungen sind schon recht gut. Und sie werden 
besser.

MfG
Falk

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleines wikipediazitat zum Thema gefällig:


Eine Defragmentierung ist aufgrund der marginalen Lese-Zugriffszeiten 
nicht nötig. In Bezug auf die Schreibleistung differieren die 
Herstellerangaben jedoch. So warnt OCZ die Nutzer seiner MLC-basierten 
Core-Serie vor dem Defragmentieren,[35] während MTron für seine 
SLC-basierten Produkte ein Defragmentieren sogar empfiehlt.[36]

Autor: blah (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kleines wikipediazitat zum Thema gefällig:

Wir können hier hoffentlich alle selber Wikipedia lesen!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Winfried J. schrieb:

> Eine Defragmentierung ist aufgrund der marginalen Lese-Zugriffszeiten
> nicht nötig. In Bezug auf die Schreibleistung differieren die
> Herstellerangaben jedoch. So warnt OCZ die Nutzer seiner MLC-basierten
> Core-Serie vor dem Defragmentieren,[35] während MTron für seine
> SLC-basierten Produkte ein Defragmentieren sogar empfiehlt.[36]

Das passt schon. Je nachdem was das Ziel der Defrag ist. Defrag nutzt 
ab, aber die Scheibleistung steigt. Da das Thema Abnutzung bei SLC Flash 
um den Faktor 10 weniger relevant ist lassen sich diese Aussagen mühelos 
in Einklang bringen.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nebenbei bleibt noch die Frage der thermischen Punktbelastung bei 
Volllast, die wahrscheinlich sehr vom konkreten Aufbau abhängt.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn
> man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus
> verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch
> langsamer.

Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die 
Adressierung zwischen den Blöcken geht keine Zeit verloren - es ist also 
egal, ob es der folgende Block ist oder einer am anderen Ende. 
Jedenfalls behaupte ich das jetzt mal so. Also Antworten bitte mit 
nachvollziehbarer Quellenangabe, sonst können Falk und ich ja würfeln.

Gruss Reinhard

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:

> Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die
> Adressierung zwischen den Blöcken geht keine Zeit verloren

Das ist der Punkt wo ich mir nicht sicher bin. Es könnte schon einen 
Unterschied machen, ob für den gleichen Job einer oder 5 Blöcke 
angefasst werden müssen. Nur ist das verglichen mit einer Festplatte 
Klagen auf ziemlich hohem Niveau.

Autor: klugscheißer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wobei eine definierte Größe der Datei auch eine definierte Anzahl an 
Blöcken belegt.
wenn eine datei 1024 Bytes groß ist, und eine Zuodnungseinheit 256 Bytes 
hat, dann benötigt man eben 4 Speicheradresse. Ob die jetzt 
aufeinanderfolgen oder wild verteilt sind, spielt keine Rolle! - Beim 
LESEN!!!

Beim schreiben sieht es anders aus: wenn die Adresse aufeinanderfolgend 
sind, reicht es eine Seite im Flash zu löschen, eine stark fragmentierte 
Platte dagegen müsste in obrigen Fall 4 Seiten Löschen bevor geschrieben 
werden kann - und ich denke hier wäre dann ein enormer 
Geschwindigkeitsverlust.

So stelle ich mir das jedenfalls vor, korrigiert mich bitte wenn das 
nicht stimmt!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klugscheißer schrieb:

> wenn eine datei 1024 Bytes groß ist, und eine Zuodnungseinheit 256 Bytes
> hat, dann benötigt man eben 4 Speicheradresse. Ob die jetzt
> aufeinanderfolgen oder wild verteilt sind, spielt keine Rolle!

Die beiden Samsung SLC,MLC NAND-Flashes, deren Datasheet sich bei mir 
auf der Platte befinden, haben 2KB Blöcke. Intel SSDs verwenden 10 
parallele Kanäle, was demzufolge auf einen effektive Pagegrösse von 20KB 
rausläuft. Wenn das Filesystem die üblichen 4KB Blöcke verwendet, dann 
macht es möglicherweise schon einen Unterschied, ob pro 20KB Lesevorgang 
5 Flash-Pages beansprucht werden, oder nur eine.

Dazu kommt, dass die SSDs den Flash-Speicher nicht direkt und linear 
adressieren können, weil das Wear-Levelling ein gewisses Mass an 
Verwaltung, an Blockmapping mit sich bringt. Je kleiner der einzelne 
Request, desto grösser ist der Verwaltungsaufwand.

Das gleiche gilt insbesondere für das Betriebssystem, auch da ist neben 
der Transferrate die Anzahl Requests ein bedeutender Faktor in der 
I/O-Performance. Bei eher kleinen Requestgrössen (untere 2stellige KB) 
ist die Gesamtperformance erfahrungsgemäss hauptsächlich von der Anzahl 
Requests abhängig, weniger vom Datenvolumen.

Folglich kann ein sequentieller Lesezugriff auf eine stark fragmentierte 
Datei durch die notwendige Verteilung auf etliche kleine Requests sehr 
wohl deutlich abgebremst werden.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Falk Brunner schrieb:
>> Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn
>> man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus
>> verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch
>> langsamer.
>
> Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die
> Adressierung zwischen den Blöcken geht keine Zeit verloren - es ist also
> egal, ob es der folgende Block ist oder einer am anderen Ende.
> Jedenfalls behaupte ich das jetzt mal so. Also Antworten bitte mit
> nachvollziehbarer Quellenangabe, sonst können Falk und ich ja würfeln.
>
> Gruss Reinhard



Hängt vom verwendeten Flash ab und wie der Controller und der restliche 
Aufbau sind...
Bsp.:
Numonyx, Hynix oder Toshiba (die anderen Hersteller können ihren Kram 
behalten, wenn sie Datenblättern nur noch mit NDAs rausrücken)
SLC large/medium
http://hynix.com/datasheet/pdf/flash/HY27UK08BGFM%...
http://numonyx.com/Documents/Datasheets/NAND04G-B2...
http://www.semicon.toshiba.co.jp/docs/datasheet/en...

Normaler Read:
- Address setup / command : 7 Bytes a 25/50 ns
- Busy (Datentransfer Speicher -> interner Cache): 25000 ns
- Datentransfer zum Controller: n * 25/50 ns

Cache-Read:
- Address setup / Command : 7 Bytes a 25/50 ns
- Busy: 25000 ns
- Datentransfer erste Page zum Controller n * 25/50 ns
- Busy: <3000 ns - 30000 ns
- Datentransfer zweite Page ...

Der Unterschied ist je nach Typ deutlich...

Ähnliche Optimierungen gibt es auch beim Schreiben

Autor: 1337 Speak (vollnoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äääähhhhh, Leute.....
Ich habe damals den Fred eröffnet (bin nun registrierter User)

Ich habe doch bloß eine kleine simple Frage gestellt weil (es tut mir 
echt leid gefragt zu haben wenn ich sehe was hier abgeht.)
Ich habe die Frage gestellt damit sich Menschen die (mit dieser neuen 
Technologie) mehr Erfahrung haben wie ich mir meine Frage beantworten da 
ich bisher verschiedene Statements gehört habe (Viele halt nur von 
vollpfosten die nur Compterbild und PCGH kennen).

Es tut mir nochmals vielmals leid eine Frage gestellt zu haben, wusste 
nicht das das heutzutage unhöflich ist und sich Menschen die es nicht 
nötig haben zu antworten sich dadurch beleidigt/angegriffen fühlen.
Ich werde es in Zukunft anstreben dumm zu sterben.....

Autor: Klugscheißer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieso?
ist doch jetzt eigentlich eine ganz sachliche und informative 
Diskussion!?
das mit dem cache-read war mir jetzt auch neu!

Autor: 1337 Speak (vollnoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ist doch jetzt eigentlich eine ganz sachliche und informative
>Diskussion!?

Echt?
K!
Dann muss ich mich noch an den Umgangston hier gewöhnen ^^
Aber dann zieht euch warm an! :-)

Autor: -Gast- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Jetzt fehlt nur noch dass du sagst, mit Linux hätte man dieses Problem
> nicht!

Gibt es bei Linux überhaupt Software zur Defragmentierung? Ich dachte, 
das macht dort der jeweilige Treiber für das Dateisystem selber.

Autor: 1337 Speak (vollnoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja Linux verwendet ein anderes Dateisystem.
In der regel ext2 oder ext3, neuerdings ext4.

Ich habe mal gehört (das bedeutet das ich es nicht 100%ig sicher weiß)
das diese dateisysteme für Fragmentierung nicht so anfällig sein sollen 
wie Fat, Fat32 oder NTFS.

Berichtigt mich bitte wenn ich falsch liege.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.