|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Andere Systeme > kann mann Festplatten leiser tunen? | [ - Search - New posts - Register - Login - ] |
| 1 2 3 4 -5- 6 7 | [ - Post reply - ] |
|
2008-12-12, 11:00 h rbn Posts: 2001 User |
@Holger: > Warum willst Du genau das, was eben noch eine besondere Belastung darstellen sollte, jetzt plötzlich ausschließen? Wo genau tue ich das bitte? > Dass die Torrents keine höhere Schreibbelastung darstellen, hast Du offenbar schon eingehen, ... Ja, hab ich das? Wo? > ... weil Du sie jetzt sogar schon aus Deiner Betrachtung ausschließen willst. Seit wann will ich das wo? Wäre es nicht einfacher gewesen mir auf meine Frage zu antworten? Samtliche andere Streamingtätigkeiten laufen über Caches ab, die unter anderen auf der Festplatte liegen können. Also wird dabei auch schreibend auf das Medium zugegriffen. Und nochmal ein typischer Torrent-Fall von gerade gestern: ca 250 kB/s Download, ca 30 kB/s Upload. Und jetzt verrat mir bitte einfach endlich, warum in aller Welt das keine massig beschriebenen Zellen verursachen soll, gerade in dem Zusammenhang mit dem von dir beschriebenen Blockgrößen bei aktuellen Filesystemen? Ohne Sparse File zu arbeiten hat auch wenig damit zu tun, unbedingt die Festplatte quälen zu wollen, sondern ganz einfach mehr gleichzeitig herunterladen zu können. Fertige Torrents ohne Peers oder mit einer Verbreitungsrate über 1.0 werden natürlich gelöscht und die Daten entfernt. Die enthaltenen Daten sind bis zu diesem Zeitpunkt schon lange in Backup DVDs gesichert und liegen nur in seltenen Fällen noch entpackt auf der Festplatte. Mit Sparse Files wäre es nicht möglich so viele Torrents gleichzeitig zu bearbeiten. rbn -- Marketing. Modern. Mittelständisch. http://www.rhein-sieg-design.de [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 11:49 h Palgucker Posts: 1342 User |
@ rbnZitat: Das kann ich mir irgendwie nicht vorstellen, da bei Torrents es eigentlich der praktikabelste Weg ist, von vornherein eine Datei in "Orginalgröße" zu erstellen, um dann die einkommenden Teile durch verändern der Schreibposition innerhalb der Datei an die richtige Position zu schreiben. Ist aber nur nebenbei...  Gruß Palgucker [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 12:05 h Andreas_Wolf Posts: 2980 User |
>> die aus der Herstelleraussage errechneten garantierten 2300 >> Schreibzugriffe pro Zelle > Ist die Anzahl der Schreibzugriffe von den Herstellern tatsächlich > ernst gemeint [...]? --- Das ist ja garnichts ... Wenn das tatsächlich > die zugesicherte Anzahl der Schreibzugriffe sein soll, dann erübrigt > sich eigentlich jede weitere Diskussion über den Praxiseinsatz von > SSDs für normalen Desktopbetrieb. Ich habe nichts weiter getan, als Majas Angaben über Intels Aussagen auf die damit garantierte Anzahl von Schreibzyklen pro Zelle umzurechnen: Zitat: "Intel verspricht, ein 80 GB X25-M könne 5 Jahre lang täglich mit 100 GB pro Tag beschrieben werden." Und da kommt man nun mal rein mathematisch nur auf exakt versprochene (= zugesicherte) 2281,25 Schreibzugriffe pro Zelle. Ob das ernst gemeint ist, müsstest du -- vorausgesetzt Majas Angaben über Intels Aussagen sind korrekt -- schon Intel selbst fragen. [ Dieser Beitrag wurde von Andreas_Wolf am 12.12.2008 um 12:20 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 12:45 h MaikG Posts: 5172 User |
Zum Glück hab ich kein Intel, ich glaub mal nicht das die Angabe stimmt. >Eine Zelle ist nicht ein Bit. Doch 1 Flash FET kann 1 Bit speichern. Bei NAND Flash sind mehrere dieser hinterinandergeschaltet, die dann nur in einer Gruppe beschrieben werden können. Zwar hat man immer mindestens 1 Byte/FS min 512+ zu schreiben aber ich denke das ist was Maja meint. Wenn du also 1000000 Dateien schreibst hast du mehr Block overhead und mehr Schreibzugriffe auf dem Index Blog(=mehr MBs die tatsächlich geschrieben werden oberhalb der wahrgenommenen/angezeigten MBs). Da die verteilt werden ist das nicht so schlimm aber die Abnutzung ist halt höher als bei 10 Dateien. Ähnliches passiert auch bei Festplatten. http://de.wikipedia.org/wiki/Flash-Speicher [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 16:35 h rbn Posts: 2001 User |
Zitat: Das ist zweifelsohne richtig und entsprach auch meinem logischen Verständnis. µTorrent bietet aber die Option an, den Speicher auf dem Speichermedium erst dann zu allokieren, wenn der Bedarf dafür auch tatsächlich anfällt. Ich habe es dann gleich mal ausprobiert, und der freie (und der belegte natürlich auch) Platz auf dem Medium wird dann wirklich immer soviel kleiner, wie gerade herunter geladen worden ist. Als ich Torrent noch unter Linux gemacht hatte (AFAIR mit dem Originalclient), war es tatsächlich so, dass direkt der gesamte benötigte Speicher allokiert und für den Rest des Systems gesperrt wurde - also "belegt" wurde. Unter MorphOS war es AFAIR nicht anders. Die Rödelei auf der Festplatte wurde dadurch übrigens nicht schlimmer. Ist aber auch klar, weil ob der Schreib-/Lesekopf nun in einem als frei gekennzeichneten Bereich Daten ablegt oder einen zuvor "genullten" Bereich mit Daten füllt ist ja letztlich egal. Mir fällt dazu eigentlich nur ein, dass im Gegenteil MIT Sparsefile (zumindest wenn der Bereich genullt wird) mehr Zugriffe stattfinden müssen. Einmal um das File im Inhaltsverzeichnis einzutragen und dann je nachdem noch mal ne ganze Ecke Zugriffe, wenn der Bereich auch noch genullt werden sollte. rbn -- Marketing. Modern. Mittelständisch. http://www.rhein-sieg-design.de [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 16:36 h rbn Posts: 2001 User |
Zitat: Schade, ich dachte (hoffte) du wüßtest es selbst genau. rbn -- Marketing. Modern. Mittelständisch. http://www.rhein-sieg-design.de [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 16:44 h _PAB_ Posts: 3016 User |
Ich denke, bei meinem "neuen Amiga" kommt eine SSD rein, der wird sowieso nicht oft für Schreibzugriffe benutzt werden, sondern eher als Musik- und Filmserver sowie zum Internet (Cache im RAM) und online-TV schauen benutzt werden. Ansich würde ich auch gerne eine SSD in mein Notebook reintun, schon wegen den 0dB Geräuschpegel und dem sehr viel geringeren Stromverbrauch, bin aber im Moment noch etwas skeptisch, was Ausdauer der SSDs angeht, auch wenn die pure Geschwindigkeit ja sehr vielversprechend ist. MTBF scheint bei aktuellen SSDs ja schon über die von "normalen" Festplatten hinauszureichen. [ Dieser Beitrag wurde von _PAB_ am 12.12.2008 um 16:45 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 17:54 h Maja Posts: 15429 User |
Zitat: Ich halte daraus mal fest: Eine Datein benötigt immer mehr als eine Speicherzelle. Zitat:Dachte ich mir wenigstens. Aber wie groß ist so eine Zelle denn nun genau? Wie viele Blocks pro Zelle? Oder ist eine Zelle weniger als ein Block? Zitat:Wear Levelling verteilt die Schreibzugriffe möglichst gleichmäßig auf alle Speicherzellen. Das erhöht aber nicht die Zahl der maximal möglichen Schreibzugriffe einer SSD, denn die gilt nicht für jede einzelne Speicherzelle, sondern für das gesamte Laufwerk, das aus mehreren Speicherchips mit jeweils einer bestimmten Kapazität an Schreibzugriffen verfügt. Diese Chips können SLC (100.000) oder MLC (10.000) sein. Wear Levelling verhindert somit den frühzeitigen Ausfall einzelner Zellen. Nicht mehr, nicht weniger. @all Noch bin ich davon überzeugt, dass zusätzlich zum reinen Datenvolumen auch die Anzahl der Dateien ein relevanter Faktor bei der Brechnung von Schreibzugriffe / Zeiteinheit ist. Umso mehr nach Holgers Ausführungen zum Thema Blockgrößen im obigen Zitat, was mir nicht unbekannt ist und schlussendlich erst zu der Annahme bringt, dass die Anzahl der Dateien mit der Anzahl der Schreibzugriffe identisch ist. Wenn das falsch ist, dann wäre es nett, wenn einer der wissenden Dummkopfrufer hier sich dazu herab lassen könnte, "Schreibzugriff Anfang" und "Schreibzugriff Ende" auch mal laienverständlich zu erklären. Denn bisher stelle ich nur fest, dass mir ein Haufen teils auch nur rhetorischer Fragen gestellt und ich angegriffen werde weil ich etwas falsch vertanden zu haben scheine, mir aber niemand von denen, die mir ein falsches Verständnis der Sache bescheinigen wollen, die Sache mal erklärt. Wollt oder könnt ihr nicht? [ Dieser Beitrag wurde von Maja am 12.12.2008 um 17:56 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 18:08 h _PAB_ Posts: 3016 User |
Hier gibt es einen sehr guten Artikel: http://www.mactechnews.de/journals/journal.html?id=223 Wer ihn noch nicht gelesen hat, sollte das mal tun - viel Hintergrundwissen. [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 19:01 h Holger Posts: 8116 User |
Zitat:Sparsefiles werden nicht genullt. Das ist doch genau das, worum es dabei geht. Übrigens unterstützt das Windows-API auch beim sequentiellen Schreiben, die zu erwartende Dateigröße mit anzugeben, um Defragmentierung bei vielen gleichzeitig geschriebenen Dateien zu vermeiden. Beides kann auch die Anzahl der Schreibzugriffe reduzieren, wenn eine Datenmenge geschrieben wird, die kein ganzzahliges Vielfache der Blockgröße ist, da das Dateisystem dann weiß, ob es sich lohnt, auf weitere Daten zu warten. Zitat:Auch schreibend. Was sagt uns das? Aber gehen wir noch mal ein Stück zurück zu dem, was Du vorher geschrieben hast: Zitat:Wo um alles in der Welt, soll da Caching auf der Platte sinnvoll sein?! Und selbst wenn: ein geschriebener Cache-Inhalt wird auch wieder gelesen (im Gegensatz zu Deinen torrents...), das heißt wieder ein Lesevorgang, während dem kein torrent gespeichert werden kann. Zitat:Weil jede Datei nur einmal geschrieben wird, egal wie groß die Blöcke sind? Zitat:Gut, wenn Du Dateien unbesehen löscht, erzeugst Du tatsächlich Traffic in der Größenordnung einer Vollbelastung. Allerdings schreibst Du selbst, dass Du sie auf DVD archivierst. Daraus folgt: Bleibt nur noch eines: wieso soll man mit Sparse Files weniger Torrents gleichzeitig bearbeiten können? Du wirst natürlich bei einer nahezu vollen Festplatte wieder genauso viel Fragmentierung wie ohne Sparse-Files erhalten, aber sonst? Aber falls Du die ganze Zeit auf die 100GB pro Tag hinauswillst, von denen irgendwo mal gesprochen wurde: ich glaube gerne, dass Du mehr Daten pro Tag speicherst (auch wenn ich das keineswegs für normal halte). Aber darum ging es eigentlich gar nicht, da Flash-Speichermedien schon deutlich mehr verkraften. Bei dem c't-Test mit echtem Dauerbeschreiben (mehr Belastung als selbst Dein Nutzungsverhalten) dürften wesentlich mehr Daten geschrieben worden sein. Und eine 100 Mal größere SSD kann auch bei zehnmal höherer Datentransferrate zehnmal länger durchhalten... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 19:01 h Begeisterter_Amiga_User Posts: 665 User |
dennoch sollte nicht vergessen werden das ne ssd im grunde nix anderes is als ne größere und intern zu verbauende variante eines usb sticks und einem usb stick würd ich net unbedingt meine backupdaten anvertrauen ... dafür is die technik noch net reif genug. MFG -- if ($GLOBALS['FORUM']->forumuser->mitglied['ahnung'] == 0) { $this->besserKlappeHalten / nachDenken= 1;} Inside Windows-Kernel: if(everything_is_ok==1) { crash(); } [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 19:20 h Holger Posts: 8116 User |
Zitat:Im Normalfall deutlich mehr. Zitat:Ob eine Datei tausend oder zehntausend Speicherzellen belegt, ist vollkommen unerheblich. Jede dieser Speicherzellen wird bei einem Schreibvorgang exakt einmal beschrieben. Und ob Du eine Datei, die eine Million Zellen belegt, oder zehn Dateien, die hunderttausend Zellen belegen, oder hunderttausend Dateien, die zehn Zellen belegen, beschreibst, hat unterm Strich ungefähr den gleichen Effekt: Eine Million Zellen werden exakt einmal beschrieben. Nachtrag: Bitte um Entschuldigung, weil ich die direkte Frage nicht direkt beantwortet habe: Eine Zelle dürfte im Normalfall kleiner als ein Block, maximal gleich groß sein. Also höchstens 4096 Bits pro Zelle. Zitat:SLC oder MLC bezeichnet die Anzahl Bits pro Zelle (Single Level Cell oder (Multi Level Cell) Technologisch unterschieden wird zwischen NOR-Flash (10.000-100.000 Löschzyklen) und NAND-Flash(1.000.000 Löschzyklen) So wird ein Schuh draus. Zitat:Jeder hier hat den Begriff Zelle im Sinne einer Einheit, die nur zusammen beschrieben, bzw. gelöscht werden kann, benutzt. Zitat:Genau darum geht es ja: auch Schreibzugriffe in die Metadaten des Dateisystems werden durch Wear Levelling auf unterschiedliche Zellen verteilt. Und: auch diese Schreibzugriffe werden durch die maximale Transferrate des verwendeten Bus-Systems und des Kontroller begrenzt, können nicht mehr Belastung als ein Dauerbeschreiben in einem anderen Schema erzeugen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 12.12.2008 um 19:33 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 19:25 h Holger Posts: 8116 User |
Zitat:Hier geht es ja nicht um Backup-Daten, sondern um einen Festplattenersatz für den Alltagseinsatz. Allerdings gibt es derzeit kein Medium (für Normaluser), dass wirklich zuverlässig auf Jahrzehnte speichert. Solche Daten sollte man immer regelmäßig umkopieren, bzw. auf mehrere Datenträger streuen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 19:33 h Begeisterter_Amiga_User Posts: 665 User |
Zitat: dem kann ich wiedersprechen --> Bild: http://upload.wikimedia.org/wikipedia/commons/c/ce/Egypt_Hieroglyphe2.jpg diese art der datenspeicherung hat mitlerweilen tausende jahre gehalten. MFG -- if ($GLOBALS['FORUM']->forumuser->mitglied['ahnung'] == 0) { $this->besserKlappeHalten / nachDenken= 1;} Inside Windows-Kernel: if(everything_is_ok==1) { crash(); } [ Dieser Beitrag wurde von Begeisterter_Amiga_User am 12.12.2008 um 19:33 Uhr geändert. ] [ Dieser Beitrag wurde von Begeisterter_Amiga_User am 12.12.2008 um 19:34 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 20:22 h Maja Posts: 15429 User |
@_PAB_: Danke. Sehr aufschlussreich. Nun weiß ich aber - augenscheinlich - immer noch nicht, was einen Schreibzyklus (Schreibzugriff) ausmacht.  (Nachtrag: Beiträge haben sich überscnitten. Dank Holger bekomme ich nun ein Gefühl dafür, dass es hauptsächlich darauf ankommt, wie gut oder schlecht Wear Levelling arbeitet, damit bei hoher Belastung keine/nicht viele Zellen vorzeitig hin sind.) Mal ein paar Werte. Datenblatt X25-E, 32 und 64 GB: http://download.intel.com/design/flash/nand/extreme/extreme-sata-ssd-datasheet.pdf Sagt auf Seite 10: "Nonrecoverable read errors (BER): 1 sector in 10 hoch 15 bits read, max" (1,25 PB, wenn ich richtig gerechnet habe) "Mean Time Between Failures (MTBF): 2,000,000 hours" (reicht bei 7Std./Tag im Schnitt 782 Jahre, im Dauerbetrieb immerhin noch 219) "Power On/Off Cycles: 50,000 cycles" (schafft 50.000 Mal An/Aus) Erläuterungen zu den Begriffen: "Non-recoverable read errors The nonrecoverable read error rate will not exceed one sector in the specified number of bits read. In the extremely unlikely event of a nonrecoverable read error, the drive will report it as a read failure to the host; the sector in error is considered corrupt and is not returned to the host." (Auf Seite 7 steht, ein Block = 512 Byte.) "Mean Time Between Failure The Mean Time Between Failures (MTBF) is calculated based on a Part Stress Analysis. It assumes nominal voltage, with all other parameters within specified range." (Ein errechneter Wert.) "Power On/Off Cycles Defined as power being removed from the drive, and then restored. Note that host systems and drive enclosures may remove power from the drive for reasons other than a system shutdown." (Die gewohnte Praxis, Datenträger bei Nichtbenutzung abschalten zu lassen, um Strom zu sparen, beeinträchtigt auch hier die Lebensdauer.) Im ganzen Datenblatt kein Wort davon, wie viele Schreibzugriffe insgesamt möglich sind. Auch nicht, welche Art von Speicherzellen verwendet werden. Oder hab ich was übersehen? (Nachtrag: Ja, ich hab was übersehen. Im Datenblatt ist von NAND-Flash die Rede. Also 1.000.000 Zyklen. Auch hier Dank an Holger für seine Ausführungen.) Noch etwas Zukunftsmusik: http://neuerdings.com/2008/07/19/flash-speicher-wird-langlebig-100-millionen-schreibzyklen/ [ Dieser Beitrag wurde von Maja am 12.12.2008 um 20:32 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 20:23 h Holger Posts: 8116 User |
Zitat:Ich wusste gar nicht, dass Normaluser sich Pyramiden hinstellen können Und genug Kapazität für ein Festplatten- resp. SSD-Backup hat so ein Medium auch nicht. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 21:07 h rbn Posts: 2001 User |
@Holger: > Bleibt nur noch eines: wieso soll man mit Sparse Files weniger Torrents gleichzeitig bearbeiten können? Du wirst natürlich bei einer nahezu vollen Festplatte wieder genauso viel Fragmentierung wie ohne Sparse-Files erhalten, aber sonst? Weil die Sparse Files Platz belegen auf der Platte. Und wenn die Platte voll ist, kein weiteres Sparse File angelegt werden kann für den nächsten Torrent. Ohne die Sparse Files aber problemlos auch ein weiterer Torrent hätte geladen werden können. > Aber falls Du die ganze Zeit auf die 100GB pro Tag hinauswillst, von denen irgendwo mal gesprochen wurde: ich glaube gerne, dass Du mehr Daten pro Tag speicherst Ich glaube das nicht. Es ging mir darum deutlich zu machen, dass es kein großes Problem darstellt massig Schreibzugriffe mit seinem Rechner zu verursachen. > (auch wenn ich das keineswegs für normal halte) Naja, du hälst wahrscheinlich auch noch Kabel TV oder Terrestrisches Radio für normal ... > Du musst sie zumindest für das Brennen lesen -> Reduktion der Schreibzugriffe Auch während dem Brennen werden die Torrentsl laufen gelassen, wenn schon - denn schon. Aber gut, gehen wir davon aus, dass jede zweite Sekunde ein Schreibzugriff stattfindet, bei dem EINE Zelle betroffen ist (was in der Praxis viel zu wenig ist). Dann entstehen pro Tag im Dauerbetrieb Theoretisch 43.200 Zellschreibvorgänge. In der Praxis natürlich FS bedingt entsprechen mehr. ... Da kann man eigentlich nur beten, dass das Wear Leveling das hält, was es verspricht. --- Jetzt aber auch mal einfach von mir privat gesprochen: bei mir hat noch kein Flashspeicher wirklich lange gehalten (trotz sachgemäßer Behandlung - nicht in der Hosentasche transportieren etc.). Hier im Thread waren bisher auch schon einige die davon berichten und in meinem Bekanntenkreis können auch fast alle ein Lied davon singen, dass man bei USB-Sticks davon ausgehen sollte, dass man diese nunmal regelmäßig neu kaufen muss. Warum in aller Welt will sich also jemand so etwas als DAUERHAFTEN Festplattenersatz anschaffen, wenn sogar auf der Packung schon draufsteht, dass das Dingen sooo verdammt lange wohl eher nicht halten wird ??? rbn -- Marketing. Modern. Mittelständisch. http://www.rhein-sieg-design.de [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 21:22 h Maja Posts: 15429 User |
@rbn: USB-Sticks haben kein Wear Levelling. Die sollte man auch nicht als Dauerlaufwerk benutzen, wozu sie zudem auch nicht gedacht sind. Wenn ich das jetzt richtig verinnerlicht habe, definiert sich ein Schreibzyklus bei wirklich gutem Wear Levelling im einmaligen füllen des gesamten Volumens eines SSD-Laufwerks. Denn Wear Levelling soll dafür sorgen, dass keine Zelle ein zweites Mal beschrieben wird, bevor nicht alle anderen auch beschrieben wurden. Also kommt es darauf an und auf die Frage, wie lange es dauert, bis z. B. ein 64 GB Medium 1 Million Mal vollständig beschrieben wurde. Rechne mal nach, wie viel GB Torrents Du so am Tag saugst. @all Mercy, please. Da war ich offenbar auf dem Holzweg. Die Zahl der Schreibzyclen ist zumindest bei SSD mit gutem Wear Levelling wohl tatsächlich nicht das Problem, das ich dahinter gesehen hatte. [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 22:27 h rbn Posts: 2001 User |
@Maja: > USB-Sticks haben kein Wear Levelling. Ich habe das Wort "USB-Sticks" hier als Synonym benutzt, für die Speicherzellen-Technologie, ich dachte, das wäre ziemlich eindeutig gewesen ... > Die ... [USB-Sticks] ... sollte man auch nicht als Dauerlaufwerk benutzen, wozu sie zudem auch nicht gedacht sind. Dazu sind sie anscheinend auch mit Wear-Leveling nicht zu gebrauchen, denn ... -> siehe Antwort nächster Punkt.. > ... Wear Levelling soll dafür sorgen, dass keine Zelle ein zweites Mal beschrieben wird, bevor nicht alle anderen auch beschrieben wurden. Und wie soll das in der Praxis funktionieren? Zugegeben, das hört sich theoretisch ganz toll an. Nur reden wir hier nicht von einem Bandlaufwerk, das vorne nach hinten bespielt wird, und wenn das Band zuende ist, fängt man wieder von vorne an (den Seitenwechsel habe ich jetzt mal überschlagen). Um das so zu realisieren, wie du es beschreibst, müssten bei normalen Desktopbetrieb ständig die Daten auf dem Ding umgeräumt werden, was wohl ziemlich auf die Übertragungsrate gehen dürfte. Aber man könnte ja ne Festplatte als Puffer davorhängen ...  Also entweder hast du da immer noch etwas falsch verstanden, oder es handelt sich um eine der gröbsten mir bisher bekannten Kundenverarschen in der Computergeschichte. rbn -- Marketing. Modern. Mittelständisch. http://www.rhein-sieg-design.de [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 22:31 h Holger Posts: 8116 User |
Zitat:Vielleicht reden wir von verschiedenen Sparse-Files. Normalerweise versucht das Dateisystem, Sparse-Files voneinander fernzuhalten, um die Fragmentierung zu verhindern. Aber Du scheinst von einem Szenario auszugehen, bei dem Du mehr Downloads startest, als tatsächlich auf die Platte passen, um dann zwischendurch Dateien zu löschen, damit sie doch gespeichert werden können. Das funktioniert natürlich auch mit Sparse-Files, allerdings um den Preis, dass es doch eine gehörige Fragmentierung gibt, ganz genauso wie ohne Sparse-Files. Was Du offenbar nicht verstehen willst: Sparse-Files werden nicht mit nullen gefüllt, im Gegenteil: unbenutzte Bereiche belegen keinen Platz. Das ist der primäre Zweck. Der Unterschied zu normalen Dateien: wenn Du einen Download auf mehrere Server verteilst, kann ein für einen hinteren Bereich zuständiger Server schneller sein, womit bei einer normalen Datei alle noch nicht runtergeladenen Bereiche vor diesem Chunk komplett mit Nullen beschrieben werden muss, während bei einem Sparse-File, die Datei einfach nur aus diesem Chunk, bzw. allen bereits runtergeladenen Chunks besteht. Zitat:Aber niemals mehr als bei einem Dauerschreibtest. Zitat:Es scheint immer noch der gleiche Denkfehler zu bestehen: eine Festplatte kann nicht gleichzeitig lesen und schreiben. Sie kann das nur abwechselnd. Zitat:Peanuts Zitat:Natürlich finden wesentlich mehr statt. Zitat:Logisch. Ohne dem würde gar nichts gehen. Zitat:Ich trag meinen täglich von zu Hause zur Arbeit und zurück. Mal in der Hosentasche, mal in der Jackentasche. Natürlich zum Zweck des täglichen Benutzens. Bisher keine Probleme. Ich würde nur empfehlen, einen Bogen um besonders billige und besonders kleine (wirklich im räumlichen Sinne) USB-Sticks zu machen. Abgesehen davon sagen Deine Erfahrungen aus der Vergangenheit natürlich nichts über den aktuellen Stand der Technik aus. Zitat:Doch haben sie. Anders wäre es kaum möglich gewesen, dass die Tester der c't 16 Millionen Mal auf die gleiche Datei schreiben konnten. Das war ein Test für die Dauerbelastung, den der Stick offensichtlich bestanden hat. Zitat:Im Idealfall. Zitat:Nun, exakt so kann es nicht funktionieren. Wenn ein Medium voll ist, bedeutet das Tauschen von Zellen, dass der Inhalt einer nicht so oft beschriebenen Zelle in die oft beschriebenen Zelle wandern muss, also ein weiterer Schreibzugriff hinzukommt. Wenn man das nach jedem Schreibzugriff tun würde, würde das nach hinten losgehen. Der Algorithmus darf dann also erst nach einer gewissen Anzahl von Schreibzyklen tauschen und muss am besten schon vorher erraten, wo als nächstes viele Schreibzyklen zu erwarten sind. Eventuell kommen bei einem Tauschvorgang auch Reserveblöcke ins Spiel, die vom Dateisystem nicht benutzt werden können. Die genauen Algorithmen sind Geheimsache der Hersteller... Zitat:Über den Daumen gepeilt. Es sind aber schon 256GB-SSDs angekündigt. Zitat:Dann ist ja wieder alles gut. Bleibt nur noch, dass SSDs entweder zu langsam, zu teuer, beides oder nicht verfügbar sind (letzteres im Falle der angekündigten SSDs, die die ersteren Punkte zumindest entschärfen sollen). mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 22:50 h Holger Posts: 8116 User |
Zitat:Was heißt, beim Desktop-Betrieb? Das passiert bei so ziemlich jeder Nutzungsart. Aber selbstverständlich passiert das im Speichermedium, hat mit der Übertragungsrate herzlich wenig zu. Bei einem nicht komplett gefüllten Medium ist es egal, ob in die ursprüngliche Zelle oder eine andere geschrieben wird. Wenn nur Teile einer Zelle beschrieben werden, muss sowieso die Zelle erst gelesen werden, und dann ist es wiederum egal, in welche Zelle geschrieben wird. Bei einem komplett vollen Medium sieht es schon anders aus. Aber vermutlich besitzt jedes Medium genau zu diesem Zweck Reservezellen, mit denen man einen Ringtausch machen kann, womit der Aufwand wiederum nur aus einem Lesevorgang (nur wenn Teilzellen beschrieben werden) und einem Lösch/Schreibvorgang besteht. Die ursprüngliche Zelle ist danach ja unbenutzt. Und damit ist der Aufwand auf Seite der Flash-Zellen nicht höher als ohne Wear-Levelling. Und wenn der Kontroller noch so clever ist, Zeiten ohne Zugriffe zum Löschen ehemals benutzter Zellen zu benutzen, kann er die nächsten Schreibzugriffe sogar ohne Löschzyklus durchführen, ist in diesem Falle beim Überschreiben sogar schneller als ohne Wear-Levelling. Inzwischen sind SSDs schon bei dreistelligen MB/s-Zahlen beim Schreiben. Zitat:Was soll die Festplatte vor dem Medium bei Vorgängen innerhalb des Mediums? Zitat:Nein, ich glaube diesmal hat jemand anderes etwas nicht verstanden. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-12-12, 23:30 h rbn Posts: 2001 User |
@Holger: > Was Du offenbar nicht verstehen willst: Sparse-Files werden nicht mit nullen gefüllt, im Gegenteil: unbenutzte Bereiche belegen keinen Platz. Das ist der primäre Zweck. Der Unterschied zu normalen Dateien: wenn Du einen Download auf mehrere Server verteilst, kann ein für einen hinteren Bereich zuständiger Server schneller sein, womit bei einer normalen Datei alle noch nicht runtergeladenen Bereiche vor diesem Chunk komplett mit Nullen beschrieben werden muss, während bei einem Sparse-File, die Datei einfach nur aus diesem Chunk, bzw. allen bereits runtergeladenen Chunks besteht. Ah, jetzt hat es klick gemacht. Bisher hörte es sich so an, als wenn so der Speicher für das "zukünftige" File reserviert wird und so dem System nicht mehr zur Verfügung steht. > Aber niemals mehr [Schreibzugriffe] als bei einem Dauerschreibtest. Hab ich auch nie behauptet, aber es gab hier Threadteilnehmer, die schienen in der Diskussion mit Maja auf dem Standpunkt zu stehen, dass beim normalen User die Anzahl der Schreibzugriffe zu vernachlässigen ist. Ich wollte mit diesem Beispiel nur klarstellen, dass man das (wie eigentlich alles) nicht so einfach über einen Kamm scheren kann und sollte. > Inzwischen sind SSDs schon bei dreistelligen MB/s-Zahlen beim Schreiben. > Bleibt nur noch, dass SSDs entweder zu langsam, ... Hier widersprichst du dir aber selbst ... > Es scheint immer noch der gleiche Denkfehler zu bestehen: eine Festplatte kann nicht gleichzeitig lesen und schreiben. Sie kann das nur abwechselnd. Sag bloß. Das ist mir schon klar. Ein heutiges System kann das aber sehr sehr schnell abwechseln. So dass meine Aufstellung von wegen ein Schreibzugriff jede zweite Sekunde schon reichlich untertrieben war. Daher würde ich diese Menge wirklich nicht als "Peanuts" abtun in Anbetracht der Menge möglicher Schreibzugriffe, die Andreas Wolf hier auf dieser Diskussion beruhend als 2281,25 für jede einzelne Zelle errechnet hat. > Was soll die Festplatte vor dem Medium bei Vorgängen innerhalb des Mediums? Da war ja wohl ein wirklich DICKER Smiley hinter ...  > Nein, ich glaube diesmal hat jemand anderes etwas nicht verstanden. Ja, denn ich glaube du hast tatsächlich noch nicht verstanden, warum ich diese Argumentationskette überhaupt begonnen habe (s. o.). Da sich der eigentliche "Anstoßer" für meine Meldung nicht mehr blicken lässt ist es aber auch relativ mühselig weiterhin darüber zu diskutieren. Ich denke es ist klar geworden, wo ich damit hinwollte. rbn -- Marketing. Modern. Mittelständisch. http://www.rhein-sieg-design.de [ - Answer - Quote - Direct link - ] |
|
2008-12-13, 04:47 h Begeisterter_Amiga_User Posts: 665 User |
Zitat: es ging ja net um die größe des speichermediums um daten aufzunemen sondern um das wiederlegen deiner aussage das es kein handelsübliches medium gibt das sicher über jahrzehnte di daten speichern kann. zumindest ist die speicherdichte bei stein genauso begrenzt wie bei den ssd's oder festplatten weil kleiner als nen paar sandkörner kannst nun mal net schreiben weils dann mit der zeit unleserlich wird genauso wie bei magnetit beschichteten scheiben oder den speicherzellen von ssd festplatten. btw wenne im garten genug platz hast kannst da sicherlich mitn bürgermeister und deinem zuständigen bauamt was aushandeln können um die ne pyramide innen garten zu pflastern :> MFG -- if ($GLOBALS['FORUM']->forumuser->mitglied['ahnung'] == 0) { $this->besserKlappeHalten / nachDenken= 1;} Inside Windows-Kernel: if(everything_is_ok==1) { crash(); } [ - Answer - Quote - Direct link - ] |
|
2008-12-13, 11:35 h Flinx Posts: 1073 User |
Zitat:Sobald ich die erste kaputte SSD habe, berichte ich das hier, falls es das Forum dann noch gibt. Ansonsten Pardon, daß ich die angekündigte Erklärung nicht geliefert habe, aber ich hatte in den letzten Tagen wirklich keine Zeit, um mich um die Diskussion zu kümmern. Scheint ja aber, als ob inzwischen alle Unklarheiten ausgeräumt wären. Nur noch so als Nachtrag, speziell für Dich, weil mir das als letzter vielleicht unsicherer Punkt übriggeblieben scheint: Daß eine Festplatte (beliebiger Art) grundsätzlich gar keinen Unterschied sieht, ob auf ihr große oder kleine Dateien geschrieben werden, ist Dir inzwischen klar? Das Dateisystem zerlegt (üblicherweise und aus historischen Gründen) alles in 512 Byte große Blöcke, die vom und zum Laufwerk übertragen werden. Soll weniger geschrieben werden, muß das Dateisystem erstmal den passenden Block (Sektor) lesen, und dann geeignet verändert zurückschreiben. Für die Platte ist es immer dasselbe: In die Register wird die Nummer des Blocks geschrieben, und dann gibt es den Schreib- oder Lesebefehl. Ggf. (speziell bei DMA) werden auch mehrere hintereinanderliegende dieser Blöcke übertragen. (Wenn es genauer gebraucht wird, hier mal eine ältere Beschreibung des ATA Command Sets, mit ATAPI sind dann noch die SCSI-Befehle dazugekommen.) Für zukünftige Massenspeicher wird man sich sicherlich was neues ausdenken, die stecken dann wahrscheinlich im Systembus und haben andere Übertragungsmethoden, aber die Protokolle wird man wohl weiter unterstützen müssen. [ - Answer - Quote - Direct link - ] |
|
2008-12-13, 15:12 h Maja Posts: 15429 User |
Zitat:Nun, nach dem zu urteilen, was Holger jetzt dazu erklärt hat, ist genau das die Vorgehensweise von Wear Levelling. Und offenbar hat das keinen spürbaren Einfluss auf die Performance des Laufwerks, wenn es gut gemacht wird. Hast Du dir das entsprechende Video unter _PAB_s Link mal angeschaut? Dieser Artikel ist übrigens wirklich mal gut geschrieben. Sehr aufschlussreich, auch für Laien. Festplatten können übrigens tatächlich nicht gleichzeitig schreiben und lesen. Damit das nicht zu sehr auf die Perfomance geht und keine Hänger entstehen, gibt es in Betriebssystemen Scheduler, welche die zeitliche Abfolge von Schreib- und Leseanfoderungen an die Platte organisieren, die im Cache der Platte auf ihre Abarbeitung warten. Wie beim Multitasking nicht gleichzeitig, sondern immer schön alles nacheinander. Zitat:Die Perfomance hat bei ansich sehr guten Zugriffszeiten etwas mit dem Verhalten bei Random Write/Read zu tun, wie ich unter _PABs_ Link gelernt habe. Gute Lösungen kosten halt auch entsprechend. Zum Preis. Hier gilt offenbar umso mehr, je billiger desto schlechter. Preise um die 800 Euro für 128 GB sind für reine Heimanwender schlicht indiskutabel. Es sei denn, man ist die Art von Technik-Freak, die über enstprechende freie Mittel verfügt. Wir sind zwar keine armen Leute, müssen beim Konsum aber dennoch Prioritäten setzen. Ich sage mal, ab 250 Euro für 500 GB (nicht zwingend in einem Laufwerk) könnten wir über einen Kauf ernsthaft nachdenken. Bis dahin wird noch einiges an Wasser den Rhein hinunterlaufen und die Technik wird vermutlich auch noch mal verbessert worden sein. Irgendwann wird vermutlich SATA selbst der Flaschenhals sein, mit dem Storage-Lösungen zu kämpfen haben werden. Was die Frage aufwirft, bei welchem Einsatzzweck 3GB/Sek. realistisch betrachtet tatsächlich zu wenig sein könnten. Was bisher nicht geschafft wurde, ist die Entwicklung einer technischen Lösung zur Datenspeicherung mit der langfristigen Datensicherheit von ägyptischen Grabtafeln. In der Hinsicht hat sogar Papier gegenüber elektronischen Lösungen noch immer die Nase vorn. Zitat:Keine Ursache, Job, Familie und Du selbst gehen natürlich vor. Zitat:Ja, das war mein Denkfehler. Und danke für deine weiteren Ausführungen und den Link dazu. Das ruft mir in Erinnerung, was ich dabei außer Acht gelassen hatte. Dinge die mir zwar nicht unbekannt waren, ich hier aber nicht in Zusammenhang brachte. Wenn man beruflich nichts damit zu tun hat, erschließen sich solche Zusammenhänge nicht unbedingt automatisch. Zitat:Natürlich. Abwärtskompatibilität ist ein leidiges Thema bei der Weiterentwicklung. Jetzt noch eine Frage aus Interesse. Können SSDs real mehrere Operationen gleichzeitig ausführen, z. B. schreiben und lesen oder mehrere, nacheinander erteilte Schreibanforderungen zur selben Zeit erledigen? In besagtem Video unter _PAB_s Link hat es den Anschein. [ Dieser Beitrag wurde von Maja am 13.12.2008 um 15:13 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-13, 17:38 h Holger Posts: 8116 User |
Zitat:Im Verhältnis zu dem, was eine aktuelle SSD verkraftet, kann man das durchaus vernachlässigen. Zitat:Hier wirfst Du zwei Dinge in einen Topf. Ein Schreibzugriff auf die SSD ist etwas völlig anderes als ein Schreibzugriff pro Zelle. Für letzteres müsstest Du bei einer 256GB SSD mit funktionierendem Wear-Levelling auch wirklich rund 256GB auf den Datenträger schreiben. Das schaffst Du nicht alle zwei Sekunden, nicht mal ansatzweise. Zitat:Nicht wirklich. Wear-Levelling ordnet nunmal tatsächlich logischen Blöcken anderen physikalische Zellen zu. Warum Du Dich auf den Standpunkt stellst, dass dies entweder falsch oder "eine der gröbsten mir bisher bekannten Kundenverarsche" darstellt, wenn Du es angeblich verstanden hast, entzieht sich jeglichem Verständnis. Was auch immer das für ein rhetorischer Kniff sein soll, den musst Du uns schon erklären. Anderenfalls haben wir gar keine andere Möglichkeit, als anzunehmen, dass Du es doch nicht verstanden hast. Zitat:Nö, denn Du hast ja den oder-Teil unterschlagen. Die 200GB/s-Exemplare sind noch nicht lieferbar, die 100GB/s-Varianten im Moment nicht lieferbar und SSDs, die lieferbar und bezahlbar sind, sind deutlich langsamer. Zitat:Pyramiden sind definitiv nicht handelsüblich. Zitat:Bis die fertig wäre, wären die zu sichernden Datenträger schon nicht mehr lesbar. Wahrscheinlich wäre auch der Bauherr auch schon nicht mehr abrufbar. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-12-13, 17:47 h Holger Posts: 8116 User |
Zitat:Es gibt bereits SSDs, die direkt via PCIe angebunden sind, z.B. von Fusion-IO, 700MB/s beim Lesen und 550MB/s beim Schreiben. Kostet schlappe $2500 für 80GB. Micron hat eine PCIe SSD angekündigt, die 1GB/s liefern soll. Ich will gar nicht wissen, zu welchem Preis. Zitat:Auch da gilt, dass man beim Druckverfahren und bei Papier und vor allem bei der Tinte nicht zu sparsam sein sollte... Insbesondere Tankstellenquittungen sind oftmals schon nach wenigen Wochen unbrauchbar. Zitat:Prinzipiell ist das machbar, da jede Zelle unabhängig von der anderen arbeitet. Es erhöht natürlich massiv den Aufwand der Steuerungselektronik, es entspricht letztendlich einem RAID von vielen kleineren SSDs. Bzw. eher einem Cluster von autark arbeitenden SSDs. Aber natürlich läuft bei einem SATA-Gerät am Ende alles durch die eine serielle Strippe. Womit es eine Kosten/Nutzen Frage ist, ob und wieviel Parallelität man in einer SSD wirklich realisiert. Aber Transferraten jenseits der 100MB/s kann man bestimmt nicht realisieren, wenn man eine Zelle nach der anderen liest/schreibt. Zitat:Nun SATA unterstützt NCQ, was SCSI unter anderem Namen schon lange kann. Und (P)ATA ist bald Geschichte. Damit ist eigentlich schon genug Raum für SSD-seitige Optimierungen in den aktuellen Protokollen vorhanden. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-12-13, 22:18 h Maja Posts: 15429 User |
Zitat:Das sind spezielle Lösungen für besondere Einsatzgebiete. Ein Heimanwender wird sich ungern einen PCIe-Slot mit einem Datenträger belegen wollen. Zitat:Kassenzettel auf Papier, dessen Belegseite glatter ist als die Rückseite? Diese Kassenzettel werden im Thermodruckverfahren erstellt. [ Dieser Beitrag wurde von Maja am 13.12.2008 um 22:18 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-12-14, 09:14 h Bogomil76 Posts: 2800 User |
SATA II hat aber 3 GigBIT/s, nich GigaBYTE/s... [ - Answer - Quote - Direct link - ] |
|
2008-12-14, 19:54 h Maja Posts: 15429 User |
@Bogomil76: Uups, ja stimmt.  Da war ich wohl zu optimistisch... [ - Answer - Quote - Direct link - ] |
| 1 2 3 4 -5- 6 7 | [ - Post reply - ] |
| amiga-news.de Forum > Andere Systeme > kann mann Festplatten leiser tunen? | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|
