Re: usb-stick durch Benutzung zerstört?
Hi,
Also sprach Gerhard Wolfstieg <gw@wolfstieg.com> (Fri, 21 Oct 2005
15:28:28 +0200):
> On Fri, 21 Oct 2005 01:10:14 +0200
> Richard Mittendorfer <delist@gmx.net> wrote:
>
> > Wie du schon recht vermutest, gibt's keinen Unterschied zwischen
> > async und sync was die Datenmenge oder die Haeufigkeit* der am
> > gleichen Fleck geschriebenen Daten angeht. Bei async wird das
> > schreiben lediglich verzoegert (es wird im buffer gehalten und bei
> > Zeit/commit rausgeschrieben). Bei sync wird die Datei in dem Moment
> > geschrieben, in dem der Befehl zum Filesystem kommt/flush (useful,
> > wenn man/frau den eigentlichen Durchsatz zur Platte wissen will oder
> > ein floppyimage schreibt; conv=sync) - also ab Daten-Aenderung.
>
> Hallo,
>
> falls das zur Zeit stimmen sollte, kann man nicht davon ausgehen, daß
> das nicht in Zunkunft durch Optimierung anders ist.
s.u.
> Ich kann mir
> vorstellen, daß es Anwendungen gibt, die Dateien in kurzen Abtänden
> modifizieren.
Gewiss. Aber die haben auf einem Medium welches sich "so schnell"
abnuetzt (und syncron gehalten wird) nichts (nicht lange was) verloren.
Die vorhandenen Optimierungen sind Dinge wie der IO-Scheduler und
filesystem-eigene Verbesserungen (zB. btrees, reisers
datenbank-aehnliches Vorgehen und Aehnliches) um Daten schneller
vom/aufs Filesystem zu bekommen / platzsparender, oekonomischer zu
speichern / journaling / und auch die Platte im Mobile ruhigzustellen.
Der IO Scheduler* ermoeglicht effezientere Headbewegungen bei
konkurierenden Zugriffen und hat damit eigentlich nix zu tun.
*vermutlich ist noop auf usb/cf der schnellste?
Dateisystemeigene Optimierungen duerften im Grossen auch kaum eine Rolle
spielen - sei denn, es ist ein kaputtes Filesystem 8).
Also bleibt noch das LinuxVM. Dieses verwaltet wann eine Datei dirty
genug ist um rausgeschrieben zu werden. Inwieweit es eine Interaktion
mit dem FS-Treiber's commit gibt ist mir nicht 100%ig klar. Das duerfte,
wie auch dirty_*_centisecs, ein (hier fixes) limit sein die Platte sync
zu halten.
Die hier hilfreichen Optimierungen sind eher am Medium selber zu suchen.
So mappen vernuenftige Speichercontroller kaputte Regionen selbstaendig
weg und scheinen sogar fuer gleichmaessige Belastung der Regionen zu
sorgen (sofern Platz - siehe Thread in Sven's interessanten vger-Link).
> Gruß, Gerhard
sl ritch
Reply to: