Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Win7: Schreibcache

77 views
Skip to first unread message

ha

unread,
Dec 27, 2014, 1:00:40 AM12/27/14
to
Hallo

Falls es eine Rolle spielen sollte, erstmal mein System:
Win7 64 Bit, Ultimate.

Mein System läuft im AHCI-Modus. Es ist keine IDE-Platte vorhanden.


Was haltet ihr von einem aktivierten Schreibcache (für die eingebauten
Festplatten)?

1. Wäre es bei aktivem Cache wirklich so viel "dramatischer" wenn der
Strom einmal ausfällt?

Kann man auf die Intervalle oder Situationen, in denen Windows den Cache
auf die Platten schreibt, Einfluss nehmen um die Risiken zu minimieren ?

2. Ich höre ab und zu, das der Einsatz des Schreibcaches bei Kopier-
vorgängen hin und wieder zu unbrauchbaren Daten führt. Ob sich das
NUR auf Wechseldatenträger bezieht, war nicht klar zu erkennen.



Michael Logies

unread,
Dec 27, 2014, 2:32:42 AM12/27/14
to
On Sat, 27 Dec 2014 07:00:37 +0100, ha <Henry_A...@Safe-mail.net>
wrote:

>Was haltet ihr von einem aktivierten Schreibcache (für die eingebauten
>Festplatten)?

Sehr sinnvoll, beschleunigt Schreibvorgänge deutlich. Ist auch die
Voreinstellung für interne Festplatten.

>1. Wäre es bei aktivem Cache wirklich so viel "dramatischer" wenn der
>Strom einmal ausfällt?

Kommt darauf an, wie viele Daten gerade geschrieben werden sollten.
Ich habe es in ca. 25 Jahren mit PCs noch nicht erlebt, daß nun gerade
der Strom ausfiel, als unwiederbringliche Daten auf die Festplatte
geschrieben wurden. Für Privatanwender kommt das vermutlich kaum vor,
sonst hätten sie eine unterbrechungsfreie Stromversorgung (USV).

Ich habe einige Stromausfälle erlebt, aber die Windows-PCs sind danach
unbeschadet wieder hochgefahren, selbst ein PostgreSQL-Datenbankserver
in einer virtuellen Maschine (VMWare Player) auf einer verschlüsselten
Partition (Truecrypt). Diese Robustheit von Windows, die sich
vielleicht auch den ständigen Abstürzen der Windowsversionen der
DOS-Reihe verdankt, habe ich immer geschätzt. Bei Linux war nach
Stromausfall schon `mal das Dateisystem kaputt.

>Kann man auf die Intervalle oder Situationen, in denen Windows den Cache
>auf die Platten schreibt, Einfluss nehmen um die Risiken zu minimieren ?

M. W. nicht.

>2. Ich höre ab und zu, das der Einsatz des Schreibcaches bei Kopier-
>vorgängen hin und wieder zu unbrauchbaren Daten führt. Ob sich das
>NUR auf Wechseldatenträger bezieht, war nicht klar zu erkennen.

Ja, ist ein Problem von Wechseldatenträgern, wenn man die entfernt,
bevor der Cache auf die Platte geschrieben werden konnte. Deshalb
sollte man die bei aktiviertem Cache vorher über das Symbol im Systray
abmelden (und ansonsten auch, wenn man auf Nummer sicher gehen will).

Grüße

M.

ha

unread,
Dec 27, 2014, 3:34:31 AM12/27/14
to
Michael Logies <log...@t-online.de> schrieb:


>> Was haltet ihr von einem aktivierten Schreibcache (für die eingebauten
>> Festplatten)?
>
> Sehr sinnvoll, beschleunigt Schreibvorgänge deutlich. Ist auch die
> Voreinstellung für interne Festplatten.


Ich hatte das bislang aufgrund der Zweifel deaktiviert.

Aber es gibt Anwendungen, die mitunter dermaßen auf die Festplatte
zugreifen, das darunter die Leistung leidet. Bisher hielt sich das in
Grenzen. Letztens aber war es heftig. Und da hatte ich den Cache
testweise aktiviert, was eine deutliche Besserung brachte. Und jetzt
sammle ich erstmal Informationen zum Thema.


>> 1. Wäre es bei aktivem Cache wirklich so viel "dramatischer" wenn der
>> Strom einmal ausfällt?
>
> Kommt darauf an, wie viele Daten gerade geschrieben werden sollten.
> Ich habe es in ca. 25 Jahren mit PCs noch nicht erlebt, daß nun gerade
> der Strom ausfiel, als unwiederbringliche Daten auf die Festplatte
> geschrieben wurden. Für Privatanwender kommt das vermutlich kaum vor,
> sonst hätten sie eine unterbrechungsfreie Stromversorgung (USV).

Wenn Daten, die gerade in Bearbeitung sind, verloren gehen, ist das
evtl. zu verschmerzen, weil Stromschwankungen selten sind. Aber
wenn anschließend das System neu aufgesetzt werden muss, ist das weniger
lustig.


> bevor der Cache auf die Platte geschrieben werden konnte. Deshalb
> sollte man die bei aktiviertem Cache vorher über das Symbol im Systray
> abmelden (und ansonsten auch, wenn man auf Nummer sicher gehen will).

Das mache ich gewohnheitsmäßig immer.




Sherlock

unread,
Dec 27, 2014, 10:01:29 AM12/27/14
to
ha:

> Mein System läuft im AHCI-Modus. Es ist keine IDE-Platte vorhanden.
> Was haltet ihr von einem aktivierten Schreibcache (für die eingebauten
> Festplatten)?

Nur das Beste. :-)

> 1. Wäre es bei aktivem Cache wirklich so viel "dramatischer" wenn der
> Strom einmal ausfällt?

Wie willst du den Cache denn überhaupt deaktivieren? Die Einstellung
"Schreibcache auf dem Gerät aktivieren" ist NICHT der Schreibcache, den
Windows für das Gerät bereitstellt.

> Kann man auf die Intervalle oder Situationen, in denen Windows den Cache
> auf die Platten schreibt, Einfluss nehmen um die Risiken zu minimieren ?

Nein.

> 2. Ich höre ab und zu, das der Einsatz des Schreibcaches bei Kopier-
> vorgängen hin und wieder zu unbrauchbaren Daten führt.

Das ist Unsinn. Ohne Cache wäre Windows Schrott.

> Ob sich das
> NUR auf Wechseldatenträger bezieht, war nicht klar zu erkennen.

Wechseldatenträger entfernt man über "sicheres Entfernen", dann passiert
auch nichts. Wenn man ihn entfernt, während noch Schreibvorgänge laufen,
heißt das Problem PEBCAK.

ha

unread,
Dec 27, 2014, 11:06:16 AM12/27/14
to
Sherlock <sherl...@gmx.net> schrieb:


> Wie willst du den Cache denn überhaupt deaktivieren? Die Einstellung
> "Schreibcache auf dem Gerät aktivieren" ist NICHT der Schreibcache, den
> Windows für das Gerät bereitstellt.

Wie das ? Davon ging ich aus. Schon die Erklärung "vor Ort" weißt
darauf hin, das es sich um genau den Cache handelt, zu dem ich fragte.

Was soll diese Funktion denn sonst bedeuten?





Helmut Hullen

unread,
Dec 27, 2014, 11:40:22 AM12/27/14
to
Hallo, Hans-Peter,

Du meintest am 27.12.14:

>> Mein System läuft im AHCI-Modus. Es ist keine IDE-Platte vorhanden.
>> Was haltet ihr von einem aktivierten Schreibcache (für die
>> eingebauten Festplatten)?

[...]

>> 1. Wäre es bei aktivem Cache wirklich so viel "dramatischer" wenn
>> der Strom einmal ausfällt?

> Wie willst du den Cache denn überhaupt deaktivieren?

Das geht bei neueren Festplatten in den "Entfernungsrichtlinien" für die
jeweilige Festplatte.

Siehe z.B.

ftp://bs.hullen.de/Hullen/Cache/HD-Win7.png

> Die Einstellung "Schreibcache auf dem Gerät aktivieren" ist NICHT der
> Schreibcache, den Windows für das Gerät bereitstellt.

Aber der Menupunkt wird (bei neueren Platten) angeboten, er ist also
schaltbar.

>> 2. Ich höre ab und zu, das der Einsatz des Schreibcaches bei Kopier-
>> vorgängen hin und wieder zu unbrauchbaren Daten führt.

> Das ist Unsinn. Ohne Cache wäre Windows Schrott.

Du vermischt mal wieder den Windows-Cache mit dem Festplatten-Cache. Das
sind verschiedene Bauteile.

Viele Gruesse!
Helmut

hpm/Sherlock: Die gesamte Gruppe ist ein Experimentalprojekt meinerseits.

Helmut Hullen

unread,
Dec 27, 2014, 11:40:23 AM12/27/14
to
Hallo, ha,

Du meintest am 27.12.14:
Startpunkt: z.B. Gerätemanager/Laufwerke/Eigenschaften, dann sollte so
etwas wie unter

ftp://bs.hullen.de/Hullen/Cache/HD-Win7.png

erscheinen.

ha

unread,
Dec 27, 2014, 11:47:35 AM12/27/14
to
Hel...@Hullen.de (Helmut Hullen) schrieb:


> ftp://bs.hullen.de/Hullen/Cache/HD-Win7.png

Genauso sieht es aus. Und von der Option sprach ich.



Sherlock

unread,
Dec 27, 2014, 12:11:26 PM12/27/14
to
ha:
Nun, das, was da steht: "Schreibcache auf dem Gerät aktivieren"
Das meint NICHT den Schreibcache, den Windows für die Platte bereitstellt.
Ist ja auch per Test sofort erkennbar. Kopiere eine Datei auf der Platte
irgendwo hin. Wiederhole den Kopiervorgang sofort: Der zweite Kopiervorgang
wird erheblich schneller gehen, bei genug RAM sogar in "Nullzeit" ohne dass
ein Kopierdialog erscheint. Daran siehst du, dass der Schreibcache von
Windows aktiv ist, auch wenn du deine Einstellung deaktiviert hast.

Sherlock

unread,
Dec 27, 2014, 12:11:26 PM12/27/14
to
Helmut Hullen:

>>> Mein System läuft im AHCI-Modus. Es ist keine IDE-Platte vorhanden.
>>> Was haltet ihr von einem aktivierten Schreibcache (für die
>>> eingebauten Festplatten)?

> [...]
>
>>> 1. Wäre es bei aktivem Cache wirklich so viel "dramatischer" wenn
>>> der Strom einmal ausfällt?
>
>> Wie willst du den Cache denn überhaupt deaktivieren?
>
> Das geht bei neueren Festplatten in den "Entfernungsrichtlinien" für die
> jeweilige Festplatte.
>
> Siehe z.B.
>
> ftp://bs.hullen.de/Hullen/Cache/HD-Win7.png

Auch das begreifst du wohl nie: das ist nicht der Windows-Schreibcache für
das Gerät.

>> Die Einstellung "Schreibcache auf dem Gerät aktivieren" ist NICHT der
>> Schreibcache, den Windows für das Gerät bereitstellt.

> Aber der Menupunkt wird (bei neueren Platten) angeboten, er ist also
> schaltbar.

Ändert nichts daran, dass man damit den Windows-Schreibcache nicht
deaktivieren kann. :-)

>>> 2. Ich höre ab und zu, das der Einsatz des Schreibcaches bei Kopier-
>>> vorgängen hin und wieder zu unbrauchbaren Daten führt.

>> Das ist Unsinn. Ohne Cache wäre Windows Schrott.

> Du vermischt mal wieder den Windows-Cache mit dem Festplatten-Cache. Das
> sind verschiedene Bauteile.

Nein, du vermischst es, ebenso wie der OP. Wenn schon jemand auf Nummer
Sicher gehen will, dann müsste er den Windows-Cache abschalten, nicht
irgendwelche Mini-Caches auf Geräten.

Helmut Hullen

unread,
Dec 27, 2014, 12:48:35 PM12/27/14
to
Hallo, ha,

Du meintest am 27.12.14:

>> ftp://bs.hullen.de/Hullen/Cache/HD-Win7.png

> Genauso sieht es aus. Und von der Option sprach ich.

Wenn nur diese beiden Optionen angezeigt werden: oben Haken setzen,
unten nicht (dürfte auch so vor-eingestellt sein).

Helmut Hullen

unread,
Dec 27, 2014, 12:48:35 PM12/27/14
to
Hallo, Hans-Peter,

Du meintest am 27.12.14:

>>> Wie willst du den Cache denn überhaupt deaktivieren?

>> Das geht bei neueren Festplatten in den "Entfernungsrichtlinien" für
>> die jeweilige Festplatte.
>>
>> Siehe z.B.
>>
>> ftp://bs.hullen.de/Hullen/Cache/HD-Win7.png

> Auch das begreifst du wohl nie: das ist nicht der
> Windows-Schreibcache für das Gerät.

Stimmt - Du willst mal wieder etwas widerlegen, was ich nie behauptet
habe. Und dieser hier angebotene Cache lässt sich offensichtlich
deaktivieren.

>>> Die Einstellung "Schreibcache auf dem Gerät aktivieren" ist NICHT
>>> der Schreibcache, den Windows für das Gerät bereitstellt.

>> Aber der Menupunkt wird (bei neueren Platten) angeboten, er ist also
>> schaltbar.

> Ändert nichts daran, dass man damit den Windows-Schreibcache nicht
> deaktivieren kann. :-)

Stimmt immer noch - von dem ist in diesem Umfeld nirgendwo die Rede. Den
schleppst Du nur als Ablenkungsmanöver heran.

>>>> 2. Ich höre ab und zu, das der Einsatz des Schreibcaches bei
>>>> Kopier-vorgängen hin und wieder zu unbrauchbaren Daten führt.

>>> Das ist Unsinn. Ohne Cache wäre Windows Schrott.

>> Du vermischt mal wieder den Windows-Cache mit dem Festplatten-Cache.

>> Das sind verschiedene Bauteile.

> Nein, du vermischst es, ebenso wie der OP.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!


> Wenn schon jemand auf
> Nummer Sicher gehen will, dann müsste er den Windows-Cache
> abschalten, nicht irgendwelche Mini-Caches auf Geräten.

Unfug.

ha

unread,
Dec 27, 2014, 12:58:00 PM12/27/14
to
Sherlock <sherl...@gmx.net> schrieb:


> irgendwo hin. Wiederhole den Kopiervorgang sofort: Der zweite Kopiervorgang

Du sagst es: SOFORT.

Denn kurz darauf ist der Speicher ggf. mit anderem gefüllt.

Ich verstehe die Sache mit dem Cache aber so, das alle Zugriffe erstmal
nur noch über das RAM ablaufen. Was da drin landet, bleibt erstmal drin.
Und in Intervallen wird das dann auf die Platte übertragen.

Sollten meine Tests etwa nur zufällig eine Verbesserung gebracht haben?

Willst du mir sagen, das die Option "Schreibcache auf dem Gerät
aktivieren" NICHT bedeutet, das alle Schreibzugriffe erstmal im RAM
stattfinden?



Sherlock

unread,
Dec 27, 2014, 2:50:54 PM12/27/14
to
Helmut Hullen:

>>> ftp://bs.hullen.de/Hullen/Cache/HD-Win7.png
>
>> Auch das begreifst du wohl nie: das ist nicht der
>> Windows-Schreibcache für das Gerät.

> Stimmt - Du willst mal wieder etwas widerlegen, was ich nie behauptet
> habe. Und dieser hier angebotene Cache lässt sich offensichtlich
> deaktivieren.

Das Thema war "Schreibcache". Das ist in *erster Linie* der von Windows
bereitgestellte Cache und nicht das, was du auf deinem Bild dort zeigst.
Der Mini-Cache, den Datenträger mit sich bringen, ist bei diesem Thema
vernachlässigbar. Ob dieser Cache nun aktiv ist oder nicht, ist recht
schnuppe. Wenn ich diesen Cache für die externe Platte deaktiviere, ergibt
sich daraus keine spürbare Änderung. Wenn ich allerdings den
Windows-Schreibcache für die Platte deaktiviere, wird die Sache dramatisch
zähflüssig.
Restliche Hullerei entsorgt.

Sherlock

unread,
Dec 27, 2014, 2:56:08 PM12/27/14
to
ha:

> Sherlock <sherl...@gmx.net> schrieb:
>> irgendwo hin. Wiederhole den Kopiervorgang sofort: Der zweite Kopiervorgang

> Du sagst es: SOFORT.
> Denn kurz darauf ist der Speicher ggf. mit anderem gefüllt.

Nein, ist er nicht. Nur dann, wenn Windows den Cache für neue Inhalte
braucht.

> Ich verstehe die Sache mit dem Cache aber so, das alle Zugriffe erstmal
> nur noch über das RAM ablaufen. Was da drin landet, bleibt erstmal drin.
> Und in Intervallen wird das dann auf die Platte übertragen.

Ein gepufferter Schreibvorgang wird im Hintergrund zeitnah auf den
Datenträger übertragen. Es gab auch Schreibcaches, für die man
benutzerdefiniert einen Verzögerungswert einstellen könnte. Dann wird eben
erst dann auf den Datenträger geschrieben, wenn dieser Zeitpunkt erreicht
ist.

> Sollten meine Tests etwa nur zufällig eine Verbesserung gebracht haben?

Welche Tests genau waren das denn?

> Willst du mir sagen, das die Option "Schreibcache auf dem Gerät
> aktivieren" NICHT bedeutet, das alle Schreibzugriffe erstmal im RAM
> stattfinden?

Richtig, das tun sie mit dieser Einstellung nicht.
Wie schon gesagt, diese Option hat nichts mit dem Schreibcache zu tun, den
Windows für das Gerät bereitstellt. Den Windows-Schreibcache kann man für
externe Datenträger mit der Einstellung "Schnelles Entfernen" (=Schreibcache
deaktiviert) oder "Bessere Leistung" (=Schreibcache aktiviert) einstellen.
Bei internen Platten ist der Schreibcache immer aktiv. Daran ändert die
Einstellung "Schreibcache auf dem Gerät aktivieren" nichts. Bei externen
Platten kann man beide Schreibcaches deaktivieren, wenn man will.

Helmut Hullen

unread,
Dec 27, 2014, 4:07:44 PM12/27/14
to
Hallo, Hans-Peter,

Du meintest am 27.12.14:

>>> Auch das begreifst du wohl nie: das ist nicht der
>>> Windows-Schreibcache für das Gerät.

>> Stimmt - Du willst mal wieder etwas widerlegen, was ich nie
>> behauptet habe. Und dieser hier angebotene Cache lässt sich
>> offensichtlich deaktivieren.

> Das Thema war "Schreibcache". Das ist in *erster Linie* der von
> Windows bereitgestellte Cache und nicht das, was du auf deinem Bild
> dort zeigst.

Ach was - "in erster Linie" schiebst Du jetzt klammheimlich nach, und
die Wertung ist zudem (wieder mal) frei erfunden.

> Der Mini-Cache, den Datenträger mit sich bringen, ist
> bei diesem Thema vernachlässigbar. Ob dieser Cache nun aktiv ist oder
> nicht, ist recht schnuppe. Wenn ich diesen Cache für die externe
> Platte deaktiviere, ergibt sich daraus keine spürbare Änderung. Wenn
> ich allerdings den Windows-Schreibcache für die Platte deaktiviere,
> wird die Sache dramatisch zähflüssig.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!

Sherlock

unread,
Dec 27, 2014, 4:21:14 PM12/27/14
to
Helmut Hullen:

>> Das Thema war "Schreibcache". Das ist in *erster Linie* der von
>> Windows bereitgestellte Cache und nicht das, was du auf deinem Bild
>> dort zeigst.

> Ach was - "in erster Linie" schiebst Du jetzt klammheimlich nach, und
> die Wertung ist zudem (wieder mal) frei erfunden.

Papperlapapp. Man kann nicht heimlich etwas nachschieben, was
Allgemeinwissen ist. Dass du sowas nicht weißt, ist eh klar.

ha

unread,
Dec 27, 2014, 4:54:18 PM12/27/14
to
Sherlock <sherl...@gmx.net> schrieb:

>> Sollten meine Tests etwa nur zufällig eine Verbesserung gebracht
>> haben?
>
> Welche Tests genau waren das denn?


Es geht um SecondLife. Es gibt Regionen, bei denen übermäßig oft
nachgeladen werden muss (Texturen, Sounds, Objekte).

Eine Region brachte mich dann zum Fluchen, weil der Viewer (das
Programm, mit dem man das System betritt) ständig hängen blieb.
Also für jeweils ein paar Sekunden nichts mehr tat.

Ich habe jetzt gerade erneut getestet: Der Unterschied ist deutlich!

Wie kann das sein, wenn es sich bei besagter Einstellung wirklich nur um
das Zuschalten eines vernachlässigbar kleinen Speichers innerhalb
des Laufwerkes handelt? "Vernachlässigbar kleiner Speicher" sage ich
aufgrund deiner Schilderung.



Ein anderer Test zeigt keinen Unterschied: Eine größere Datei von
einer Platte auf eine andere kopieren.








Helmut Hullen

unread,
Dec 28, 2014, 5:27:31 AM12/28/14
to
Hallo, Hans-Peter,

Du meintest am 27.12.14:

>>> Das Thema war "Schreibcache". Das ist in *erster Linie* der von
>>> Windows bereitgestellte Cache und nicht das, was du auf deinem Bild
>>> dort zeigst.

>> Ach was - "in erster Linie" schiebst Du jetzt klammheimlich nach,
>> und die Wertung ist zudem (wieder mal) frei erfunden.

> Papperlapapp. Man kann nicht heimlich etwas nachschieben, was
> Allgemeinwissen ist.

Erst jetzt differenzierst Du per "in erster Linie". Vorher hattest Du
die Allgemeingültigkeit Deiner (absurden) Nullzeit-Theorie suggeriert.

> Dass du sowas nicht weißt, ist eh klar.

Dir gebricht es mal wieder an inhaltlichen Argumenten.

Sherlock

unread,
Dec 29, 2014, 10:10:25 AM12/29/14
to
ha:

> Sherlock <sherl...@gmx.net> schrieb:

>>> Sollten meine Tests etwa nur zufällig eine Verbesserung gebracht
>>> haben?
>>
>> Welche Tests genau waren das denn?
>
>
> Es geht um SecondLife. Es gibt Regionen, bei denen übermäßig oft
> nachgeladen werden muss (Texturen, Sounds, Objekte).
>
> Eine Region brachte mich dann zum Fluchen, weil der Viewer (das
> Programm, mit dem man das System betritt) ständig hängen blieb.
> Also für jeweils ein paar Sekunden nichts mehr tat.
>
> Ich habe jetzt gerade erneut getestet: Der Unterschied ist deutlich!

Ist doch schön, dann lasse die Einstellung auf jeden Fall so.

> Wie kann das sein, wenn es sich bei besagter Einstellung wirklich nur um
> das Zuschalten eines vernachlässigbar kleinen Speichers innerhalb
> des Laufwerkes handelt? "Vernachlässigbar kleiner Speicher" sage ich
> aufgrund deiner Schilderung.
> Ein anderer Test zeigt keinen Unterschied: Eine größere Datei von
> einer Platte auf eine andere kopieren.

Ich habe hier testweise mal einen 10 GB großen Ordner mit 9000 Dateien auf
die externe USB-Platte kopiert, einmal mit aktiviertem Plattencache und
einmal ohne. Jeweils immer direkt nach Neustart, damit der
Windows-Lese/Schreibcache das Ergebnis nicht verfälschen kann.
Beide Vorgänge waren zeitlich gleich, Unterschied nur eine Sekunde.
Der Schreibcache der USB-Platte bringt da gar nichts.
Der Windows-Schreibcache hingegen hat die Kopierzeit beim dritten Versuch
dann glatt halbiert, weil der Ordner nun schon im Lesecache enthalten war.

Ganz anders sieht es bei der internen Platte aus, wenn beim Kopieren auf der
gleichen Platte gelesen und geschrieben werden muss. Hier bringt der
eingeschaltete Plattencache doch eine sehr deutliche Verbesserung mit sich.
Es wäre Idiotie, ihn abzuschalten.

Sherlock

unread,
Dec 29, 2014, 10:25:47 AM12/29/14
to
Helmut Hullen:

>>>> Das Thema war "Schreibcache". Das ist in *erster Linie* der von
>>>> Windows bereitgestellte Cache und nicht das, was du auf deinem Bild
>>>> dort zeigst.

>>> Ach was - "in erster Linie" schiebst Du jetzt klammheimlich nach,
>>> und die Wertung ist zudem (wieder mal) frei erfunden.

>> Papperlapapp. Man kann nicht heimlich etwas nachschieben, was
>> Allgemeinwissen ist.

> Erst jetzt differenzierst Du per "in erster Linie". Vorher hattest Du
> die Allgemeingültigkeit Deiner (absurden) Nullzeit-Theorie suggeriert.

>> Dass du sowas nicht weißt, ist eh klar.

> Dir gebricht es mal wieder an inhaltlichen Argumenten.

Nein, deine Antwort zeigt, dass du wie immer kein Wissen hast und zudem noch
merkbefreit bist. Nimm's leicht und sing deine Heimatlieder. :o)

Helmut Hullen

unread,
Dec 29, 2014, 12:01:41 PM12/29/14
to
Hallo, Sherlock,

Du meintest am 29.12.14:

>> Erst jetzt differenzierst Du per "in erster Linie". Vorher hattest
>> Du die Allgemeingültigkeit Deiner (absurden) Nullzeit-Theorie
>> suggeriert.

>>> Dass du sowas nicht weißt, ist eh klar.

>> Dir gebricht es mal wieder an inhaltlichen Argumenten.

> Nein, deine Antwort zeigt, dass du wie immer kein Wissen hast und
> zudem noch merkbefreit bist.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!

Helmut Hullen

unread,
Dec 29, 2014, 12:01:41 PM12/29/14
to
Hallo, Hans-Peter,

Du meintest am 29.12.14:


> Ich habe hier testweise mal einen 10 GB großen Ordner mit 9000
> Dateien auf die externe USB-Platte kopiert, einmal mit aktiviertem
> Plattencache und einmal ohne. Jeweils immer direkt nach Neustart,
> damit der Windows-Lese/Schreibcache das Ergebnis nicht verfälschen
> kann. Beide Vorgänge waren zeitlich gleich, Unterschied nur eine
> Sekunde. Der Schreibcache der USB-Platte bringt da gar nichts.

Sehr schön.

> Der Windows-Schreibcache hingegen hat die Kopierzeit beim dritten
> Versuch dann glatt halbiert, weil der Ordner nun schon im Lesecache
> enthalten war.

Wobei Du wieder mal mit "Kopierzeit" die irreführende Rückmeldung von
"robocopy" meinst; die USB-Platte darf dann noch lange nicht entfernt
werden.

Aber wenn diese (irreführende) Meldung immer noch eine deutlich von Null
verschiedene Zeit anzeigt, dann hast Du nicht genug RAM. Auch bei Deinen
32 GByte RAM passen offensichtlich die 10 GByte Daten nicht mehr
komplett in den Windows-Cache.

> Ganz anders sieht es bei der internen Platte aus, wenn beim Kopieren
> auf der gleichen Platte gelesen und geschrieben werden muss.

Klar - weil dann die Kopfbewegungen ein wenig reduziert werden können.

Die Zeiten wären übrigens gerade für diesen Fall bei einer SSD deutlich
kleiner.

Sherlock

unread,
Dec 29, 2014, 12:14:57 PM12/29/14
to
Helmut Hullen:

>> Ich habe hier testweise mal einen 10 GB großen Ordner mit 9000
>> Dateien auf die externe USB-Platte kopiert, einmal mit aktiviertem
>> Plattencache und einmal ohne. Jeweils immer direkt nach Neustart,
>> damit der Windows-Lese/Schreibcache das Ergebnis nicht verfälschen
>> kann. Beide Vorgänge waren zeitlich gleich, Unterschied nur eine
>> Sekunde. Der Schreibcache der USB-Platte bringt da gar nichts.

> Sehr schön.

>> Der Windows-Schreibcache hingegen hat die Kopierzeit beim dritten
>> Versuch dann glatt halbiert, weil der Ordner nun schon im Lesecache
>> enthalten war.

> Wobei Du wieder mal mit "Kopierzeit" die irreführende Rückmeldung von
> "robocopy" meinst;

Ich hatte dir doch Folgendes auferlegt:

Windows arbeitet mit "write-behind caching". Schreiboperationen sind für das
Win32-API wie auch das NT-API beendet, sobald die Daten im Cache stehen.
Drucke es dir aus, hänge es an jede Wand und lasse es dir in Spiegelschrift
an die Stirn tackern.

Befolge es endlich. Dann weißt du, dass der Kopierdialog von Windows nicht
irreführend ist! Das begreift sogar ein Hund, wenn man es ihm so oft sagt
wie dir!

> die USB-Platte darf dann noch lange nicht entfernt
> werden.

Du musst jetzt stark sein, ich habe keinen irrationalen Zwang, verbundene
Platten zu entfernen. Bei der internen Platte würde mir das eh schwer
fallen.

> Aber wenn diese (irreführende) Meldung immer noch eine deutlich von Null
> verschiedene Zeit anzeigt, dann hast Du nicht genug RAM. Auch bei Deinen
> 32 GByte RAM passen offensichtlich die 10 GByte Daten nicht mehr
> komplett in den Windows-Cache.

Auch das hatte ich dir schon x Mal erklärt.

>> Ganz anders sieht es bei der internen Platte aus, wenn beim Kopieren
>> auf der gleichen Platte gelesen und geschrieben werden muss.

> Klar - weil dann die Kopfbewegungen ein wenig reduziert werden können.

Du solltest dich besser um deine Kopfbewegungen kümmern. Sie sollten
deutlich reduziert werden.

> Die Zeiten wären übrigens gerade für diesen Fall bei einer SSD deutlich
> kleiner.

Was mit dem obigen Thema genau nichts zu tun hat.

ha

unread,
Dec 29, 2014, 12:21:50 PM12/29/14
to
Sherlock <sherl...@gmx.net> schrieb:

>> Ich habe jetzt gerade erneut getestet: Der Unterschied ist deutlich!
>
> Ist doch schön, dann lasse die Einstellung auf jeden Fall so.

Siehe unten ..

> Ganz anders sieht es bei der internen Platte aus, wenn beim Kopieren auf der
> gleichen Platte gelesen und geschrieben werden muss. Hier bringt der
> eingeschaltete Plattencache doch eine sehr deutliche Verbesserung mit sich.
> Es wäre Idiotie, ihn abzuschalten.

Ächz ! Damit wären wir endlich bei meiner eigentlichen Frage
(zurück)angelangt. Im Übrigen nanntest du diesen internen Plattencache
vor kurzem noch quasi überflüssig. Oder interpretiere ich dich fehl?

ich zitiere dich einmal:

"Der Mini-Cache, den Datenträger mit sich bringen, ist bei diesem Thema
vernachlässigbar. Ob dieser Cache nun aktiv ist oder nicht, ist recht
schnuppe."

Nun berichte ich von einer Verbesserung MIT diesem Schnuppecache und du
meinst, es sei idiotisch, den abzuschalten. Was denn nun ;-)

Davon, von internen Platten und von nichts anderem rede ich hier.
USB&Extern interessiert mich hier nicht.

Meine ursprüngliche Frage bezog sich auf ... nein, das wiederhole ich
jetzt nicht. Einfach mal im Eröffnungsbeitrag nachlesen, der Beitrag ist
noch da ;-)





Helmut Hullen

unread,
Dec 29, 2014, 12:25:46 PM12/29/14
to
Hallo, Hans-Peter,

Du meintest am 29.12.14:

>> Wobei Du wieder mal mit "Kopierzeit" die irreführende Rückmeldung
>> von "robocopy" meinst;

> Ich hatte dir doch Folgendes auferlegt:

> Windows arbeitet mit "write-behind caching". Schreiboperationen sind
> für das Win32-API wie auch das NT-API beendet, sobald die Daten im
> Cache stehen. Drucke es dir aus, hänge es an jede Wand und lasse es
> dir in Spiegelschrift an die Stirn tackern.

Du verallgemeinerst immer noch einen Sonderfall. Bei externen
Datenträgern ist dieser Cache abschaltbar, in der
"Entfernungsrichtlinie".

>> die USB-Platte darf dann noch lange nicht entfernt
>> werden.

> Du musst jetzt stark sein, ich habe keinen irrationalen Zwang,
> verbundene Platten zu entfernen. Bei der internen Platte würde mir
> das eh schwer fallen.

Du scheinst mal wieder Deine ganz speziellen Lebens- und
Arbeitsgewohnheiten verallgemeinern zu wollen.

Frank Möller

unread,
Dec 29, 2014, 1:34:42 PM12/29/14
to
ha schrieb am Mon, 29 Dec 2014 18:21:48 +0100:
> Sherlock <sherl...@gmx.net> schrieb:

>>> Ich habe jetzt gerade erneut getestet: Der Unterschied ist deutlich!

>> Ist doch schön, dann lasse die Einstellung auf jeden Fall so.

> Siehe unten ..

>> Ganz anders sieht es bei der internen Platte aus, wenn beim Kopieren auf der
>> gleichen Platte gelesen und geschrieben werden muss. Hier bringt der
>> eingeschaltete Plattencache doch eine sehr deutliche Verbesserung mit sich.
>> Es wäre Idiotie, ihn abzuschalten.

> Ächz ! Damit wären wir endlich bei meiner eigentlichen Frage
> (zurück)angelangt. Im Übrigen nanntest du diesen internen Plattencache
> vor kurzem noch quasi überflüssig. Oder interpretiere ich dich fehl?

Nimm diesen Fischdetektiv besser nicht so ernst, der widerspricht sich
regelmäßig mit größter Wonne.

> Davon, von internen Platten und von nichts anderem rede ich hier.
> USB&Extern interessiert mich hier nicht.

Dann stell deren Cache an und sei glücklich.

--

Helmut Hullen

unread,
Dec 29, 2014, 2:36:28 PM12/29/14
to
Hallo, Hans-Peter,

Du meintest am 29.12.14:

>> Ein anderer Test zeigt keinen Unterschied: Eine größere Datei von
>> einer Platte auf eine andere kopieren.

> Ich habe hier testweise mal einen 10 GB großen Ordner mit 9000
> Dateien auf die externe USB-Platte kopiert, einmal mit aktiviertem
> Plattencache und einmal ohne. Jeweils immer direkt nach Neustart,
> damit der Windows-Lese/Schreibcache das Ergebnis nicht verfälschen
> kann. Beide Vorgänge waren zeitlich gleich, Unterschied nur eine
> Sekunde. Der Schreibcache der USB-Platte bringt da gar nichts.
> Der Windows-Schreibcache hingegen hat die Kopierzeit beim dritten
> Versuch dann glatt halbiert, weil der Ordner nun schon im Lesecache
> enthalten war.

Ist hier nicht reproduzierbar. So wie auch Deine Behauptung über die
"Nullzeit", die 0,9 Sekunden dauert.

Mein Experiment (auf einem Thinkpad T410 mit einer Festplatte als Quelle
und einer SSD als Ziel) mit einer 2-GByte-Datei, unter Windows 7:

a) auf der SSD "bessere Leistung" sowie "Schreibcache auf dem
Datenträger" eingeschaltet, "robocopy" einmal mit der Option "/Bytes"
und einmal ohne sie gestartet, vor dem Aufruf jeweils die zu kopierende
Datei (wenn dort vorhanden) auf dem Ziel-Datenträger gelöscht.


-------------------------------------------------------------------------------
ROBOCOPY :: Robustes Dateikopieren für Windows
-------------------------------------------------------------------------------

Gestartet: Mon Dec 29 18:55:28 2014

Quelle : c:\Muell\
Ziel : d:\robo\

Dateien : Der rote*.m2p

Optionen: /BYTES /TEE /COPY:DAT /R:1000000 /W:30

------------------------------------------------------------------------------

1 c:\Muell\
Neue Datei 2149099832 Der rote Korsar_1952 (The Crimson Pirate).m2p

------------------------------------------------------------------------------

Insgesamt KopiertÜbersprungenKeine Übereinstimmung FEHLER Extras
Verzeich.: 1 0 1 0 0 0
Dateien: 1 1 0 0 0 0
Bytes: 2149099832 2149099832 0 0 0 0
Zeiten: 0:00:55 0:00:55 0:00:00 0:00:00


Geschwindigkeit: 38688362 Bytes/Sek.
Geschwindigkeit: 2213.765 Megabytes/Min.

Beendet: Mon Dec 29 18:56:24 2014

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
ROBOCOPY :: Robustes Dateikopieren fÜr Windows
-------------------------------------------------------------------------------

Gestartet: Mon Dec 29 19:09:13 2014

Quelle : c:\Muell\
Ziel : d:\robo\

Dateien : Der rote*.m2p

Optionen: /TEE /COPY:DAT /R:1000000 /W:30

------------------------------------------------------------------------------

1 c:\Muell\
Neue Datei 2.0 g Der rote Korsar_1952 (The Crimson Pirate).m2p


------------------------------------------------------------------------------

Insgesamt KopiertÜbersprungenKeine Übereinstimmung FEHLER Extras
Verzeich.: 1 0 1 0 0 0
Dateien: 1 1 0 0 0 0
Bytes: 2.001 g 2.001 g 0 0 0 0
Zeiten: 0:00:55 0:00:55 0:00:00 0:00:00


Geschwindigkeit: 39060338 Bytes/Sek.
Geschwindigkeit: 2235.050 Megabytes/Min.

Beendet: Mon Dec 29 19:10:09 2014

=====================================================================

Der Unterschied zwischen den beiden Kopier-Läufen ist minimal, die Kiste
ist offensichtlich auch ein wenig mit anderen Dingen beschäftigt.

Das gleiche Experiment mit der Entfernungs-Richtlinie "schnelles
Entfernen" für die SSD:


------------------------------------------------------------------------
-------
ROBOCOPY :: Robustes Dateikopieren für Windows
-------------------------------------------------------------------------------

Gestartet: Mon Dec 29 19:40:31 2014

Quelle : c:\muell\
Ziel : d:\robo\

Dateien : der rote*.m2p

Optionen: /BYTES /TEE /COPY:DAT /R:1000000 /W:30

------------------------------------------------------------------------------

1 c:\muell\
Neue Datei 2149099832 Der rote Korsar_1952 (The Crimson Pirate).m2p

------------------------------------------------------------------------------

Insgesamt KopiertÜbersprungenKeine Übereinstimmung FEHLER Extras
Verzeich.: 1 0 1 0 0 0
Dateien: 1 1 0 0 0 0
Bytes: 2149099832 2149099832 0 0 0 0
Zeiten: 0:00:57 0:00:57 0:00:00 0:00:00


Geschwindigkeit: 37131549 Bytes/Sek.
Geschwindigkeit: 2124.684 Megabytes/Min.

Beendet: Mon Dec 29 19:41:29 2014

-------------------------------------------------------------------------------
ROBOCOPY :: Robustes Dateikopieren für Windows
-------------------------------------------------------------------------------

Gestartet: Mon Dec 29 19:43:57 2014

Quelle : c:\muell\
Ziel : d:\robo\

Dateien : der rote*.m2p

Optionen: /TEE /COPY:DAT /R:1000000 /W:30

------------------------------------------------------------------------------

1 c:\muell\
Neue Datei 2.0 g Der rote Korsar_1952 (The Crimson Pirate).m2p

------------------------------------------------------------------------------

Insgesamt KopiertÜbersprungenKeine Übereinstimmung FEHLER Extras
Verzeich.: 1 0 1 0 0 0
Dateien: 1 1 0 0 0 0
Bytes: 2.001 g 2.001 g 0 0 0 0
Zeiten: 0:01:00 0:01:00 0:00:00 0:00:00


Geschwindigkeit: 35562870 Bytes/Sek.
Geschwindigkeit: 2034.923 Megabytes/Min.

Beendet: Mon Dec 29 19:44:58 2014


-------

Das dauert also ein wenig länger als das Kopieren mit der Option
"bessere Leistung", aber der Unterschied scheint (bei diesen
Nebenbedingungen) im Bereich von etwa 5% zu liegen.

Bemerkenswert ist, wie variabel Windows die Dateigrösse von
2.149.099.832 darstellt.


Und jetzt kommt der weitere Versuch, der gleich 2 Deiner seltsamen
Theorien falsifiziert:

Vorher hatte ich stets eine eventuell noch oder schon vorhandene Datei
dieses Namens und dieser Grösse auf dem Ziel-Datenträger gelöscht, schon
das reichte, um etwa gleiche Übertragungszeiten zu erhalten.

Wenn ich die von früheren Versuchen noch vorhandene Datei auf dem Ziel-
Datenträger lösche, dann zeigt auch mein System (scheinbar) "Nullzeit"
und behauptet, 2 GByte in 0 Sekunden kopiert zu haben:

------------------------------------------------------------------------
-------
ROBOCOPY :: Robustes Dateikopieren für Windows
-------------------------------------------------------------------------------

Gestartet: Mon Dec 29 19:45:01 2014

Quelle : c:\muell\
Ziel : d:\robo\

Dateien : der rote*.m2p

Optionen: /TEE /COPY:DAT /R:1000000 /W:30

------------------------------------------------------------------------------

1 c:\muell\

------------------------------------------------------------------------------

Insgesamt KopiertÜbersprungenKeine Übereinstimmung FEHLER Extras
Verzeich.: 1 0 1 0 0 0
Dateien: 1 0 1 0 0 0
Bytes: 2.001 g 0 2.001 g 0 0 0
Zeiten: 0:00:00 0:00:00 0:00:00 0:00:00

Beendet: Mon Dec 29 19:45:01 2014

-----------

Diese Meldung zeigt, dass diesmal 1 Datei beim Kopieren übersprungen
wurde (weil sie bereits auf dem Zieldatenträger vorhanden war). Das
passierte auch dann, wenn ich zwischendrin eine weitere Datei von etwa 5
GByte kopierte und somit den Windows-Cache sicherlich mit anderen Daten
überschreiben liess.

Auch eine eventuelle Datenkompression (bei SSD gern zur
Leistungssteigerung benutzt) ist in diesem Fall unwirksam: "*.m2p" als
Umbenennung einer "mpg"-Datei ist bereits kräftig komprimiert.

Und zu Deiner unsinnigen Behauptung, dass die vermeintliche "Nullzeit"
0,9 Sekunden lang sei:

die Option "/Bytes" bei "robocopy" zeigt, dass "robocopy" bei der
Ausgabe nur mit verschiedenen Maßvorsätzen (Binärpräfixen) jongliert:

http://de.wikipedia.org/wiki/Binärpräfix

und das macht hier so etwa 7 bis 10% aus.

Den Murks hat Microsoft schon bei der 3,5-Zoll-Diskette produziert: 1440
KByte = 1,44 MByte (oder auch nicht; Mischmasch von Binär- und SI-
Präfix).

-------------

Du hast also sowohl die Robocopy-Meldung fehlinterpretiert als auch die
Auswirkung des Windows-Cache

Sherlock

unread,
Dec 30, 2014, 9:31:37 AM12/30/14
to
ha:

>> Ganz anders sieht es bei der internen Platte aus, wenn beim Kopieren auf der
>> gleichen Platte gelesen und geschrieben werden muss. Hier bringt der
>> eingeschaltete Plattencache doch eine sehr deutliche Verbesserung mit sich.
>> Es wäre Idiotie, ihn abzuschalten.

> Ächz ! Damit wären wir endlich bei meiner eigentlichen Frage
> (zurück)angelangt. Im Übrigen nanntest du diesen internen Plattencache
> vor kurzem noch quasi überflüssig. Oder interpretiere ich dich fehl?

Das Wort "überflüssig" hatte ich wo genau verwendet?

> ich zitiere dich einmal:
> "Der Mini-Cache, den Datenträger mit sich bringen, ist bei diesem Thema
> vernachlässigbar. Ob dieser Cache nun aktiv ist oder nicht, ist recht
> schnuppe."

Das beruhte darauf, dass ich hier noch nie ein spürbares Plus an Performance
feststellen konnte, ob das Ding nun aus oder an war. Siehe den gerade
geposteten Test. Beide Kopierzeiten waren gleich.

> Nun berichte ich von einer Verbesserung MIT diesem Schnuppecache und du
> meinst, es sei idiotisch, den abzuschalten. Was denn nun ;-)

Das brachte mich zu einem weiteren Test mit der internen Platte und da war
dann tatsächlich eine spürbare Verbesserung da. Trotzdem bringt der
Schreibcache von Windows die dramatisch spürbare Verbesserung, nicht der
andere - wenn genug RAM da ist.

> Davon, von internen Platten und von nichts anderem rede ich hier.
> USB&Extern interessiert mich hier nicht.

> Meine ursprüngliche Frage bezog sich auf ... nein, das wiederhole ich
> jetzt nicht. Einfach mal im Eröffnungsbeitrag nachlesen, der Beitrag ist
> noch da ;-)

Da stand allgemein:

| Was haltet ihr von einem aktivierten Schreibcache (für die eingebauten
| Festplatten)?

Welchen der Caches meinte der Schreiber? Das wäre nur mit Kristallkugel
erkennbar gewesen.

Meine Antwort: "nur das Beste".
Im weiteren Verlauf verdichtete sich dann der Eindruck, dass du den
Unterschied gar nicht kanntest:

| > Wie willst du den Cache denn überhaupt deaktivieren? Die Einstellung
| > "Schreibcache auf dem Gerät aktivieren" ist NICHT der Schreibcache, den
| > Windows für das Gerät bereitstellt.
|
| Wie das ?

Das ergibt sich bei mir beim Nachlesen. ;-)

Sherlock

unread,
Dec 30, 2014, 9:32:41 AM12/30/14
to
Helmut Hullen:

>>> Wobei Du wieder mal mit "Kopierzeit" die irreführende Rückmeldung
>>> von "robocopy" meinst;

>> Ich hatte dir doch Folgendes auferlegt:

>> Windows arbeitet mit "write-behind caching". Schreiboperationen sind
>> für das Win32-API wie auch das NT-API beendet, sobald die Daten im
>> Cache stehen. Drucke es dir aus, hänge es an jede Wand und lasse es
>> dir in Spiegelschrift an die Stirn tackern.

> Du verallgemeinerst immer noch einen Sonderfall.

Nein, du hast zum "Schreibcache für Platte" ein Bild gepostet, das einen
Sonderfall darstellt. Ich hatte daraufhin geschrieben, dass es zweierlei
Arten von "Schreibcache für Platte" gibt.

> Bei externen
> Datenträgern ist dieser Cache abschaltbar, in der
> "Entfernungsrichtlinie".

<gähn>

>>> die USB-Platte darf dann noch lange nicht entfernt
>>> werden.

>> Du musst jetzt stark sein, ich habe keinen irrationalen Zwang,
>> verbundene Platten zu entfernen. Bei der internen Platte würde mir
>> das eh schwer fallen.

> Du scheinst mal wieder Deine ganz speziellen Lebens- und
> Arbeitsgewohnheiten verallgemeinern zu wollen.

Du bist wieder merkbefreit.

Sherlock

unread,
Dec 30, 2014, 9:56:42 AM12/30/14
to
Helmut Hullen:

>>> Ein anderer Test zeigt keinen Unterschied: Eine größere Datei von
>>> einer Platte auf eine andere kopieren.

>> Ich habe hier testweise mal einen 10 GB großen Ordner mit 9000
>> Dateien auf die externe USB-Platte kopiert, einmal mit aktiviertem
>> Plattencache und einmal ohne. Jeweils immer direkt nach Neustart,
>> damit der Windows-Lese/Schreibcache das Ergebnis nicht verfälschen
>> kann. Beide Vorgänge waren zeitlich gleich, Unterschied nur eine
>> Sekunde. Der Schreibcache der USB-Platte bringt da gar nichts.
>> Der Windows-Schreibcache hingegen hat die Kopierzeit beim dritten
>> Versuch dann glatt halbiert, weil der Ordner nun schon im Lesecache
>> enthalten war.

> Ist hier nicht reproduzierbar. So wie auch Deine Behauptung über die
> "Nullzeit", die 0,9 Sekunden dauert.

Das liegt, wie schon gesagt, an deiner Schrotthardware. Es kann also auch
nur auf entsprechend guter Hardware nachvollzogen werden, mit ebenso viel
RAM. Du wirst es auch in 100 Jahren nicht nachvollziehen können oder aber
sofort, sowie du dir entsprechende Hardware kaufst. :-)

[Viel überflüssigen Müll entsorgt.]

> Das dauert also ein wenig länger als das Kopieren mit der Option
> "bessere Leistung", aber der Unterschied scheint (bei diesen
> Nebenbedingungen) im Bereich von etwa 5% zu liegen.

Je nach Schrotthardware sind solche Ergebnisse durchaus normal.

> Und jetzt kommt der weitere Versuch, der gleich 2 Deiner seltsamen
> Theorien falsifiziert:
> Vorher hatte ich stets eine eventuell noch oder schon vorhandene Datei
> dieses Namens und dieser Grösse auf dem Ziel-Datenträger gelöscht, schon
> das reichte, um etwa gleiche Übertragungszeiten zu erhalten.

Dieses "etwa" ist auch bei Schrotthardware nicht weiter verwunderlich.

> Wenn ich die von früheren Versuchen noch vorhandene Datei auf dem Ziel-
> Datenträger lösche, dann zeigt auch mein System (scheinbar) "Nullzeit"
> und behauptet, 2 GByte in 0 Sekunden kopiert zu haben:

Auch das ist normal, nur ist MEINE "Nullzeit" NICHT auf diese Weise
entstanden. Dort war am Ziel keine Datei, die robocopy einfach nur
übersprungen hat. Das mit dem Überspringen ist auch völlig normal, wurde dir
hier auch schon öfter gesagt. Mal wieder dein Gedächtnis, sehr schlimm.

> Und zu Deiner unsinnigen Behauptung, dass die vermeintliche "Nullzeit"
> 0,9 Sekunden lang sei:

Das ergab sich aus der Transferrate von 2 GB/s und der Größe der Datei 2 GB.
Wie gesagt, Grundrechenarten. :-)

> Du hast also sowohl die Robocopy-Meldung fehlinterpretiert als auch die
> Auswirkung des Windows-Cache

<prust>
Ich war schon fast der Meinung, dass du hier nur trollen willst, aber deine
braven Experimente, die du hier vorgeführt hast, zeigen, dass du die ganze
Sache tatsächlich ernst meinst - und das ist schon sehr erschütternd. Sowas
ist mir im Usenet noch nie begegnet. Dir war nur wieder entfallen, dass die
kopierte Datei auch mit dem Explorer oder mit anderen Kopierprogrammen
ebenfalls in "Nullzeit" am Ziel erscheint. Für den Explorer hatte ich dir
sogar ein Bild mit einer Transferrate von 2,33 GB/s gepostet. Die 2-GB-Datei
MUSS also in "Nullzeit" kopiert werden bzw. in den genannten 0,9 Sekunden.

Fazit: Es sollte dir endlich mal einleuchten, dass du Kopiervorgänge mit
deiner Schrotthardware nicht verallgemeinern darfst. Das wird man allerdings
wohl nie erleben.

Helmut Hullen

unread,
Dec 30, 2014, 10:00:25 AM12/30/14
to
Hallo, Hans-Peter,

Du meintest am 30.12.14:

>> Du verallgemeinerst immer noch einen Sonderfall.

> Nein, du hast zum "Schreibcache für Platte" ein Bild gepostet, das
> einen Sonderfall darstellt. Ich hatte daraufhin geschrieben, dass es
> zweierlei Arten von "Schreibcache für Platte" gibt.

Und dass bei den Enfernungsrichtlinien je nach Datenträger sowohl der
Windows-Cache als auch der Cache auf dem Datenträger (wenn vorhanden)
schaltbar sind, hatte ich vorher schon mehrfach erwähnt. Bei neueren
externen Datenträgern (USB-Stick, SSD) wird des öfteren beides
angeboten.

Eben habe ich noch mal bei einem alten USB-Stick an einem Windows-7-
Rechner nachgeschaut: dort ist "sicheres Entfernen" vor-eingestellt, und
in der Erläuterung steht "Deaktiviert den Schreibcache auf dem
Datenträger und in Windows".

Ergibt sich auch aus einigen der weiteren Bilder unter

ftp://bs.hullen.de/Hullen/Cache/

auf die ich ebenfalls schon vor einigen Tagen hingewiesen habe und die
Du anscheinend schon vorher studiert hast.

Was wolltest Du noch gleich widerlegen?

Christian Potzinger

unread,
Dec 30, 2014, 10:01:01 AM12/30/14
to
Sherlock schrieb:

> Das liegt, wie schon gesagt, an deiner Schrotthardware. Es kann also
> auch nur auf entsprechend guter Hardware nachvollzogen werden, mit
> ebenso viel RAM. Du wirst es auch in 100 Jahren nicht nachvollziehen
> können oder aber sofort, sowie du dir entsprechende Hardware kaufst. :-)

FX-8350 (8 Kerner, 4 GHz), 32 GB RAM, 3x SSDs (1x 840 EVO,
2x 850 Pro). Deine Messwerte können auch darauf nicht nach-
vollzogen werden.
--
ryl: G'Kar

Sherlock

unread,
Dec 30, 2014, 10:07:08 AM12/30/14
to
Christian Potzinger:
Dann poste mal deine Messwerte. Kopiere eine 2-GB-Datei mit Robocopy.
Dann lösche die Datei am Ziel und kopiere sie erneut und poste wiederum das
Protokoll. Dann sehen wir weiter.

Helmut Hullen

unread,
Dec 30, 2014, 10:11:31 AM12/30/14
to
Hallo, Hans-Peter,

Du meintest am 30.12.14:


>> Ist hier nicht reproduzierbar. So wie auch Deine Behauptung über die
>> "Nullzeit", die 0,9 Sekunden dauert.

> Das liegt, wie schon gesagt, an deiner Schrotthardware. Es kann also
> auch nur auf entsprechend guter Hardware nachvollzogen werden, mit
> ebenso viel RAM.

Nein - Robocopy gibt (ohne die Option "/Bytes") mal Bytes an, und mal
GB. Mit (nach Norm) falsch geschriebenem Binärpräfix.

> Du wirst es auch in 100 Jahren nicht nachvollziehen
> können oder aber sofort, sowie du dir entsprechende Hardware kaufst.
> :-)

Beides falsch - Du interpretierst die Robocopy-Ausgabe immer noch
falsch. Benutz doch mal die Option "/Bytes", damit das Programm stets
mit dem gleichen Präfix arbeitet.

> Das ergab sich aus der Transferrate von 2 GB/s und der Größe der
> Datei 2 GB. Wie gesagt, Grundrechenarten. :-)

>> Du hast also sowohl die Robocopy-Meldung fehlinterpretiert als auch
>> die Auswirkung des Windows-Cache

> Ich war schon fast der Meinung, dass du hier nur trollen willst, aber
> deine braven Experimente, die du hier vorgeführt hast, zeigen, dass
> du die ganze Sache tatsächlich ernst meinst - und das ist schon sehr
> erschütternd.

Worauf beruht noch mal Deine kühne Behauptung, dass die Übertragung
tatsächlich 0,9 Sekunden dauere?

Sherlock

unread,
Dec 30, 2014, 10:12:41 AM12/30/14
to
Helmut Hullen:

>>> Du verallgemeinerst immer noch einen Sonderfall.

>> Nein, du hast zum "Schreibcache für Platte" ein Bild gepostet, das
>> einen Sonderfall darstellt. Ich hatte daraufhin geschrieben, dass es
>> zweierlei Arten von "Schreibcache für Platte" gibt.

> Und dass bei den Enfernungsrichtlinien je nach Datenträger sowohl der
> Windows-Cache als auch der Cache auf dem Datenträger (wenn vorhanden)
> schaltbar sind, hatte ich vorher schon mehrfach erwähnt. Bei neueren
> externen Datenträgern (USB-Stick, SSD) wird des öfteren beides
> angeboten.

Nein, das hattest du in deiner Antwort auf den OP nicht erwähnt. Du hattest
nur das Bild gepostet, das den Sonderfall von Schreibcache darstellt.

> Eben habe ich noch mal bei einem alten USB-Stick an einem Windows-7-
> Rechner nachgeschaut: dort ist "sicheres Entfernen" vor-eingestellt, und
> in der Erläuterung steht "Deaktiviert den Schreibcache auf dem
> Datenträger und in Windows".

Das ist normal. Wenn der Windows-Cache deaktiviert ist, ist die andere
Cache-Einstellung auch eh ausgegraut und inaktiv.

> Was wolltest Du noch gleich widerlegen?

Nun, ich hatte auf beide Caches hingewiesen, während du einen Sonderfall
verallgemeinert hattest.

Sherlock

unread,
Dec 30, 2014, 10:18:12 AM12/30/14
to
Helmut Hullen:

>>> Ist hier nicht reproduzierbar. So wie auch Deine Behauptung über die
>>> "Nullzeit", die 0,9 Sekunden dauert.

>> Das liegt, wie schon gesagt, an deiner Schrotthardware. Es kann also
>> auch nur auf entsprechend guter Hardware nachvollzogen werden, mit
>> ebenso viel RAM.

> Nein - Robocopy gibt (ohne die Option "/Bytes") mal Bytes an, und mal
> GB. Mit (nach Norm) falsch geschriebenem Binärpräfix.

Lötzinn, Robocopy zeigt die gleiche Transferrate wie der Windows-Explorer
und andere Kopierprogramme auch, nämlich die übliche Rate im RAM.

>> Ich war schon fast der Meinung, dass du hier nur trollen willst, aber
>> deine braven Experimente, die du hier vorgeführt hast, zeigen, dass
>> du die ganze Sache tatsächlich ernst meinst - und das ist schon sehr
>> erschütternd.

> Worauf beruht noch mal Deine kühne Behauptung, dass die Übertragung
> tatsächlich 0,9 Sekunden dauere?

Nun, wie lange dauert es denn, wenn man 2 GB mit einer Transferrate von ca.
2 GB/s kopiert?

Helmut Hullen

unread,
Dec 30, 2014, 10:55:50 AM12/30/14
to
Hallo, Hans-Peter,

Du meintest am 30.12.14:

>> Nein - Robocopy gibt (ohne die Option "/Bytes") mal Bytes an, und
>> mal GB. Mit (nach Norm) falsch geschriebenem Binärpräfix.

> Lötzinn, Robocopy zeigt die gleiche Transferrate wie der
> Windows-Explorer und andere Kopierprogramme auch, nämlich die übliche
> Rate im RAM.

Unfug. Gerade läuft auf einem meiner Laptops eine Kopieraktion, knapp 8
GByte übers Netz, per "Strg C" / "Strg V". Als verbleibende Zeit werden
derzeit Werte zwischen 16 und 40 Minuten angegeben. Das ist weit
entfernt von der "üblichen Rate im RAM".

>> Worauf beruht noch mal Deine kühne Behauptung, dass die Übertragung
>> tatsächlich 0,9 Sekunden dauere?

> Nun, wie lange dauert es denn, wenn man 2 GB mit einer Transferrate
> von ca. 2 GB/s kopiert?

Das dauert etwa 1 Sekunde, und nicht die von Dir neuerdings behaupteten
0,9 Sekunden. Eine Schreibrate von 2 GByte/s schafft keine Deiner
Festplatten. Und wenn Du auf einen externen Datenträger schreibst (oder
auf einen, bei dem "sicheres Entfernen" einschaltbar ist), dann benutzt
Windows den Windows-Cache nicht.

Das hatte ich Dir schon mehrfach erklärt. Du beharrst auf Deiner sehr
seltsamen Interpretation.

Helmut Hullen

unread,
Dec 30, 2014, 10:55:50 AM12/30/14
to
Hallo, Hans-Peter,

Du meintest am 30.12.14:

>>>> Du verallgemeinerst immer noch einen Sonderfall.

>>> Nein, du hast zum "Schreibcache für Platte" ein Bild gepostet, das
>>> einen Sonderfall darstellt. Ich hatte daraufhin geschrieben, dass
>>> es zweierlei Arten von "Schreibcache für Platte" gibt.

>> Und dass bei den Enfernungsrichtlinien je nach Datenträger sowohl
>> der Windows-Cache als auch der Cache auf dem Datenträger (wenn
>> vorhanden) schaltbar sind, hatte ich vorher schon mehrfach erwähnt.
>> Bei neueren externen Datenträgern (USB-Stick, SSD) wird des öfteren
>> beides angeboten.

> Nein, das hattest du in deiner Antwort auf den OP nicht erwähnt. Du
> hattest nur das Bild gepostet, das den Sonderfall von Schreibcache
> darstellt.

Einen der vielen Fälle. Für das, worüber der OP und ich sprachen,
reichte das.

>> Was wolltest Du noch gleich widerlegen?

> Nun, ich hatte auf beide Caches hingewiesen, während du einen
> Sonderfall verallgemeinert hattest.

Ich habe diesen einen Fall nicht verallgemeinert.

Sherlock

unread,
Dec 30, 2014, 11:28:52 AM12/30/14
to
Helmut Hullen:

>>> Nein - Robocopy gibt (ohne die Option "/Bytes") mal Bytes an, und
>>> mal GB. Mit (nach Norm) falsch geschriebenem Binärpräfix.

>> Lötzinn, Robocopy zeigt die gleiche Transferrate wie der
>> Windows-Explorer und andere Kopierprogramme auch, nämlich die übliche
>> Rate im RAM.

> Unfug. Gerade läuft auf einem meiner Laptops eine Kopieraktion, knapp 8
> GByte übers Netz, per "Strg C" / "Strg V". Als verbleibende Zeit werden
> derzeit Werte zwischen 16 und 40 Minuten angegeben. Das ist weit
> entfernt von der "üblichen Rate im RAM".

Das ist bei deiner Schrotthardware normal. Es ging um MEINEN Kopiervorgang
bzw. Kopiervorgänge auf GLEICHER Hardware, nicht um deinen.

>>> Worauf beruht noch mal Deine kühne Behauptung, dass die Übertragung
>>> tatsächlich 0,9 Sekunden dauere?

>> Nun, wie lange dauert es denn, wenn man 2 GB mit einer Transferrate
>> von ca. 2 GB/s kopiert?

> Das dauert etwa 1 Sekunde, und nicht die von Dir neuerdings behaupteten
> 0,9 Sekunden.

Prima, nun musst du nur noch erkennen, dass 0,9 Sekunden "etwa 1 Sekunde"
ist. Bekommst du auch das noch hin? Die Transferrate lag auch nicht exakt
bei 2,0 GB/s, sondern bei ca. 2 GB/s.

> Eine Schreibrate von 2 GByte/s schafft keine Deiner
> Festplatten.

Der SCHREIBVORGANG von einer Platte auf die andere oder innerhalb der Platte
verlief mit dieser Rate. Das ist die übliche Rate, wenn Lese- und
Schreibcache zusammenarbeiten - auf entsprechend guter Hardware.
Windows arbeitet mit "write-behind caching". Schreiboperationen sind für das
Win32-API wie auch das NT-API beendet, sobald die Daten im Cache stehen.
Drucke es dir aus, hänge es an jede Wand und lasse es dir in Spiegelschrift
an die Stirn tackern.

> Und wenn Du auf einen externen Datenträger schreibst (oder
> auf einen, bei dem "sicheres Entfernen" einschaltbar ist), dann benutzt
> Windows den Windows-Cache nicht.

Wenn der Cache für diesen Datenträger eingeschaltet ist, dann nutzt Windows
ihn auch. Bei mir ist für alle Datenträger Schreibcache aktiviert, intern
und extern. Das muss in eines Menschen Gehirn doch reinpassen.

> Das hatte ich Dir schon mehrfach erklärt. Du beharrst auf Deiner sehr
> seltsamen Interpretation.

Wenn man erklären will, muss man das erforderliche Wissen haben.
Ist ja nicht tragisch, wenn man keines hat, aber man sollte zumindest
dazulernen können.

Helmut Hullen

unread,
Dec 30, 2014, 12:59:20 PM12/30/14
to
Hallo, Hans-Peter,

Du meintest am 30.12.14:

>>> Lötzinn, Robocopy zeigt die gleiche Transferrate wie der
>>> Windows-Explorer und andere Kopierprogramme auch, nämlich die
>>> übliche Rate im RAM.

>> Unfug. Gerade läuft auf einem meiner Laptops eine Kopieraktion,
>> knapp 8 GByte übers Netz, per "Strg C" / "Strg V". Als verbleibende
>> Zeit werden derzeit Werte zwischen 16 und 40 Minuten angegeben. Das
>> ist weit entfernt von der "üblichen Rate im RAM".

> Das ist bei deiner Schrotthardware normal. Es ging um MEINEN
> Kopiervorgang bzw. Kopiervorgänge auf GLEICHER Hardware, nicht um
> deinen.

Ach - mal wieder ein Sonderfall, den Du gern verallgemeinern möchtest.

>>> Nun, wie lange dauert es denn, wenn man 2 GB mit einer Transferrate
>>> von ca. 2 GB/s kopiert?

>> Das dauert etwa 1 Sekunde, und nicht die von Dir neuerdings
>> behaupteten 0,9 Sekunden.

> Prima, nun musst du nur noch erkennen, dass 0,9 Sekunden "etwa 1
> Sekunde" ist. Bekommst du auch das noch hin? Die Transferrate lag
> auch nicht exakt bei 2,0 GB/s, sondern bei ca. 2 GB/s.

Noch mal: lass den Kopiervorgang mal mit der weiteren Option "/Bytes"
laufen und vergleiche die dann angezeigten Daten. Du fehlinterpretierst
die "GB"-Anzeige von Robocop.

>> Eine Schreibrate von 2 GByte/s schafft keine Deiner
>> Festplatten.

> Der SCHREIBVORGANG von einer Platte auf die andere oder innerhalb der
> Platte verlief mit dieser Rate.

Mit 2 GByte/s? Erstaunlich! Erst vor wenigen Tagen hattest Du erwähnt,
dass Deine Festplatte(n) eine Schreibrate von (nur) etwa 200 MByte/s
hätte(n).

> Das ist die übliche Rate, wenn Lese-
> und Schreibcache zusammenarbeiten - auf entsprechend guter Hardware.
> Windows arbeitet mit "write-behind caching". Schreiboperationen sind
> für das Win32-API wie auch das NT-API beendet, sobald die Daten im
> Cache stehen.

Und dieser Windows-Cache ist allemal bei den Datenträgern abschaltbar,
die von Windows als wechselbar betrachtet werden. Fällt unter die
Entfernungsrichtlinie "sicheres Entfernen".

Du willst mal wieder einen Spezialfall verallgemeinern.

>> Und wenn Du auf einen externen Datenträger schreibst (oder
>> auf einen, bei dem "sicheres Entfernen" einschaltbar ist), dann
>> benutzt Windows den Windows-Cache nicht.

> Wenn der Cache für diesen Datenträger eingeschaltet ist, dann nutzt
> Windows ihn auch. Bei mir ist für alle Datenträger Schreibcache
> aktiviert, intern und extern. Das muss in eines Menschen Gehirn doch
> reinpassen.

Demnach hast Du bei den wechselbaren Datenträgern die Vor-Einstellung
geändert.

ha

unread,
Dec 30, 2014, 1:08:22 PM12/30/14
to
Sherlock <sherl...@gmx.net> schrieb:


>> vor kurzem noch quasi überflüssig. Oder interpretiere ich dich
>> fehl?
>
> Das Wort "überflüssig" hatte ich wo genau verwendet?

Nicht wörtlich. Daher hatte ich oben geschrieben "quasi".

Und es bezog sich auf "vernachlässigbar" in diesem Zitat:

>> ich zitiere dich einmal: "Der Mini-Cache, den Datenträger mit sich
>> bringen, ist bei diesem Thema vernachlässigbar. Ob dieser Cache nun
>> aktiv ist oder nicht, ist recht schnuppe."

> Das brachte mich zu einem weiteren Test mit der internen Platte und
> da war dann tatsächlich eine spürbare Verbesserung da. Trotzdem
> bringt der Schreibcache von Windows die dramatisch spürbare
> Verbesserung, nicht der andere - wenn genug RAM da ist.

Das sind hier 16 GB, wovon im fraglichen Fall ca. 12 GB frei verfügbar
waren.

>> Meine ursprüngliche Frage bezog sich auf ... nein, das wiederhole
>> ich jetzt nicht. Einfach mal im Eröffnungsbeitrag nachlesen, der
>> Beitrag ist noch da ;-)
>
> Da stand allgemein:
>
> | Was haltet ihr von einem aktivierten Schreibcache (für die
> eingebauten | Festplatten)?
>
> Welchen der Caches meinte der Schreiber? Das wäre nur mit
> Kristallkugel erkennbar gewesen.

Das hätte ich vielleicht deutlicher sagen sollen. .. Das Windows Dateien
generell ins RAM holt, ist bekannt.

Aber meine Frage wies meiner Meinung nach deutlich darauf hin, worauf
ich mich bezog. Nämlich auf "Schreibvorgänge", die erstmal hauptsächlich
im RAM stattfinden und erst später tatsächlich auf dem Datenträger
verewigt werden. Das bringt die Geschwindigkeit. Das birgt aber eben
auch Gefahren. Und diese sind Grund für meine Zurückhaltung.


Der Screenshot von Helmut Hullen zeigt genau die Stelle, wo ich diese
Funktion (de)aktivieren kann. Von der Funktion spreche ich von Anfang
an ;-)



Sherlock

unread,
Dec 30, 2014, 4:03:33 PM12/30/14
to
ha:

> Aber meine Frage wies meiner Meinung nach deutlich darauf hin, worauf
> ich mich bezog. Nämlich auf "Schreibvorgänge", die erstmal hauptsächlich
> im RAM stattfinden und erst später tatsächlich auf dem Datenträger
> verewigt werden. Das bringt die Geschwindigkeit. Das birgt aber eben
> auch Gefahren. Und diese sind Grund für meine Zurückhaltung.

Es birgt eben nicht wirklich Gefahren. Beide Caches abzuschalten, den
Windows-Cache und den Geräte-Cache, wäre eine Schildbürger-Aktion.
Wenn der Strom ausfällt, kann das System trotzdem geschrottet sein, wenn man
Pech hat, auch ohne Cache.

> Der Screenshot von Helmut Hullen zeigt genau die Stelle, wo ich diese
> Funktion (de)aktivieren kann. Von der Funktion spreche ich von Anfang
> an ;-)

Da wären wir wieder Anfang. Was nützt dir das Deaktivieren des Gerätecaches,
wenn der von Windows bereitgestellte Schreibcache für den Datenträger dann
trotzdem noch aktiv ist, die Schreibvorgänge also erst mal im RAM
stattfinden - und in dem Moment fällt der Strom aus? Wenn der Strom mitten
im Schreibvorgang ganz ohne Cache ausfällt, kann auch Datenschrott
entstehen. Wer so überängstlich ist, sollte sich ein USV zulegen oder keine
Computer betreiben.

Sherlock

unread,
Dec 30, 2014, 4:14:16 PM12/30/14
to
Helmut Hullen:

>>>> Lötzinn, Robocopy zeigt die gleiche Transferrate wie der
>>>> Windows-Explorer und andere Kopierprogramme auch, nämlich die
>>>> übliche Rate im RAM.

>>> Unfug. Gerade läuft auf einem meiner Laptops eine Kopieraktion,
>>> knapp 8 GByte übers Netz, per "Strg C" / "Strg V". Als verbleibende
>>> Zeit werden derzeit Werte zwischen 16 und 40 Minuten angegeben. Das
>>> ist weit entfernt von der "üblichen Rate im RAM".

>> Das ist bei deiner Schrotthardware normal. Es ging um MEINEN
>> Kopiervorgang bzw. Kopiervorgänge auf GLEICHER Hardware, nicht um
>> deinen.

> Ach - mal wieder ein Sonderfall, den Du gern verallgemeinern möchtest.

Du redest wieder wirr. Du hattest von MEINEM "Sonderfall" behauptet, er sei
so nicht möglich. Das war nun mal völliger Nonsens. Er ist auf allen Geräten
mit gleicher Hardware so möglich. Das gilt allgemein. Auf Schrotthardware
ist er nicht möglich. Auch das gilt allgemein.

>>>> Nun, wie lange dauert es denn, wenn man 2 GB mit einer Transferrate
>>>> von ca. 2 GB/s kopiert?

>>> Das dauert etwa 1 Sekunde, und nicht die von Dir neuerdings
>>> behaupteten 0,9 Sekunden.

>> Prima, nun musst du nur noch erkennen, dass 0,9 Sekunden "etwa 1
>> Sekunde" ist. Bekommst du auch das noch hin? Die Transferrate lag
>> auch nicht exakt bei 2,0 GB/s, sondern bei ca. 2 GB/s.

> Noch mal: lass den Kopiervorgang mal mit der weiteren Option "/Bytes"
> laufen und vergleiche die dann angezeigten Daten. Du fehlinterpretierst
> die "GB"-Anzeige von Robocop.

Noch mal: das ist Unsinn und du bist merkbefreit. Lies die genannten Fakten
- Sinn entnehmend!

>>> Eine Schreibrate von 2 GByte/s schafft keine Deiner
>>> Festplatten.
>
>> Der SCHREIBVORGANG von einer Platte auf die andere oder innerhalb der
>> Platte verlief mit dieser Rate.

> Mit 2 GByte/s? Erstaunlich! Erst vor wenigen Tagen hattest Du erwähnt,
> dass Deine Festplatte(n) eine Schreibrate von (nur) etwa 200 MByte/s
> hätte(n).

Windows arbeitet mit "write-behind caching". Schreiboperationen sind für das
Win32-API wie auch das NT-API beendet, sobald die Daten im Cache stehen.
Drucke es dir aus, hänge es an jede Wand und lasse es dir in Spiegelschrift
an die Stirn tackern.

>> Das ist die übliche Rate, wenn Lese-
>> und Schreibcache zusammenarbeiten - auf entsprechend guter Hardware.
>> Windows arbeitet mit "write-behind caching". Schreiboperationen sind
>> für das Win32-API wie auch das NT-API beendet, sobald die Daten im
>> Cache stehen.

> Und dieser Windows-Cache ist allemal bei den Datenträgern abschaltbar,
> die von Windows als wechselbar betrachtet werden. Fällt unter die
> Entfernungsrichtlinie "sicheres Entfernen".

Ja, bei mir ist er aber NICHT abgeschaltet.

> Du willst mal wieder einen Spezialfall verallgemeinern.

Du willst immer noch meinen "Spezialfall" für unmöglich erklären.
Er ist aber allgemein auf ALLEN Geräten mit gleicher Hardware so möglich und
auch üblich, wenn Lese- und Schreibcache zusammenarbeiten.

>>> Und wenn Du auf einen externen Datenträger schreibst (oder
>>> auf einen, bei dem "sicheres Entfernen" einschaltbar ist), dann
>>> benutzt Windows den Windows-Cache nicht.

>> Wenn der Cache für diesen Datenträger eingeschaltet ist, dann nutzt
>> Windows ihn auch. Bei mir ist für alle Datenträger Schreibcache
>> aktiviert, intern und extern. Das muss in eines Menschen Gehirn doch
>> reinpassen.

> Demnach hast Du bei den wechselbaren Datenträgern die Vor-Einstellung
> geändert.

Latürnich, denn ich bin ja nen schlaues Kerlchen.

ha

unread,
Dec 30, 2014, 4:38:10 PM12/30/14
to
Sherlock <sherl...@gmx.net> schrieb:


> Da wären wir wieder Anfang. Was nützt dir das Deaktivieren des Gerätecaches,
> wenn der von Windows bereitgestellte Schreibcache für den Datenträger dann
> trotzdem noch aktiv ist, die Schreibvorgänge also erst mal im RAM
> stattfinden - und in dem Moment fällt der Strom aus? Wenn der Strom mitten
> im Schreibvorgang ganz ohne Cache ausfällt, kann auch Datenschrott
> entstehen. Wer so überängstlich ist, sollte sich ein USV zulegen oder keine
> Computer betreiben.


Wer solch abenteuerliche Ideen wie "überängstlich" in ernsthafte,
technisch interessante Fragen hineininterpretiert, der sollte sich mit
dem Beantworten mehr Zeit lassen. Denn Hineininterpretieren geschieht
meist aus Übereifer. Oder aus Dummheit. Und letzteres möchte ich bei dir
ausschliessen. ;-)


Vielleicht weißt du es noch nicht, aber es ist kommt vor, das
verschiedene Funktionen verschieden funktionieren. Wer nicht fragt,
stirbt dumm oder ist z.b. technisch desinteressiert.



Helmut Hullen

unread,
Dec 30, 2014, 5:12:22 PM12/30/14
to
Hallo, Hans-Peter,

Du meintest am 30.12.14:

>> Ach - mal wieder ein Sonderfall, den Du gern verallgemeinern
>> möchtest.

> Du redest wieder wirr. Du hattest von MEINEM "Sonderfall" behauptet,
> er sei so nicht möglich.

Die Robocopy-Meldung ist unsinnig. Deine Interpretation auch.

>> Noch mal: lass den Kopiervorgang mal mit der weiteren Option
>> "/Bytes" laufen und vergleiche die dann angezeigten Daten. Du
>> fehlinterpretierst die "GB"-Anzeige von Robocop.

> Noch mal: das ist Unsinn und du bist merkbefreit.

Du willst also mal wieder den simplen Versuch nicht durchführen, weil er
einige Deiner wilden Theorien erschüttern könnte.

Stattdessen diffamierst Du wieder -immer noch ein Zeichen dafür, dass es
Dir an Fakten gebricht.

Michael Stöhr

unread,
Dec 30, 2014, 5:49:28 PM12/30/14
to
ha <Henry_A...@Safe-mail.net> schrieb:

>Sherlock <sherl...@gmx.net> schrieb:
>
>
>> Da wären wir wieder Anfang. Was nützt dir das Deaktivieren des Gerätecaches,
>> wenn der von Windows bereitgestellte Schreibcache für den Datenträger dann
>> trotzdem noch aktiv ist, die Schreibvorgänge also erst mal im RAM
>> stattfinden - und in dem Moment fällt der Strom aus? Wenn der Strom mitten
>> im Schreibvorgang ganz ohne Cache ausfällt, kann auch Datenschrott
>> entstehen. Wer so überängstlich ist, sollte sich ein USV zulegen oder keine
>> Computer betreiben.
>
>
>Wer solch abenteuerliche Ideen wie "überängstlich" in ernsthafte,
>technisch interessante Fragen hineininterpretiert, der sollte sich mit
>dem Beantworten mehr Zeit lassen. Denn Hineininterpretieren geschieht
>meist aus Übereifer. Oder aus Dummheit. Und letzteres möchte ich bei dir
>ausschliessen. ;-)

ROTFL Du vielleicht, alle anderen hier aber eher nicht..... ;-))

ha

unread,
Jan 1, 2015, 3:06:18 AM1/1/15
to
Michael Stöhr <Familie...@web.de> schrieb:


>> meist aus Übereifer. Oder aus Dummheit. Und letzteres möchte ich
>> bei dir ausschliessen. ;-)
>
> ROTFL Du vielleicht, alle anderen hier aber eher nicht..... ;-))

Er ist übereifrig und übersieht manchmal die Feinheiten. Dabei bleibt er
aber umgänglich. Daher geht das für mich in Ordnung. Diesbzgl. gibt es
weitaus problematischere Leute hier ;-)

Und nicht zu vergessen: Der Gruppe ein "Frohes Jahr 2015"







Arno Welzel

unread,
Jan 2, 2015, 7:02:24 AM1/2/15
to
Am 2014-12-27 um 17:06 schrieb ha:

> Sherlock <sherl...@gmx.net> schrieb:
>
>
>> Wie willst du den Cache denn überhaupt deaktivieren? Die Einstellung
>> "Schreibcache auf dem Gerät aktivieren" ist NICHT der Schreibcache, den
>> Windows für das Gerät bereitstellt.
>
> Wie das ? Davon ging ich aus. Schon die Erklärung "vor Ort" weißt
> darauf hin, das es sich um genau den Cache handelt, zu dem ich fragte.

Nein, den Cache, den Du vermutlich meinst, ist der Cache, den Windows
selber verwaltet, um Dateioperationen zu beschleunigen. Dieser wird auch
beim *Lesen* von Dateien genutzt - größere Dateien werden, wenn mögich,
im RAM gehalten, so dass mehrfache Zugriffe darauf schneller erfolgen.

> Was soll diese Funktion denn sonst bedeuten?

Genau das, was sie sagt - manche Laufwerke, wie z.B. Festplatten, haben
eingebaute Cache-Speicher, je nach Größe des Laufwerks. Eine WD RED mit
2 TB hat z.B. 64 MB RAM für Caching eingebaut. Mit dieser Einstellung
kann man festlegen, ob der Cache im Laufwerk selbst genutzt werden soll,
oder nicht. Das sollte man ohne Not auch nicht abschalten - denn ohne
diesen lokalen Cache werden Festplatten stark verlangsamt.

Der Windows-eigene Cache wird z.B. bei USB-Sticks grundsätzlich nicht
benutzt - eben um zu vermeiden, dass bei einem vermeintlichen "Ende"
eines Schreibzugriffs der Anwender den USB-Stick abzieht, bevor der
Cache vollständig geschrieben wurde. Das wiederum kann man mit der
anderen Einstellung festlegen - wahlweise "für schnelles Entfernen"
optimieren (kein Cache) oder für schnellere Schreibzugriffe (mit Cache).


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

Arno Welzel

unread,
Jan 2, 2015, 7:06:35 AM1/2/15
to
Am 2014-12-27 um 18:11 schrieb Sherlock:
> ha:
>
>> Sherlock <sherl...@gmx.net> schrieb:
>
>>> Wie willst du den Cache denn überhaupt deaktivieren? Die Einstellung
>>> "Schreibcache auf dem Gerät aktivieren" ist NICHT der Schreibcache, den
>>> Windows für das Gerät bereitstellt.
>>
>> Wie das ? Davon ging ich aus. Schon die Erklärung "vor Ort" weißt
>> darauf hin, das es sich um genau den Cache handelt, zu dem ich fragte.
>>
>> Was soll diese Funktion denn sonst bedeuten?
>
> Nun, das, was da steht: "Schreibcache auf dem Gerät aktivieren"
> Das meint NICHT den Schreibcache, den Windows für die Platte bereitstellt.
> Ist ja auch per Test sofort erkennbar. Kopiere eine Datei auf der Platte
> irgendwo hin. Wiederhole den Kopiervorgang sofort: Der zweite Kopiervorgang
> wird erheblich schneller gehen, bei genug RAM sogar in "Nullzeit" ohne dass
> ein Kopierdialog erscheint. Daran siehst du, dass der Schreibcache von
> Windows aktiv ist, auch wenn du deine Einstellung deaktiviert hast.

Kannst Du bitte aufhören, von "Nullzeit" in diesem Kontext zu reden. Es
gibt nur sehr schnelle Vorgänge, die scheinbar "sofort" abgeschlossen
sind, weil der Zeitbedarf sehr gering ist.

Der Begriff "Nullzeit" hat eine völlig andere Bedeutung:

<http://de.wikipedia.org/wiki/Nullzeit>

Arno Welzel

unread,
Jan 2, 2015, 7:07:30 AM1/2/15
to
Am 2014-12-27 um 18:57 schrieb ha:

> Sherlock <sherl...@gmx.net> schrieb:
>
>
>> irgendwo hin. Wiederhole den Kopiervorgang sofort: Der zweite Kopiervorgang
>
> Du sagst es: SOFORT.
>
> Denn kurz darauf ist der Speicher ggf. mit anderem gefüllt.
>
> Ich verstehe die Sache mit dem Cache aber so, das alle Zugriffe erstmal
> nur noch über das RAM ablaufen. Was da drin landet, bleibt erstmal drin.
> Und in Intervallen wird das dann auf die Platte übertragen.
>
> Sollten meine Tests etwa nur zufällig eine Verbesserung gebracht haben?
>
> Willst du mir sagen, das die Option "Schreibcache auf dem Gerät
> aktivieren" NICHT bedeutet, das alle Schreibzugriffe erstmal im RAM
> stattfinden?

Korrekt. Der Windows-eigene Cache wird für Nicht-Wechseldatenträger
dadurch nicht beeinflusst.

Arno Welzel

unread,
Jan 2, 2015, 7:15:01 AM1/2/15
to
Am 2014-12-27 um 22:54 schrieb ha:
> Sherlock <sherl...@gmx.net> schrieb:
>
>>> Sollten meine Tests etwa nur zufällig eine Verbesserung gebracht
>>> haben?
>>
>> Welche Tests genau waren das denn?
>
>
> Es geht um SecondLife. Es gibt Regionen, bei denen übermäßig oft
> nachgeladen werden muss (Texturen, Sounds, Objekte).
>
> Eine Region brachte mich dann zum Fluchen, weil der Viewer (das
> Programm, mit dem man das System betritt) ständig hängen blieb.
> Also für jeweils ein paar Sekunden nichts mehr tat.
>
> Ich habe jetzt gerade erneut getestet: Der Unterschied ist deutlich!
>
> Wie kann das sein, wenn es sich bei besagter Einstellung wirklich nur um
> das Zuschalten eines vernachlässigbar kleinen Speichers innerhalb
> des Laufwerkes handelt? "Vernachlässigbar kleiner Speicher" sage ich
> aufgrund deiner Schilderung.

Möglicherweise führt Second Life hier sehr weit verteilte Zugriffe
durch, wo jeweils nur wenige MB Daten geladen werden. Der Controller in
der Festplatte ist aber bemüht, das Cache-RAMs auf der Festplatte
möglichst optimal zu nutzen - und wird ggf. immer 16, 32 oder 64 MB
Daten lesen, auch wenn nur ein paar Sektoren konkret angefordert werden.
Wenn nun z.B. 50x jeweils 1 MB angefordert wird, liest die Festplatte
mit aktivem Cache im Extremfall statt 50 MB Daten eben rund 3,2 GB, weil
sie 50x ihren Cache mit je 64 MB neu füllt.

In solchen Ausnahmefällen kann das Abschalten des Cache auf der
Festplatte in der Tat einen Vorteil bedeuten. Ich würde aber in solchen
Fällen eher gleich eine SSD in Betracht ziehen - da sind die
Zugriffszeiten gegenüber Festplatten praktisch nicht mehr messbar und es
macht in der Praxis keinen wesentlichen Unterschied, ob man nun 50 oder
100 einzelne, weit verteilt Blöcke liest oder eine einzelne große Datei.

Arno Welzel

unread,
Jan 2, 2015, 7:17:28 AM1/2/15
to
Korrektur: Meine Aussage gilt natürlich auch in anderer Richtung - also
wenn die Festplatte häufig Daten laden muss, die Sie dann direkt aus
ihrem Cache liefern kann, statt jedesmal den Sektor lesen zu müssen, ist
der Cache natürlich sinnvoll.

Sherlock

unread,
Jan 2, 2015, 2:29:50 PM1/2/15
to
Michael Stöhr:

> ROTFL Du vielleicht, alle anderen hier aber eher nicht..... ;-))

Sagen wir mal so: alle anderen einer gewissen Teilmenge mit einem bestimmten
Geisteszustand. Da hast du auf jeden Fall Recht. <eg>

Sherlock

unread,
Jan 2, 2015, 2:57:04 PM1/2/15
to
Arno Welzel:

> Kannst Du bitte aufhören, von "Nullzeit" in diesem Kontext zu reden. Es
> gibt nur sehr schnelle Vorgänge, die scheinbar "sofort" abgeschlossen
> sind, weil der Zeitbedarf sehr gering ist.
> Der Begriff "Nullzeit" hat eine völlig andere Bedeutung:
> <http://de.wikipedia.org/wiki/Nullzeit>

Nein, in deinem netten Artikel ist von Nullzeit die Rede, nicht von
"Nullzeit". Ich habe es ganz bewusst in "" gesetzt, weil es eben nicht
wirklich Nullzeit ist, sondern von Robocopy als solche ausgewiesen wird, da
die Zeit unterhalb einer Sekunde liegt. Du möchtest dir überlegen, was die
"" bedeuten.

Sherlock

unread,
Jan 2, 2015, 2:57:04 PM1/2/15
to
Helmut Hullen:

>>> Ach - mal wieder ein Sonderfall, den Du gern verallgemeinern
>>> möchtest.

>> Du redest wieder wirr. Du hattest von MEINEM "Sonderfall" behauptet,
>> er sei so nicht möglich.

> Die Robocopy-Meldung ist unsinnig. Deine Interpretation auch.

Nein, sie entspricht genau der Arbeitsweise des Windows-Caches.
Dies zeigt auch sehr schön der Kopierdialog des Windows-Explorers.
http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
Bei einer Transferrate von 2 GB/s MUSS eine 2 GB große Datei in einer
Sekunde kopiert sein. Jeder Blinde mit Krückstock erkennt das, nur du nicht.
Deine Meinung dazu ist unsinning. Das beruht auf deinem Unwissen und deiner
Merkbefreiung. Aber vermutlich ist laut Hullen ja auch der Windows-Explorer
kaputt, nicht nur robocopy, hm? <eg>

Helmut Hullen

unread,
Jan 2, 2015, 3:28:48 PM1/2/15
to
Hallo, Hans-Peter,

Du meintest am 02.01.15:
Du wiederholst Unsinn. Robocopy behauptet "0 Sekunden", wenn einige
Nebenbedinmgungen zutreffen. Die von Dir neuerdings damit verkoppelten
0,9 Sekunden sind nur Folge der Vermischung von Binär- und SI-Präfixen
bei den Grössenangaben.

Helmut Hullen

unread,
Jan 2, 2015, 3:28:50 PM1/2/15
to
Hallo, Hans-Peter,

Du meintest am 02.01.15:

> Helmut Hullen:

>>>> Ach - mal wieder ein Sonderfall, den Du gern verallgemeinern
>>>> möchtest.

>>> Du redest wieder wirr. Du hattest von MEINEM "Sonderfall"
>>> behauptet, er sei so nicht möglich.

>> Die Robocopy-Meldung ist unsinnig. Deine Interpretation auch.

> Nein, sie entspricht genau der Arbeitsweise des Windows-Caches.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!


> Dies zeigt auch sehr schön der Kopierdialog des Windows-Explorers.
> http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
> Bei einer Transferrate von 2 GB/s MUSS eine 2 GB große Datei in einer
> Sekunde kopiert sein.

Und "robocopy" zeigt (unsinnigerweise) 0 Sekunden an, wenn/weil bei
Deinem System wegen einer absonderlichen Vorgeschichte die gesamte Datei
bereits von der Quell-Platte in den Cache geschoben war..

Das von Dir genannte Bild zeigt keine Transferrate von 2 GByte/s,
sondern den Anfang einer länger dauernden Kopieraktion, bei der sich
irgendwann die Schreibrate der Zielplatte durchsetzen wird - auch solche
Bilder über den weiteren Ablauf des Kopierens einer 8-GByte-Datei
hattest Du ja schon mal gezeigt, z.B. "kopierenzwr5m1jxq0.jpg".

Zudem wäre es ausgesprochen hilfreich, wenn auf der waagerechten Achse
des Bildes auch Zeiten eingetragen wären.

> Jeder Blinde mit Krückstock erkennt das, nur du nicht.

Falsche Theorie - falsche Schlussfolgerung.
Du irrst immer noch.

Sherlock

unread,
Jan 2, 2015, 3:49:27 PM1/2/15
to
Helmut Hullen:

>>>>> Ach - mal wieder ein Sonderfall, den Du gern verallgemeinern
>>>>> möchtest.

>>>> Du redest wieder wirr. Du hattest von MEINEM "Sonderfall"
>>>> behauptet, er sei so nicht möglich.

>>> Die Robocopy-Meldung ist unsinnig. Deine Interpretation auch.

>> Nein, sie entspricht genau der Arbeitsweise des Windows-Caches.

>>>>>>>>>>>>>>>>>>>>> Nein!

Das war eh schon immer klar: du hast keine Ahnung von der Arbeitsweise des
Lese/Schreibcaches.

>> Dies zeigt auch sehr schön der Kopierdialog des Windows-Explorers.
>> http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
>> Bei einer Transferrate von 2 GB/s MUSS eine 2 GB große Datei in einer
>> Sekunde kopiert sein.

> Und "robocopy" zeigt (unsinnigerweise) 0 Sekunden an,

Daran ist nichts unsinnig. Bei einer Genauigkeit auf die volle Sekunde wird
0,x Sekunden eben als 0 angezeigt.

> wenn/weil bei
> Deinem System wegen einer absonderlichen Vorgeschichte die gesamte Datei
> bereits von der Quell-Platte in den Cache geschoben war..

Wenn Lese- und Schreibcache zusammenarbeiten. Dies ist nicht absonderlich,
sondern vielfacher Normalfall in Windows. Das macht die Performance des
Systems aus, sofern die Hardware es zulässt. Es ist auch nicht absonderlich,
dass eine runtergeladene Datei automatisch im Cache ist. Auch das ist
normal!

> Das von Dir genannte Bild zeigt keine Transferrate von 2 GByte/s,

Richtig, es zeigt deutlich 2,33 GB/s an, also sogar mehr!

> sondern den Anfang einer länger dauernden Kopieraktion, - auch solche
> Bilder über den weiteren Ablauf des Kopierens einer 8-GByte-Datei
> hattest Du ja schon mal gezeigt, z.B. "kopierenzwr5m1jxq0.jpg".

Das Bild zeigt den Anfang der Kopieraktion einer 8 GB-Datei. Das hält an bis
50%. Wenn also 4 GB locker in den Schreibcache passen, weiß jeder, der nicht
Hullen ist, dass dies bei 2 GB also erst recht zutrifft und die GB also in
besagter Sekunde kopiert sind.

> bei der sich irgendwann die Schreibrate der Zielplatte durchsetzen wird

Nein, weder bei 8 noch bei 2 GB!
<recycle>
Windows arbeitet mit "write-behind caching". Schreiboperationen sind für das
Win32-API wie auch das NT-API beendet, sobald die Daten im Cache stehen.
Drucke es dir aus, hänge es an jede Wand und lasse es dir in Spiegelschrift
an die Stirn tackern.
Die Schreibrate der Platte ist für den Schreibvorgang irrelevant! Sowohl
8 GB als auch 2 GB sind bei Zusammenspiel von Lese/Schreibcache wesentlich
schneller kopiert als ohne Cache.

> Zudem wäre es ausgesprochen hilfreich, wenn auf der waagerechten Achse
> des Bildes auch Zeiten eingetragen wären.

Nein, das wäre nicht hilfreich.

Sherlock

unread,
Jan 2, 2015, 3:51:56 PM1/2/15
to
Helmut Hullen:

>>> Kannst Du bitte aufhören, von "Nullzeit" in diesem Kontext zu reden.
>>> Es gibt nur sehr schnelle Vorgänge, die scheinbar "sofort"
>>> abgeschlossen sind, weil der Zeitbedarf sehr gering ist.
>>> Der Begriff "Nullzeit" hat eine völlig andere Bedeutung:
>>> <http://de.wikipedia.org/wiki/Nullzeit>

>> Nein, in deinem netten Artikel ist von Nullzeit die Rede, nicht von
>> "Nullzeit". Ich habe es ganz bewusst in "" gesetzt, weil es eben
>> nicht wirklich Nullzeit ist, sondern von Robocopy als solche
>> ausgewiesen wird, da die Zeit unterhalb einer Sekunde liegt.
>
> Du wiederholst Unsinn.

Du bist merkbefreit.

> Robocopy behauptet "0 Sekunden", wenn einige
> Nebenbedinmgungen zutreffen.

Richtig, nämlich wenn Lese- und Schreibcache zusammenarbeiten.

> Die von Dir neuerdings damit verkoppelten
> 0,9 Sekunden sind nur Folge der Vermischung von Binär- und SI-Präfixen
> bei den Grössenangaben.

Lötzinn. Sie sind die Folge aus Größe der Datei und Transferrate.

Helmut Hullen

unread,
Jan 2, 2015, 4:36:29 PM1/2/15
to
Hallo, Hans-Peter,

Du meintest am 02.01.15:

>>>> Die Robocopy-Meldung ist unsinnig. Deine Interpretation auch.

>>> Nein, sie entspricht genau der Arbeitsweise des Windows-Caches.

>>>>>>>>>>>>>>>>>>>>>> Nein!

> Das war eh schon immer klar: du hast keine Ahnung von der
> Arbeitsweise des Lese/Schreibcaches.

Du irrst immer noch.

>>> Dies zeigt auch sehr schön der Kopierdialog des Windows-Explorers.
>>> http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
>>> Bei einer Transferrate von 2 GB/s MUSS eine 2 GB große Datei in
>>> einer Sekunde kopiert sein.

>> Und "robocopy" zeigt (unsinnigerweise) 0 Sekunden an,

> Daran ist nichts unsinnig. Bei einer Genauigkeit auf die volle
> Sekunde wird 0,x Sekunden eben als 0 angezeigt.

Immer noch falsch interpretiert.

Sind es nun (nach Deiner absurden Theorie) 0,9 Sekunden oder vielleicht
nur 0,5 Sekunden?

>> wenn/weil bei
>> Deinem System wegen einer absonderlichen Vorgeschichte die gesamte
>> Datei bereits von der Quell-Platte in den Cache geschoben war..

> Wenn Lese- und Schreibcache zusammenarbeiten. Dies ist nicht
> absonderlich, sondern vielfacher Normalfall in Windows.

In anderen Zusammenhängen: mag sein.

Beim Kopieren grosser Dateien von einem Datenträger zu einem anderen
Datenträger: abschaltbar. Bei externen Datenträger ist von Windows "kein
Windows-Cache" vor-eingestellt.

> Das macht die
> Performance des Systems aus, sofern die Hardware es zulässt.

Und sofern Windows die Benutzung des Windows-Cache nicht abgeschaltet
hat.

Etliche Nebenbedingungen, die nicht unbedingt allesamt zutreffen. Und
darauf baust Du eine Theorie auf, die Du als allgemeingültig
suggerierst.

Rosstäuscherei.

> Es ist auch nicht absonderlich, dass eine runtergeladene Datei
> automatisch im Cache ist. Auch das ist normal!

Andere Baustelle.
Trifft fürs Kopieren von einem Datenträger zu einem anderen nicht zu. Du
eierst herum.

>> Das von Dir genannte Bild zeigt keine Transferrate von 2 GByte/s,

> Richtig, es zeigt deutlich 2,33 GB/s an, also sogar mehr!

Zu Beginn der Kopiererei. Für irgendeine kurze Zeit.

>> sondern den Anfang einer länger dauernden Kopieraktion, - auch
>> solche Bilder über den weiteren Ablauf des Kopierens einer
>> 8-GByte-Datei hattest Du ja schon mal gezeigt, z.B.
>> "kopierenzwr5m1jxq0.jpg".

> Das Bild zeigt den Anfang der Kopieraktion einer 8 GB-Datei. Das hält
> an bis 50%. Wenn also 4 GB locker in den Schreibcache passen, weiß
> jeder, der nicht Hullen ist, dass dies bei 2 GB also erst recht
> zutrifft und die GB also in besagter Sekunde kopiert sind.

Sie ist noch lange nicht auf dem Ziel-Datenträger angekommen.

Helmut Hullen

unread,
Jan 2, 2015, 4:36:30 PM1/2/15
to
Hallo, Hans-Peter,

Du meintest am 02.01.15:

>> Die von Dir neuerdings damit verkoppelten
>> 0,9 Sekunden sind nur Folge der Vermischung von Binär- und
>> SI-Präfixen bei den Grössenangaben.

> Lötzinn. Sie sind die Folge aus Größe der Datei und Transferrate.

Nein - lass den von Dir gezeigten Kopiervorgang doch noch mal mit der
zusätzlichen "robocopy"-Option "/Bytes" durchlaufen. Hatte ich Dir schon
mehrfach empfohlen - Du magst das Ergebnis anscheinend nicht produzieren
und dann zeigen.

Sherlock

unread,
Jan 3, 2015, 8:53:53 AM1/3/15
to
Helmut Hullen:

[viel Nonsens entsorgt]

Du musst nur rechnen können.
Transferrate = 2,33 GB/s
Dateigröße = 2 GB
Wie lange dauert der Kopiervorgang?
Jeder Grundschüler kann das.

Sherlock

unread,
Jan 3, 2015, 8:56:37 AM1/3/15
to
Helmut Hullen:

>>> Die von Dir neuerdings damit verkoppelten
>>> 0,9 Sekunden sind nur Folge der Vermischung von Binär- und
>>> SI-Präfixen bei den Grössenangaben.

>> Lötzinn. Sie sind die Folge aus Größe der Datei und Transferrate.

> Nein - lass den von Dir gezeigten Kopiervorgang doch noch mal mit der
> zusätzlichen "robocopy"-Option "/Bytes" durchlaufen. Hatte ich Dir schon
> mehrfach empfohlen - Du magst das Ergebnis anscheinend nicht produzieren
> und dann zeigen.

Plapperdiblubb. Die Größe der Datei bleibt dann immer noch 2 GB.
Und die Kopiergeschwindigkeit im Cache bleibt immer noch 2,33 GB/s.
Egal, mit welcher Option man die Datei kopiert.

Helmut Hullen

unread,
Jan 3, 2015, 11:08:26 AM1/3/15
to
Hallo, Hans-Peter,

Du meintest am 03.01.15:

> [viel Nonsens entsorgt]

> Du musst nur rechnen können.
> Transferrate = 2,33 GB/s
> Dateigröße = 2 GB
> Wie lange dauert der Kopiervorgang?

Hat aber nichts mit dem von Dir gezeigten Bild

http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg

zu tun. Du eierst mal wieder herum.

Helmut Hullen

unread,
Jan 3, 2015, 11:08:26 AM1/3/15
to
Hallo, Hans-Peter,

Du meintest am 03.01.15:

>> Nein - lass den von Dir gezeigten Kopiervorgang doch noch mal mit
>> der zusätzlichen "robocopy"-Option "/Bytes" durchlaufen. Hatte ich
>> Dir schon mehrfach empfohlen - Du magst das Ergebnis anscheinend
>> nicht produzieren und dann zeigen.

> Plapperdiblubb. Die Größe der Datei bleibt dann immer noch 2 GB.
> Und die Kopiergeschwindigkeit im Cache bleibt immer noch 2,33 GB/s.
> Egal, mit welcher Option man die Datei kopiert.

Du mischt 2 Kopiervorgänge.

In

http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg


hast Du gezeigt, dass robocopy zu Beginn der Kopiererei von etwa 8 GByte
auch mal 2,33 GByte/s meldet. Später reduziert sich die Übertragungsrate
auf weniger als 200 MByte/s.

Am 22. Dezember 2014 (also vor knapp 2 Wochen) hast Du in

<news:cfrb9l...@mid.uni-berlin.de>

die Robocopy-Meldung


Insgesamt Kopiert
Dateien: 1 1
Bytes: 2.002 g 2.002 g
Zeiten: 0:00:00 0:00:00
Geschwindigkeit: 2190115106 Bytes/Sek.


gezeigt - nix mit 233 GByte/s. Sondern mal mit Binär-Präfix, mal ohne
Präfix.

Sherlock

unread,
Jan 3, 2015, 2:03:54 PM1/3/15
to
Helmut Hullen:

>>> Nein - lass den von Dir gezeigten Kopiervorgang doch noch mal mit
>>> der zusätzlichen "robocopy"-Option "/Bytes" durchlaufen. Hatte ich
>>> Dir schon mehrfach empfohlen - Du magst das Ergebnis anscheinend
>>> nicht produzieren und dann zeigen.

>> Plapperdiblubb. Die Größe der Datei bleibt dann immer noch 2 GB.
>> Und die Kopiergeschwindigkeit im Cache bleibt immer noch 2,33 GB/s.
>> Egal, mit welcher Option man die Datei kopiert.

> Du mischt 2 Kopiervorgänge.
> In
> http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
> hast Du gezeigt, dass robocopy zu Beginn der Kopiererei von etwa 8 GByte
> auch mal 2,33 GByte/s meldet. Später reduziert sich die Übertragungsrate
> auf weniger als 200 MByte/s.

Richtig, und bei Dateigrößen um 2 GB liegen die 2,33 GB/s eben während des
gesamten Kopiervorganges an. Deshalb die 0,9 Sekunden. Das war ja einfach.

> Am 22. Dezember 2014 (also vor knapp 2 Wochen) hast Du in
>
> <news:cfrb9l...@mid.uni-berlin.de>
>
> die Robocopy-Meldung
>
>
> Insgesamt Kopiert
> Dateien: 1 1
> Bytes: 2.002 g 2.002 g
> Zeiten: 0:00:00 0:00:00
> Geschwindigkeit: 2190115106 Bytes/Sek.
> gezeigt - nix mit 233 GByte/s. Sondern mal mit Binär-Präfix, mal ohne
> Präfix.

233 GB/s hast du frei erfunden. Rechne einfach mal
2190115106 Bytes/Sek. in GB/s um, falls du das hinbekommst.
Das ist dann frei nach Hullen was?

Sherlock

unread,
Jan 3, 2015, 2:03:56 PM1/3/15
to
Helmut Hullen:

>> [viel Nonsens entsorgt]
>
>> Du musst nur rechnen können.
>> Transferrate = 2,33 GB/s
>> Dateigröße = 2 GB
>> Wie lange dauert der Kopiervorgang?

> Hat aber nichts mit dem von Dir gezeigten Bild
> http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
> zu tun. Du eierst mal wieder herum.

Doch, genau damit hat es zu tun. Dieses Bild zeigt sich immer beim Kopieren
unter Mitwirkung des Cache. Wobei die Sache bei Größen von nur 2 GB nur 0,9
Sekunden dauert. Das ist zu schnell für den Explorer. Bei solchen Zeiten
zeigt er keinen Kopierdialog mehr an. Die Datei erscheint einfach nur sofort
im Ziel. Du bist weiterhin stur merkbefreit.

Helmut Hullen

unread,
Jan 3, 2015, 2:22:05 PM1/3/15
to
Hallo, Hans-Peter,

Du meintest am 03.01.15:

Nein - Komma vergessen. Sorry.

> Rechne einfach mal
> 2190115106 Bytes/Sek. in GB/s um, falls du das hinbekommst.
> Das ist dann frei nach Hullen was?

Bei GByte: 2,190 GByte/s.

Bei GibiByte: 2,04 GiByte/s.

Siehe auch

<http://de.wikipedia.org/wiki/Byte#Bedeutungen_von_Dezimal-_und_Binärpräfixen_für_große_Anzahlen_von_Bytes>

Helmut Hullen

unread,
Jan 3, 2015, 2:22:05 PM1/3/15
to
Hallo, Hans-Peter,

Du meintest am 03.01.15:

>>> Du musst nur rechnen können.
>>> Transferrate = 2,33 GB/s
>>> Dateigröße = 2 GB
>>> Wie lange dauert der Kopiervorgang?

>> Hat aber nichts mit dem von Dir gezeigten Bild
>> http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
>> zu tun. Du eierst mal wieder herum.

> Doch, genau damit hat es zu tun. Dieses Bild zeigt sich immer beim
> Kopieren unter Mitwirkung des Cache.

Nur dann, wenn etliche Nebenbedingungen erfüllt sind. Also nicht
"immer", sondern nur gelegentlich.

> Wobei die Sache bei Größen von
> nur 2 GB nur 0,9 Sekunden dauert. Das ist zu schnell für den
> Explorer. Bei solchen Zeiten zeigt er keinen Kopierdialog mehr an.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!

Sherlock

unread,
Jan 3, 2015, 4:17:43 PM1/3/15
to
Helmut Hullen:

>>>> Du musst nur rechnen können.
>>>> Transferrate = 2,33 GB/s
>>>> Dateigröße = 2 GB
>>>> Wie lange dauert der Kopiervorgang?

>>> Hat aber nichts mit dem von Dir gezeigten Bild
>>> http://www.fotos-hochladen.net/uploads/kopieren8gbemplwy84rz.jpg
>>> zu tun. Du eierst mal wieder herum.

>> Doch, genau damit hat es zu tun. Dieses Bild zeigt sich immer beim
>> Kopieren unter Mitwirkung des Cache.

> Nur dann, wenn etliche Nebenbedingungen erfüllt sind. Also nicht
> "immer", sondern nur gelegentlich.

Die Bedingung lautet: unter Mitwirkung von Lese/Schreibcache.
Für meine Beispiele ist diese Bedingung erfüllt.
Ein 2-GB-Kopierbeispiel ohne Cache hatte ich ja auch schon gepostet.

>> Rechne einfach mal
>> 2190115106 Bytes/Sek. in GB/s um, falls du das hinbekommst.
>> Das ist dann frei nach Hullen was?

> Bei GByte: 2,190 GByte/s.
> Bei GibiByte: 2,04 GiByte/s.

Schön, bestätigt also die Anzeige des Explorer-Kopierdialogs.
Wir können aber auch gerne beliebige andere Kopierprogramme einsetzen.
Hier das Protokoll von Back4Sure für die 2-GB-Datei, auch mit Cache:

*** Zusammenfassung des Backups ***
Anzahl Dateien im Backup: 1
Anzahl Bytes im Backup: 2076101694 (1979,92 MiB)
Zu kopierende Dateien: 1
Zu kopierende Bytes: 2076101694 (1979,92 MiB)
Kopierte Dateien: 1
Kopierte Bytes: 2076101694 (1979,92 MiB)
Geschwindigkeit: 3288,91 MiB/s
Verstrichene Zeit: 00:00:01
Fehler beim Zugriff auf Quellverzeichnisse: 0
Fehler beim Kopieren: 0

Verflixt, schon wieder nur eine Sekunde. Meine Hardware taugt wohl einfach
nichts, sie ist zu gut für dein Weltbild.

Helmut Hullen

unread,
Jan 3, 2015, 4:41:58 PM1/3/15
to
Hallo, Hans-Peter,

Du meintest am 03.01.15:

>>> Doch, genau damit hat es zu tun. Dieses Bild zeigt sich immer beim
>>> Kopieren unter Mitwirkung des Cache.

>> Nur dann, wenn etliche Nebenbedingungen erfüllt sind. Also nicht
>> "immer", sondern nur gelegentlich.

> Die Bedingung lautet: unter Mitwirkung von Lese/Schreibcache.

Und hinreichend grossem Windows-Cache.

> Für meine Beispiele ist diese Bedingung erfüllt.

Wobei schon das Bild mit der 8-Gbyte-Kopie zeigt, dass der Windows-Cache
für diese Datei nicht gross genug ist.

Bei externen (oder wechselbaren) Zieldatenträgern ist auch "Windows-
Cache" nach Windows-Voreinstellung nicht erfüllt.

Darauf baust Du eine Theorie auf, die Du als allgemeingültig
suggerierst, unentwegt, unbeirrt.

Das sieht wie Rosstäuscherei aus.

Sherlock

unread,
Jan 5, 2015, 1:02:22 PM1/5/15
to
Helmut Hullen:

>>>> Doch, genau damit hat es zu tun. Dieses Bild zeigt sich immer beim
>>>> Kopieren unter Mitwirkung des Cache.

>>> Nur dann, wenn etliche Nebenbedingungen erfüllt sind. Also nicht
>>> "immer", sondern nur gelegentlich.

>> Die Bedingung lautet: unter Mitwirkung von Lese/Schreibcache.

> Und hinreichend grossem Windows-Cache.

Latürnich. Mit 32 GB ist er für eine 2-GB-Datei mehr als groß genug.

>> Für meine Beispiele ist diese Bedingung erfüllt.

> Wobei schon das Bild mit der 8-Gbyte-Kopie zeigt, dass der Windows-Cache
> für diese Datei nicht gross genug ist.

Doch, denn immerhin die ersten 50% bei dem 8-GB-Beispiel verlaufen dank
Cache mit 2,33 GB/s. Das beschleunigt die Sache gewaltig. Es ging aber um
das 2-GB-Beispiel, nicht um 8 GB.

> Bei externen (oder wechselbaren) Zieldatenträgern ist auch "Windows-
> Cache" nach Windows-Voreinstellung nicht erfüllt.
> Darauf baust Du eine Theorie auf, die Du als allgemeingültig
> suggerierst, unentwegt, unbeirrt.

Der Lese/Schreibcache von Windows ist keine Theorie. Ich hatte ein Beispiel
für robocopy gepostet und dieses war unter den genannten Bedingungen
korrekt, keine Fantasiewerte und kein kaputtes Robocopy, wie du hier seit
geraumer Zeit unterstellst. Ich habe hier täglich viele solcher
Kopiervorgänge. Alles reine Praxis.

Helmut Hullen

unread,
Jan 5, 2015, 4:19:03 PM1/5/15
to
Hallo, Hans-Peter,

Du meintest am 05.01.15:

>>>>> Doch, genau damit hat es zu tun. Dieses Bild zeigt sich immer
>>>>> beim Kopieren unter Mitwirkung des Cache.

>>>> Nur dann, wenn etliche Nebenbedingungen erfüllt sind. Also nicht
>>>> "immer", sondern nur gelegentlich.

>>> Die Bedingung lautet: unter Mitwirkung von Lese/Schreibcache.

>> Und hinreichend grossem Windows-Cache.

> Latürnich. Mit 32 GB ist er für eine 2-GB-Datei mehr als groß genug.

Eben - (mindestens) 3 Nebenbedingungen, die allesamt erfüllt sein
müssen, damit Deine Theorie so leidlich passt.

Damit ist das keine allgemeingültige Theorie, sondern ein Sonderfall.

Danke für die Ergänzungen.

[...]

>> Bei externen (oder wechselbaren) Zieldatenträgern ist auch "Windows-
>> Cache" nach Windows-Voreinstellung nicht erfüllt.
>> Darauf baust Du eine Theorie auf, die Du als allgemeingültig
>> suggerierst, unentwegt, unbeirrt.

> Der Lese/Schreibcache von Windows ist keine Theorie.

Du willst mal wieder etwas widerlegen, was ich nie behauptet habe.
Rhetorik für Anfänger. Oder aber ein Zeichen dafür, dass Du Probleme mit
dem "sinnentnehmenden Lesen" hast.

Sherlock

unread,
Jan 6, 2015, 1:03:37 PM1/6/15
to
Helmut Hullen:

>>>>>> Doch, genau damit hat es zu tun. Dieses Bild zeigt sich immer
>>>>>> beim Kopieren unter Mitwirkung des Cache.

>>>>> Nur dann, wenn etliche Nebenbedingungen erfüllt sind. Also nicht
>>>>> "immer", sondern nur gelegentlich.

>>>> Die Bedingung lautet: unter Mitwirkung von Lese/Schreibcache.

>>> Und hinreichend grossem Windows-Cache.
>
>> Latürnich. Mit 32 GB ist er für eine 2-GB-Datei mehr als groß genug.
>
> Eben - (mindestens) 3 Nebenbedingungen, die allesamt erfüllt sein
> müssen, damit Deine Theorie so leidlich passt.
> Damit ist das keine allgemeingültige Theorie, sondern ein Sonderfall.

Noch mal: dies war explizit ein Kopierbeispiel für das Zusammenwirken von
Lese/Schreibcache. Ist für alle Systeme gültig, wobei natürlich die Hardware
bestimmt, wie effektiv die Sache letztlich funktioniert.
Es kommt natürlich nicht bei jedem Kopiervorgang so zum Tragen wie in diesem
Beispiel, aber hier täglich sehr oft, eher in der Mehrzahl der Fälle. Es ist
recht angenehm, wenn beim Kopieren auch großer Dateien im GB-Bereich die
Sache ohne Kopierdialog und ohne erkennbaren Zeitverzug vonstatten geht.
Oder anderes Beispiel: Man durchsucht das Laufwerk nach einer Datei, das
dauert beim ersten Mal etliche Sekunden. Für alle Folgesuchen später am Tag
wird gar nicht mehr auf die Platte zugegriffen, alle Suchen erfolgen im RAM
im Sekundenbruchteil... In der Regel bleibt die Suche hier den ganzen Tag im
RAM, denn es ist ja genug da.

Helmut Hullen

unread,
Jan 6, 2015, 3:45:56 PM1/6/15
to
Hallo, Hans-Peter.,

Du meintest am 06.01.15:

>>>>> Die Bedingung lautet: unter Mitwirkung von Lese/Schreibcache.

>>>> Und hinreichend grossem Windows-Cache.

>>> Latürnich. Mit 32 GB ist er für eine 2-GB-Datei mehr als groß
>>> genug.

>> Eben - (mindestens) 3 Nebenbedingungen, die allesamt erfüllt sein
>> müssen, damit Deine Theorie so leidlich passt.
>> Damit ist das keine allgemeingültige Theorie, sondern ein
>> Sonderfall.

> Noch mal: dies war explizit ein Kopierbeispiel für das Zusammenwirken
> von Lese/Schreibcache.

So isses. Das ist kein Beispiel für das Kopieren von Daten von einem
Datenträger zu einem anderen.

Sherlock

unread,
Jan 11, 2015, 10:22:23 AM1/11/15
to
Helmut Hullen:

>> Noch mal: dies war explizit ein Kopierbeispiel für das Zusammenwirken
>> von Lese/Schreibcache.
>
> So isses. Das ist kein Beispiel für das Kopieren von Daten von einem
> Datenträger zu einem anderen.

Doch, natürlich war dies eines. Es war ein Beispiel fürs Kopieren auf eine
USB-Platte. Du solltest ja nun wissen:
Windows arbeitet mit "write-behind caching". Schreiboperationen sind für das
Win32-API wie auch das NT-API beendet, sobald die Daten im Cache stehen.
Gilt aber für interne Datenträger ebenfalls.

Helmut Hullen

unread,
Jan 11, 2015, 10:37:21 AM1/11/15
to
Hallo, Hans-Peter,

Du meintest am 11.01.15:

>>> Noch mal: dies war explizit ein Kopierbeispiel für das
>>> Zusammenwirken von Lese/Schreibcache.
>>
>> So isses. Das ist kein Beispiel für das Kopieren von Daten von einem
>> Datenträger zu einem anderen.

> Doch, natürlich war dies eines. Es war ein Beispiel fürs Kopieren auf
> eine USB-Platte.

Du widersprichst Dir mal wieder.
Du hattest ein Beispiel fürs Kopieren von Lese-Cache zu Schreib-Cache
gebracht. Das Kopieren auf USB-Platte dauert erheblich länger, siehe
auch

http://de.wikipedia.org/wiki/Universal_Serial_Bus#Datenraten

---------- Zitat ein -----------

... so dass bei aktuellen Systemen für USB 2.0 eine nutzbare Datenrate
in der Größenordnung von 320 Mbit/s (40 MB/s) und für USB 3.0 2400 Mbit/
s (300 MB/s)[13] bleibt.

---------- Zitat aus -----------

Eine 2-GByte-Datei braucht also bei USB 2.0 mindestens 50 Sekunden, bei
USB 3.0 mindestens 7 Sekunden, bis sie komplett auf den Zieldatenträger
geschrieben ist.

Du arbeitest immer noch mit Verfälschungen.

Sherlock

unread,
Jan 11, 2015, 1:07:45 PM1/11/15
to
Helmut Hullen:

>> Doch, natürlich war dies eines. Es war ein Beispiel fürs Kopieren auf
>> eine USB-Platte.

> Du widersprichst Dir mal wieder.
> Du hattest ein Beispiel fürs Kopieren von Lese-Cache zu Schreib-Cache
> gebracht. Das Kopieren auf USB-Platte dauert erheblich länger, siehe
> auch

Nun, dann poste hier mal eine Befehlszeile mit robocopy oder einem anderen
Kopierprogramm, mit der man von Lesecache zu Schreibcache kopieren kann.
Da bin ich mal gespannt.

> http://de.wikipedia.org/wiki/Universal_Serial_Bus#Datenraten
>
> ---------- Zitat ein -----------
>
> ... so dass bei aktuellen Systemen für USB 2.0 eine nutzbare Datenrate
> in der Größenordnung von 320 Mbit/s (40 MB/s) und für USB 3.0 2400 Mbit/
> s (300 MB/s)[13] bleibt.
>
> ---------- Zitat aus -----------

> Eine 2-GByte-Datei braucht also bei USB 2.0 mindestens 50 Sekunden, bei
> USB 3.0 mindestens 7 Sekunden, bis sie komplett auf den Zieldatenträger
> geschrieben ist.

Was genau verstehst du denn hieran immer noch nicht?
Windows arbeitet mit "write-behind caching". Schreiboperationen sind für das
Win32-API wie auch das NT-API beendet, sobald die Daten im Cache stehen.
Drucke es dir aus, hänge es an jede Wand und lasse es dir in Spiegelschrift
an die Stirn tackern.

> Du arbeitest immer noch mit Verfälschungen.

Du bist nach wie vor hartnäckig merkbefreit. Sowas gab es in der Form im
Usenet noch nie.

Helmut Hullen

unread,
Jan 12, 2015, 1:43:33 AM1/12/15
to
Hallo, Hans-Peter,

Du meintest am 11.01.15:

>> Du hattest ein Beispiel fürs Kopieren von Lese-Cache zu
>> Schreib-Cache gebracht. Das Kopieren auf USB-Platte dauert erheblich
>> länger, siehe auch

> Nun, dann poste hier mal eine Befehlszeile mit robocopy oder einem
> anderen Kopierprogramm, mit der man von Lesecache zu Schreibcache
> kopieren kann. Da bin ich mal gespannt.

Du willst mal wieder ausweichen. Es gibt keinen Windows-Befehl, mit dem
Daten in den Lesespeicher geschoben werden, das erledigt das
Betriebssystem ungefragt (wenn bestimmte Nebenbedingungen zutreffen).

Genausowenig kann ich per Windows-Befehl Daten aus dem Schreibcache
irgendwohin schieben.

Du eierst mal wieder herum.

>> Eine 2-GByte-Datei braucht also bei USB 2.0 mindestens 50 Sekunden,
>> bei USB 3.0 mindestens 7 Sekunden, bis sie komplett auf den
>> Zieldatenträger geschrieben ist.

> Was genau verstehst du denn hieran immer noch nicht?
> Windows arbeitet mit "write-behind caching".

Manchmal.
Das lässt sich abschalten. Hattest auch Du bereits mehrfach eingeräumt.
Und das ändert die Schreibrate einer Festplatte überhaupt nicht.

Sherlock

unread,
Jan 13, 2015, 6:47:18 AM1/13/15
to
Helmut Hullen:

>>> Du hattest ein Beispiel fürs Kopieren von Lese-Cache zu
>>> Schreib-Cache gebracht. Das Kopieren auf USB-Platte dauert erheblich
>>> länger, siehe auch

>> Nun, dann poste hier mal eine Befehlszeile mit robocopy oder einem
>> anderen Kopierprogramm, mit der man von Lesecache zu Schreibcache
>> kopieren kann. Da bin ich mal gespannt.

> Du willst mal wieder ausweichen. Es gibt keinen Windows-Befehl, mit dem
> Daten in den Lesespeicher geschoben werden, das erledigt das
> Betriebssystem ungefragt (wenn bestimmte Nebenbedingungen zutreffen).
> Genausowenig kann ich per Windows-Befehl Daten aus dem Schreibcache
> irgendwohin schieben.

Eben. Das Beispiel war also ein Beispiel für einen Kopiervorgang von
Datenträger zu Datenträger! Ich hatte von der internen Platte auf die
externe kopiert.

> Du eierst mal wieder herum.

Du bist immer noch merkbefreit.

>>> Eine 2-GByte-Datei braucht also bei USB 2.0 mindestens 50 Sekunden,
>>> bei USB 3.0 mindestens 7 Sekunden, bis sie komplett auf den
>>> Zieldatenträger geschrieben ist.

>> Was genau verstehst du denn hieran immer noch nicht?
>> Windows arbeitet mit "write-behind caching".

> Manchmal.

In meinem Beispiel war es eindeutig und völlig zweifelsfrei der Fall.
Und du hattest dieses Beispiel als Unsinn bezeichnet und "Fantasiewerte"
unterstellt. weiterhin behauptet, Robocopy sei kaputt. Das war nun mal
völliger, hanebüchener Blödsinn. Dies sollte ja nun klar sein.

> Das lässt sich abschalten. Hattest auch Du bereits mehrfach eingeräumt.

Natürlich. Dann hat man eben schlechtere Werte bei den Kopierzeiten.
Wer schlechte Perfomance mag, schaltet den Schreibcache eben ab.

> Und das ändert die Schreibrate einer Festplatte überhaupt nicht.

Die Schreibrate einer Platte ist für die Dauer des Kopiervorganges VÖLLIG
IRRELEVANT, wenn Lese- und Schreibcache im Spiel sind. Das sollte eigentlich
jeder Anfänger wissen.

Helmut Hullen

unread,
Jan 13, 2015, 7:45:29 AM1/13/15
to
Hallo, Hans-Peter,

Du meintest am 13.01.15:

>>>> Du hattest ein Beispiel fürs Kopieren von Lese-Cache zu
>>>> Schreib-Cache gebracht. Das Kopieren auf USB-Platte dauert
>>>> erheblich länger, siehe auch

[...]

>> Du willst mal wieder ausweichen. Es gibt keinen Windows-Befehl, mit
>> dem Daten in den Lesespeicher geschoben werden, das erledigt das
>> Betriebssystem ungefragt (wenn bestimmte Nebenbedingungen
>> zutreffen). Genausowenig kann ich per Windows-Befehl Daten aus dem
>> Schreibcache irgendwohin schieben.

> Eben. Das Beispiel war also ein Beispiel für einen Kopiervorgang von
> Datenträger zu Datenträger! Ich hatte von der internen Platte auf die
> externe kopiert.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!

Du zitierst (immer noch) Robocopy-Daten, die in diesem ganz speziellen
Fall nur beschreiben, wie lange es dauert, bis die Daten vom Lese-Cache
in den Schreib-Cache kommen. Mehr nicht. Die Dauer des Transfers von der
Quellplatte in den Lesecache und die Dauer des Transfers vom
Schreibcache zur Zielplatte wird bei diesen ganz speziellen
Nebenbedingungen von Robocopy vertuscht.

Sherlock

unread,
Jan 13, 2015, 9:11:17 AM1/13/15
to
Helmut Hullen:

>>>>> Du hattest ein Beispiel fürs Kopieren von Lese-Cache zu
>>>>> Schreib-Cache gebracht. Das Kopieren auf USB-Platte dauert
>>>>> erheblich länger, siehe auch
>
> [...]
>
>>> Du willst mal wieder ausweichen. Es gibt keinen Windows-Befehl, mit
>>> dem Daten in den Lesespeicher geschoben werden, das erledigt das
>>> Betriebssystem ungefragt (wenn bestimmte Nebenbedingungen
>>> zutreffen). Genausowenig kann ich per Windows-Befehl Daten aus dem
>>> Schreibcache irgendwohin schieben.

>> Eben. Das Beispiel war also ein Beispiel für einen Kopiervorgang von
>> Datenträger zu Datenträger! Ich hatte von der internen Platte auf die
>> externe kopiert.

>>>>>>>>>>>>>>>>>>>>> Nein!

Hellseher willst du also auch noch sein.

> Du zitierst (immer noch) Robocopy-Daten, die in diesem ganz speziellen
> Fall nur beschreiben, wie lange es dauert, bis die Daten vom Lese-Cache
> in den Schreib-Cache kommen. Mehr nicht.

Damit ist der Kopiervorgang von Platte A zu Platte B logisch abgeschlossen.
Windows meldet: Datei wurde kopiert. Die Datei ist im Explorer am Ziel
sichtbar und kann dort beliebig bearbeitet werden, denn:
Windows arbeitet mit "write-behind caching". Schreiboperationen sind für das
Win32-API wie auch das NT-API beendet, sobald die Daten im Cache stehen.
Drucke es dir aus, hänge es an jede Wand und lasse es dir in Spiegelschrift
an die Stirn tackern.
Es wurde der Ablauf des Kopiervorganges beschrieben.

> Die Dauer des Transfers von der
> Quellplatte in den Lesecache und die Dauer des Transfers vom
> Schreibcache zur Zielplatte wird bei diesen ganz speziellen
> Nebenbedingungen von Robocopy vertuscht.

Du musst jetzt stark sein: 99% aller Aktivitäten werden von Windows
"vertuscht". Windows meldet den Vollzug von Aktionen, die dann im
Hintergrund weitere Aktionen bewirken, unsichtbar für den User.
Sichtbar werden sie, wenn man z.B. den Process Monitor öffnet.
Relevant für den User ist das, was Windows meldet, z.B. dass seine
Kopieraktion ausgeführt und beendet wurde. Wenn Windows meldet "Datei wurde
kopiert" ist das für den User der Fall. Hierfür muss aber kein einziges Bit
physisch am Ziel angekommen sein!
Du hast Unsinn geplappert. Robocopy und alle anderen Kopierprogramme sind
nicht kaputt und liefern keine Fantasiewerte!

Helmut Hullen

unread,
Jan 13, 2015, 12:14:00 PM1/13/15
to
Hallo, Hans-Peter,

Du meintest am 13.01.15:

>>> Eben. Das Beispiel war also ein Beispiel für einen Kopiervorgang
>>> von Datenträger zu Datenträger! Ich hatte von der internen Platte
>>> auf die externe kopiert.

>>>>>>>>>>>>>>>>>>>>>> Nein!

> Hellseher willst du also auch noch sein.

Unfug. Was Du hier unentwegt vorzeigst, das ist das Kopieren vom
Lesecache zum Schreibcache. Mehr nicht.

>> Du zitierst (immer noch) Robocopy-Daten, die in diesem ganz
>> speziellen Fall nur beschreiben, wie lange es dauert, bis die Daten
>> vom Lese-Cache in den Schreib-Cache kommen. Mehr nicht.

> Damit ist der Kopiervorgang von Platte A zu Platte B logisch
> abgeschlossen.

Unfug. Wenn etliche Nebenbedingungen erfüllt sind (die Du selbst erst
unlängst eingeräumt hast), dann ist der Porozess bestenfalls in den
Hintergrund geschoben. Mehr nicht.

> Windows meldet: Datei wurde kopiert. Die Datei ist im
> Explorer am Ziel sichtbar und kann dort beliebig bearbeitet werden,
> denn: Windows arbeitet mit "write-behind caching". Schreiboperationen

Bei meinen Maschinen meldet Windows dann, dass auf die Datei nicht
zugeriffen werden könne. Auch wenn der Windows-Explorer sie als existent
meldet.

Du verfälscht einiges.

> sind für das Win32-API wie auch das NT-API beendet, sobald die Daten
> im Cache stehen. Drucke es dir aus, hänge es an jede Wand und lasse
> es dir in Spiegelschrift an die Stirn tackern.
> Es wurde der Ablauf des Kopiervorganges beschrieben.

Das Kopieren von einem Datenträger zu einem anderen ist dann
abegschlossen, wenn auch das letzte Byte auf dem Zieldatenträger
angekommen ist. Nicht schon dann, wenn der Prozess in den Hintergrund
geschoben ist.

Bei einer Schreibrate von 200 MByte/s dauert also auch bei Deinem System
das Kopieren einer Datei von 2 GByte mindestens 10 Sekunden.

>> Die Dauer des Transfers von der
>> Quellplatte in den Lesecache und die Dauer des Transfers vom
>> Schreibcache zur Zielplatte wird bei diesen ganz speziellen
>> Nebenbedingungen von Robocopy vertuscht.

> Du musst jetzt stark sein: 99% aller Aktivitäten werden von Windows
> "vertuscht". Windows meldet den Vollzug von Aktionen, die dann im
> Hintergrund weitere Aktionen bewirken, unsichtbar für den User.

Na also - jetzt räumst Du mal wieder ein, dass der Kopierprozess noch
eine Weile läuft.

So weit waren wir schon mal ...

Wobei die 99% mal wieder frei erfunden sind.

Sherlock

unread,
Jan 14, 2015, 8:46:45 AM1/14/15
to
Helmut Hullen:

>>>> Eben. Das Beispiel war also ein Beispiel für einen Kopiervorgang
>>>> von Datenträger zu Datenträger! Ich hatte von der internen Platte
>>>> auf die externe kopiert.

>>>>>>>>>>>>>>>>>>>>>>> Nein!
>
>> Hellseher willst du also auch noch sein.

> Unfug. Was Du hier unentwegt vorzeigst, das ist das Kopieren vom
> Lesecache zum Schreibcache. Mehr nicht.

So erledigt Windows Kopiervorgänge unter Mitwirkung des Caches von einer
Platte auf die andere. Seit Urzeiten schon!

>>> Du zitierst (immer noch) Robocopy-Daten, die in diesem ganz
>>> speziellen Fall nur beschreiben, wie lange es dauert, bis die Daten
>>> vom Lese-Cache in den Schreib-Cache kommen. Mehr nicht.

>> Damit ist der Kopiervorgang von Platte A zu Platte B logisch
>> abgeschlossen.

> Unfug. Wenn etliche Nebenbedingungen erfüllt sind (die Du selbst erst
> unlängst eingeräumt hast), dann ist der Porozess bestenfalls in den
> Hintergrund geschoben. Mehr nicht.

Das ist völliger Lötzinn! Du kapierst rein gar nichts.
Wenn Windows dem User meldet "Datei wurde kopiert", dann ist sie kopiert.
Der User kann sie am Ziel dann voll verwenden. Was Windows im Hintergrund
treibt, ist für User irrelevant. Das gilt für ALLE Vorgänge, die Windows
ausführt und dem User meldet. Kein User muss einen Prozess-Monitor starten
und nachschauen, ob der Vorgang auch im Hintergrund schon beendet ist.
Wenn Windows dem User "Vorgang erledigt" meldet, und der User dies selbst
auch sieht, ist es so, egal, was Windows im Hintergrund noch treibt.

>> Windows meldet: Datei wurde kopiert. Die Datei ist im
>> Explorer am Ziel sichtbar und kann dort beliebig bearbeitet werden,
>> denn: Windows arbeitet mit "write-behind caching". Schreiboperationen

> Bei meinen Maschinen meldet Windows dann, dass auf die Datei nicht
> zugeriffen werden könne. Auch wenn der Windows-Explorer sie als existent
> meldet.

Ich schrieb nichts von " Windows-Explorer sie als existent meldet."!
Du kannst nicht Sinn entnehmend lesen! Ich schrieb von Windows meldet
"Datei wurde kopiert". Wenn DU diese Meldung von Windows bekommst, dann
kannst du die Datei im Ziel auch bearbeiten, egal, ob sie dort schon
physisch existiert oder nicht.

> Du verfälscht einiges.

Nein, du bist merkbefreit.

>> sind für das Win32-API wie auch das NT-API beendet, sobald die Daten
>> im Cache stehen. Drucke es dir aus, hänge es an jede Wand und lasse
>> es dir in Spiegelschrift an die Stirn tackern.
>> Es wurde der Ablauf des Kopiervorganges beschrieben.

> Das Kopieren von einem Datenträger zu einem anderen ist dann
> abegschlossen, wenn auch das letzte Byte auf dem Zieldatenträger
> angekommen ist. Nicht schon dann, wenn der Prozess in den Hintergrund
> geschoben ist.

Nein! Für Windows ist es dann beendet, sobald die Daten im Cache stehen!
Windows schiebt den Kopiervorgang NICHT in den Hintergrund. Der copy-Befehl
zeigt in deutlich sichtbar an. Solange der Kopiervorgang läuft, sieht man
den blinkenden Cursor, ist er beendet, meldet Windows "Datei wurde kopiert".
Danach ist die Datei im Ziel voll verwendbar - und hierzu muss noch kein
einziges Byte am Ziel physisch angekommen sein! Auch der Explorer zeigt
deutlich den Kopiervorgang an, mit Fortschrittsbalken. Da ist auch nichts in
den Hintergrund geschoben. Wenn die 100% erreicht sind, ist der
Kopiervorgang beendet. Auch hier muss noch kein Byte physisch am Ziel
angekommen sein!

> Bei einer Schreibrate von 200 MByte/s dauert also auch bei Deinem System
> das Kopieren einer Datei von 2 GByte mindestens 10 Sekunden.

Dass das nicht stimmt, hatte ich dir nun schon per Log von x
Kopierprogrammen bewiesen! Überall nur eine Sekunde!

>>> Die Dauer des Transfers von der
>>> Quellplatte in den Lesecache und die Dauer des Transfers vom
>>> Schreibcache zur Zielplatte wird bei diesen ganz speziellen
>>> Nebenbedingungen von Robocopy vertuscht.

>> Du musst jetzt stark sein: 99% aller Aktivitäten werden von Windows
>> "vertuscht". Windows meldet den Vollzug von Aktionen, die dann im
>> Hintergrund weitere Aktionen bewirken, unsichtbar für den User.

> Na also - jetzt räumst Du mal wieder ein, dass der Kopierprozess noch
> eine Weile läuft.

Nicht der Kopierprozess! Den hat Windows schon lange als beendet erklärt!
Es sind mit dem Kopierprozess verbundene Hintergrundtätigkeiten, die für den
User irrelevant sind. Alle Aktionen von Windows sind mit solchen
Hintergrundtätigkeiten verbunden!
Der Kopierprozess dauert die eine Sekunde, die im Log ausgewiesen ist.
Die Hintergrundtätigkeiten von Windows sind endlos und dauern so lange, wie
der Rechner eingeschaltet ist, sie enden nie! Da könnte man für jede Aktion,
die Windows als beendet erklärt, behaupten, sie sei ja gar nicht beendet,
weil im Hintergrund noch damit zusammen hängende Aktivität besteht.
Aber nur Vollidioten würden das so sehen!

> So weit waren wir schon mal ...

Ja, jeder normale User rafft das recht schnell. Du wohl nie!

Helmut Hullen

unread,
Jan 14, 2015, 10:32:47 AM1/14/15
to
Hallo, Hans-Peter,

Du meintest am 14.01.15:

>> Unfug. Was Du hier unentwegt vorzeigst, das ist das Kopieren vom
>> Lesecache zum Schreibcache. Mehr nicht.

> So erledigt Windows Kopiervorgänge unter Mitwirkung des Caches von
> einer Platte auf die andere. Seit Urzeiten schon!

Eben - "unter Mitwirkung". Der Schreibcache (wenn er denn überhaupt a)
benutzbar und b) hinreichend gross ist) ist nur eine der vielen
Stationen auf dem Weg der Daten von dem einen Datenträger zum anderen.

Ziel des Kopierens ist der andere Datenträger, nicht eine der vielen
Zwischenstationen - ja: auch die Leitungen vom Quelldatenträger zum
Chipsatz im Rechner und vom RAM des Rechners über den Chipsatz und den
Cache des Zieldatenträgers sind nur Zwischenstationen.

Wenn ich einen Brief nach Brisbane in Australien hier in Braunschweig in
den Briefkasten einwerfe, dann ist der Briefkasten auch nur 1
Zwischenstation, der Brief ist dann noch lange nicht beim Empfänger.

>> Unfug. Wenn etliche Nebenbedingungen erfüllt sind (die Du selbst
>> erst unlängst eingeräumt hast), dann ist der Porozess bestenfalls in
>> den Hintergrund geschoben. Mehr nicht.

> Das ist völliger Lötzinn! Du kapierst rein gar nichts.

Du erzählst unentwegt Unfug, Du verwechselst iimmer noch
Zwischenstationen mit dem Ziel.

> Wenn Windows dem User meldet "Datei wurde kopiert", dann ist sie
> kopiert.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!



> Der User kann sie am Ziel dann voll verwenden.

Nein.
Habe ich gerade noch mal ausprobiert.

Videodatei von 5,5 Gbyte auf eine SSD kopiert, der Schreibcache ist
eingeschaltet.
Der Rechner ist mit 8 GByte RAM bis zum Anschlag gefüllt, mehr geht
nicht hinein.


> Was Windows
> im Hintergrund treibt, ist für User irrelevant.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!

> Das gilt für ALLE
> Vorgänge, die Windows ausführt und dem User meldet.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!

>>> Windows meldet: Datei wurde kopiert. Die Datei ist im
>>> Explorer am Ziel sichtbar und kann dort beliebig bearbeitet werden,
>>> denn: Windows arbeitet mit "write-behind caching".
>>> Schreiboperationen

>> Bei meinen Maschinen meldet Windows dann, dass auf die Datei nicht
>> zugeriffen werden könne. Auch wenn der Windows-Explorer sie als
>> existent meldet.

> Ich schrieb nichts von " Windows-Explorer sie als existent meldet."!
> Du kannst nicht Sinn entnehmend lesen! Ich schrieb von Windows meldet
> "Datei wurde kopiert".

Und das dauert im oben genannten Fall etwa 60 Sekunden.
In der Zeit kann ich sie weder auf dem Quell-Datenträger löschen noch
auf dem Ziel-Datenträger (wo sie bereits nach wenigen Sekunden angezeigt
wird) "öffnen"; bei der *.mpg-Datei wartet z.B. das Abspielprogramm
diese etwa 60 Sekunden ab, bevor es das Video abspielt.

Du hast ein wilde Theorie darauf gegründet, dass mindestens 3
Nebenbedingungen erfüllt sind. Und diese wilde Theorie willst Du jetzt
als allgemeingültig verkaufen. Und was nicht hineinpasst, das leugnetst
Du mit absurden Abwehr-Argumenten ("braucht nicht jeder", "ist nicht der
Normalfall", "Schrott-Hardware" usw.).

> Wenn DU diese Meldung von Windows bekommst,
> dann kannst du die Datei im Ziel auch bearbeiten, egal, ob sie dort
> schon physisch existiert oder nicht.

Eben nicht. Nicht mal das "Öffnen", also der nur lesende Zugriff, geht.

>> Das Kopieren von einem Datenträger zu einem anderen ist dann
>> abgeschlossen, wenn auch das letzte Byte auf dem Zieldatenträger
>> angekommen ist. Nicht schon dann, wenn der Prozess in den
>> Hintergrund geschoben ist.

> Nein! Für Windows ist es dann beendet, sobald die Daten im Cache
> stehen!

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!


> Windows schiebt den Kopiervorgang NICHT in den Hintergrund.
> Der copy-Befehl zeigt in deutlich sichtbar an. Solange der
> Kopiervorgang läuft, sieht man den blinkenden Cursor, ist er beendet,
> meldet Windows "Datei wurde kopiert". Danach ist die Datei im Ziel
> voll verwendbar - und hierzu muss noch kein einziges Byte am Ziel
> physisch angekommen sein!

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!


> Auch der Explorer zeigt deutlich den
> Kopiervorgang an, mit Fortschrittsbalken. Da ist auch nichts in den
> Hintergrund geschoben. Wenn die 100% erreicht sind, ist der
> Kopiervorgang beendet. Auch hier muss noch kein Byte physisch am Ziel
> angekommen sein!

Siehe oben - nicht mal der lesende Zugriff funktioniert.


>> Bei einer Schreibrate von 200 MByte/s dauert also auch bei Deinem
>> System das Kopieren einer Datei von 2 GByte mindestens 10 Sekunden.

> Dass das nicht stimmt, hatte ich dir nun schon per Log von x
> Kopierprogrammen bewiesen! Überall nur eine Sekunde!

"Überall"? Schon bei einer Datei mit etwa 8 GByte braucht Dein System
viel länger als die von Dir mühsam erfunden 1 Sekunde.

Du wiederholst Unfug.

>> Na also - jetzt räumst Du mal wieder ein, dass der Kopierprozess
>> noch eine Weile läuft.

> Nicht der Kopierprozess! Den hat Windows schon lange als beendet
> erklärt! Es sind mit dem Kopierprozess verbundene
> Hintergrundtätigkeiten, die für den User irrelevant sind.
>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!



> Alle
> Aktionen von Windows sind mit solchen Hintergrundtätigkeiten
> verbunden!Der Kopierprozess dauert die eine Sekunde, die im Log
> ausgewiesen ist.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!


> Die Hintergrundtätigkeiten von Windows sind endlos
> und dauern so lange, wie der Rechner eingeschaltet ist, sie enden
> nie!

Fürs Kopieren irrelevant (wenn Deine Behauptung denn überhaupt stimmt).
Du willst nur wieder ablenken.

> Da könnte man für jede Aktion, die Windows als beendet erklärt,
> behaupten, sie sei ja gar nicht beendet, weil im Hintergrund noch
> damit zusammen hängende Aktivität besteht. Aber nur Vollidioten
> würden das so sehen!

Rhetorik für Anfänger. Ablenkungsmanöver.

Sherlock

unread,
Jan 14, 2015, 11:50:27 AM1/14/15
to
Helmut Hullen:

>>> Unfug. Was Du hier unentwegt vorzeigst, das ist das Kopieren vom
>>> Lesecache zum Schreibcache. Mehr nicht.

>> So erledigt Windows Kopiervorgänge unter Mitwirkung des Caches von
>> einer Platte auf die andere. Seit Urzeiten schon!

> Eben - "unter Mitwirkung". Der Schreibcache (wenn er denn überhaupt a)
> benutzbar und b) hinreichend gross ist) ist nur eine der vielen
> Stationen auf dem Weg der Daten von dem einen Datenträger zum anderen.

Dummerweise geht es nicht um den "Weg der Daten von dem einen Datenträger
zum anderen", sondern um einen Kopiervorgang und dessen Dauer unter Windows.
Wenn Windows dem User meldet "Datei wurde kopiert", dann kann der User die
Datei ab diesem Zeitpunkt am Ziel voll verwenden. Alles andere muss den User
nicht kümmern. Falls bei dir nach der Meldung "Datei wurde kopiert" diese
nicht benutzbar ist, dann ist dein System kaputt und schrottreif.

Wenn ein Schreibcache da ist und dieser z.B. auf eine Schreibverzögerung von
2 Stunden eingestellt ist, kann der User die Datei auf dem Zieldatenträger
logischerweise sofort voll verwenden und nicht erst nach 2 Stunden, wenn die
Daten physisch dort niedergeschrieben werden.
Das kapieren selbst Leute mit dem IQ eines Hundes, wenn es ihnen so oft
erklärt wird.

[Restlichen Unfug und Trollereien entsorgt]

Helmut Hullen

unread,
Jan 14, 2015, 12:58:20 PM1/14/15
to
Hallo, Hans-Peter,

Du meintest am 14.01.15:

>>> So erledigt Windows Kopiervorgänge unter Mitwirkung des Caches von
>>> einer Platte auf die andere. Seit Urzeiten schon!

>> Eben - "unter Mitwirkung". Der Schreibcache (wenn er denn überhaupt
>> a) benutzbar und b) hinreichend gross ist) ist nur eine der vielen
>> Stationen auf dem Weg der Daten von dem einen Datenträger zum
>> anderen.

> Dummerweise geht es nicht um den "Weg der Daten von dem einen
> Datenträger zum anderen", sondern um einen Kopiervorgang und dessen
> Dauer unter Windows.

Das möchtest Du gern derart verdrehen, damit Deine meistens unsinnige
Behauptung nicht so offensichtlich unsinnig aussieht.

Das Kopieren einer Datei von 2 GByte auf eine Festplatte, die eine
Schreibrate von 200 MByte/s hat, dauert nun mal mindestens 10 Sekunden.

Auch dann, wenn die Elektronen dann und wann fast mit
Lichtgeschwindigkeit wandern.

Sherlock

unread,
Jan 14, 2015, 1:38:33 PM1/14/15
to
Helmut Hullen:

>>>> So erledigt Windows Kopiervorgänge unter Mitwirkung des Caches von
>>>> einer Platte auf die andere. Seit Urzeiten schon!

>>> Eben - "unter Mitwirkung". Der Schreibcache (wenn er denn überhaupt
>>> a) benutzbar und b) hinreichend gross ist) ist nur eine der vielen
>>> Stationen auf dem Weg der Daten von dem einen Datenträger zum
>>> anderen.

>> Dummerweise geht es nicht um den "Weg der Daten von dem einen
>> Datenträger zum anderen", sondern um einen Kopiervorgang und dessen
>> Dauer unter Windows.

> Das möchtest Du gern derart verdrehen, damit Deine meistens unsinnige
> Behauptung nicht so offensichtlich unsinnig aussieht.

Wie schon gesagt: Robocopy, der Explorer oder auch Bach4Sure liefern keine
unsinnigen Logs. Nur Hullen liefert unsinnige, falsche Behauptungen zu
Windows.

> Das Kopieren einer Datei von 2 GByte auf eine Festplatte, die eine
> Schreibrate von 200 MByte/s hat, dauert nun mal mindestens 10 Sekunden.

Wie das denn, wenn für den Schreibcache 2 Stunden Schreibverzögerung
eingestellt sind? Dann müsste es nach Hullen-Mathematik ja 2 Stunden und 10
Sekunden dauern. Was macht also der User, wenn er die kopierte Datei am Ziel
sofort bearbeiten will? 2 Stunden und 10 Sekunden warten? Oder darf er
sofort, wenn Windows meldete "Datei wurde kopiert"? Oder meldet Windows das
dann erst nach 2 Stunden? Wie ist das in Hullens Universum?

Helmut Hullen

unread,
Jan 14, 2015, 3:42:08 PM1/14/15
to
Hallo, Hans-Peter,

Du meintest am 14.01.15:

> Wie schon gesagt: Robocopy, der Explorer oder auch Bach4Sure liefern
> keine unsinnigen Logs.

Wie schon gesagt: wenn ich Dateien kopiere, dann interessiert mich
(gelegentlich, wenn ich neugierig bin) nur, wie lange es dauert, bis
auch das letzte Byte auf dem Ziel-Datenträger gelandet ist. Du scheinst
an anderen Daten interessiert zu sein. Dein Beispiel mit der 2-GByte-
Datei liefert ja nur dann die (irreführende und deshalb unsinnige)
Kopierzeit von 0 Sekunden, wenn mindestens 3 Nebenbedingungen erfüllt
sind.

Schon bei einer Datei von 8 Gbyte werden (natürlich) erheblich längere
Zeiten angezeigt. Insbesondere weder 8*0 noch noch *1 Sekunde.


>> Das Kopieren einer Datei von 2 GByte auf eine Festplatte, die eine
>> Schreibrate von 200 MByte/s hat, dauert nun mal mindestens 10
>> Sekunden.

> Wie das denn, wenn für den Schreibcache 2 Stunden Schreibverzögerung
> eingestellt sind? Dann müsste es nach Hullen-Mathematik ja 2 Stunden
> und 10 Sekunden dauern.

Du weisst, was "mindestens" bedeutet?

> Was macht also der User, wenn er die kopierte
> Datei am Ziel sofort bearbeiten will? 2 Stunden und 10 Sekunden
> warten?

Richtig!

Endlich hast Du das Problem verstanden!

(Mal sehen, wie lange das vorhält ...)

Arno Welzel

unread,
Jan 15, 2015, 3:50:43 AM1/15/15
to
Sherlock schrieb am 2015-01-14 um 14:46:

> Helmut Hullen:
[...]
[Sinnfreies Ja-Nein-Doch-Aber entsorgt]

Wie lange wollt ihr diese sinnfreie Spielchen eigentlich noch treiben?

Die Funktionsweise von Caches ist hinlänglich bekannt. Da werdet ihr
auch nichts daran ändern.

Vorschlag zur Güte:

Für Helmut Hullen ist "Kopieren abgeschlossen" grundsätzlich nur dann
gegeben, wenn der Schreibvorgang auf dem Datenträger abgeschlossen wurde
und man selbigen z.B. auch entfernen könnte und "Sherlock" begnügt sich
damit, wenn das Windows-API den Schreibzugriff als "abgeschlossen"
meldet, auch wenn im Hintergrund noch Cache-Inhalte geschrieben werden
müssen.


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

Sherlock

unread,
Jan 15, 2015, 9:12:42 AM1/15/15
to
Helmut Hullen:

>> Wie schon gesagt: Robocopy, der Explorer oder auch Bach4Sure liefern
>> keine unsinnigen Logs.

> Wie schon gesagt: wenn ich Dateien kopiere, dann interessiert mich
> (gelegentlich, wenn ich neugierig bin) nur, wie lange es dauert, bis
> auch das letzte Byte auf dem Ziel-Datenträger gelandet ist.

Wann das letzte Byte physisch am Ziel ankam, interessiert keinen User.
Es ist beim Kopieren völlig irrelevant. Der Kopierdialog von Windows sagt
dem User, wann der Kopiervorgang beendet ist. Dann kann er die Datei im Ziel
bearbeiten, wenn er das will. Und die meisten User legen sehr viel Wert
darauf, dass Vorgänge schnell und nicht langsam ablaufen, sofern sie keine
Hullen sind.

>>> Das Kopieren einer Datei von 2 GByte auf eine Festplatte, die eine
>>> Schreibrate von 200 MByte/s hat, dauert nun mal mindestens 10
>>> Sekunden.

>> Wie das denn, wenn für den Schreibcache 2 Stunden Schreibverzögerung
>> eingestellt sind? Dann müsste es nach Hullen-Mathematik ja 2 Stunden
>> und 10 Sekunden dauern.

> Du weisst, was "mindestens" bedeutet?

Hullen-Mathematik kommt aus einem anderen Universum.

>> Was macht also der User, wenn er die kopierte
>> Datei am Ziel sofort bearbeiten will? 2 Stunden und 10 Sekunden
>> warten?

> Richtig!

LOL
Nun, Windows meldet aber nach einer Sekunde "Datei wurde kopiert" und der
User kann die Datei auf dem Zieldatenträger dann auch öffnen und bearbeiten
- und das, obwohl noch nicht ein einziges Byte dort physisch vorhanden ist.
Das ist der Sinn eines Schreibcaches mit Verzögerung: Beschleunigung der
Arbeitsvorgänge. Alle Nicht-Hullen bearbeiten die Datei also nach einer
Sekunde, ein Hullen wartet 2 Stunden ab, bis die Schreibverzögerung
abgelaufen ist. :-)

Was macht ein Hullen eigentlich beim Start von Programmen?
Jedes Programm hat ja einen Pfad, der auf den Speicherort auf dem
Datenträger zeigt. Das Starten eines Programmes dauert also z.B. 20
Sekunden, wenn es von diesem Ort geladen wird.
Nun schlägt aber wieder der unsinnige Cache zu, indem Superfetch beim Booten
das Programm ins RAM lädt. Der Hullen erkennt also mit Erstaunen, dass das
Programm schon im Sekundenbruchteil geladen wird, was bei der Leserate der
Platte ja völlig unmöglich ist, es muss 20 Sekunden dauern. Auch hier
liefert Windows also wieder unsinnige Werte bei der Startzeit, die ja gar
nicht sein können.
Was macht der Hullen dann? Er wartet noch 20 Sekunden ab, bis er das
Programm zu benutzen wagt? Faszinierend, diese Hullen-Welt.

Sherlock

unread,
Jan 15, 2015, 9:21:34 AM1/15/15
to
Arno Welzel:

> Wie lange wollt ihr diese sinnfreie Spielchen eigentlich noch treiben?

Ich finde es faszinierend. Solche Merkbefreiung ist im Usenet immerhin
einmalig.

> Die Funktionsweise von Caches ist hinlänglich bekannt. Da werdet ihr
> auch nichts daran ändern.

Nun, ich kenne sie und will daran auch nichts ändern. Hullen hat da aber
seine eigenen Vorstellungen. Er meint, man müsse 2 Stunden warten, wenn der
Schreibcache auf diese Verzögerung eingestellt ist.

> Vorschlag zur Güte:
> Für Helmut Hullen ist "Kopieren abgeschlossen" grundsätzlich nur dann
> gegeben, wenn der Schreibvorgang auf dem Datenträger abgeschlossen wurde
> und man selbigen z.B. auch entfernen könnte und "Sherlock" begnügt sich
> damit, wenn das Windows-API den Schreibzugriff als "abgeschlossen"
> meldet, auch wenn im Hintergrund noch Cache-Inhalte geschrieben werden
> müssen.

Das Kopieren ist für User dann abgeschlossen, wenn Windows es als beendet
erklärt. Die Datei kann im Ziel dann bearbeitet werden. Was Windows im
Hintergrund treibt, ist für User irrelevant. Ich hatte Herrn Hullen ja schon
vor langer Zeit auf den Unterschied logischer/physischer Kopiervorgang
hingewiesen. Das kapiert er aber nicht. Insofern kann man sich darauf auch
nicht einigen. Man muss zwei Stunden warten, bevor man die kopierte Datei
bearbeiten darf. :o)

Helmut Hullen

unread,
Jan 15, 2015, 10:09:22 AM1/15/15
to
Hallo, Hans-Peter,

Du meintest am 15.01.15:

>> Vorschlag zur Güte:
>> Für Helmut Hullen ist "Kopieren abgeschlossen" grundsätzlich nur
>> dann gegeben, wenn der Schreibvorgang auf dem Datenträger
>> abgeschlossen wurde und man selbigen z.B. auch entfernen könnte und
>> "Sherlock" begnügt sich damit, wenn das Windows-API den
>> Schreibzugriff als "abgeschlossen" meldet, auch wenn im Hintergrund
>> noch Cache-Inhalte geschrieben werden müssen.

> Das Kopieren ist für User dann abgeschlossen, wenn Windows es als
> beendet erklärt.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!


> Die Datei kann im Ziel dann bearbeitet werden.

>>>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>>>> Doch!
>>>>>>>>>>>>>> Nein!
>>>>>>>>>>>>> Doch!
>>>>>>>>>>>> Nein!
>>>>>>>>>>> Doch!
>>>>>>>>>> Nein!
>>>>>>>>> Doch!
>>>>>>>> Nein!
>>>>>>> Doch!
>>>>>> Nein!
>>>>> Doch!
>>>> Nein!
>>> Doch!
>> Nein!
> Doch!
Nein!

Helmut Hullen

unread,
Jan 15, 2015, 10:09:22 AM1/15/15
to
Hallo, Hans-Peter,

Du meintest am 15.01.15:

>> Wie schon gesagt: wenn ich Dateien kopiere, dann interessiert mich
>> (gelegentlich, wenn ich neugierig bin) nur, wie lange es dauert, bis
>> auch das letzte Byte auf dem Ziel-Datenträger gelandet ist.

> Wann das letzte Byte physisch am Ziel ankam, interessiert keinen
> User.

Diese Ansicht ist "extraordinär". Schon beim Arbeiten mit USB-Sticks ist
es ratsam, den Stick erst dann zu entfernen, wenn auch das letzte Byte
brav abgespeichert worden ist.

Aber Du hast vermutlich mal wieder einen Begriff (hier: "keinen")
umdefiniert.

Sherlock

unread,
Jan 15, 2015, 2:09:08 PM1/15/15
to
Helmut Hullen:

>>> Wie schon gesagt: wenn ich Dateien kopiere, dann interessiert mich
>>> (gelegentlich, wenn ich neugierig bin) nur, wie lange es dauert, bis
>>> auch das letzte Byte auf dem Ziel-Datenträger gelandet ist.

>> Wann das letzte Byte physisch am Ziel ankam, interessiert keinen
>> User.

> Diese Ansicht ist "extraordinär". Schon beim Arbeiten mit USB-Sticks ist
> es ratsam, den Stick erst dann zu entfernen, wenn auch das letzte Byte
> brav abgespeichert worden ist.

Auch das interessiert keinen User. Windows gibt den Stick erst dann frei,
wenn es alle Schreibvorgänge darauf erledigt hat, auch die Schreibvorgänge
in NTFS-Dateien. Der User klickt also einfach nur auf "Entfernen" und
wartet, bis Windows meldet "Du darfst jetzt entfernen". Das war ja einfach!

Helmut Hullen

unread,
Jan 15, 2015, 3:33:58 PM1/15/15
to
Hallo, Hans-Peter,

Du meintest am 15.01.15:

>>> Wann das letzte Byte physisch am Ziel ankam, interessiert keinen
>>> User.

>> Diese Ansicht ist "extraordinär". Schon beim Arbeiten mit USB-Sticks
>> ist es ratsam, den Stick erst dann zu entfernen, wenn auch das
>> letzte Byte brav abgespeichert worden ist.

> Auch das interessiert keinen User.

Du arbeitest mal wieder mit freien Erfindungen.

> Windows gibt den Stick erst dann frei, wenn es alle Schreibvorgänge
> darauf erledigt hat, auch die Schreibvorgänge in NTFS-Dateien.

Also sollte den User doch interessieren, ob denn auch tatsächlich alle
Bytes auf dem Ziel-Datenträger angekommen sind. Du eierst mal wieder
herum

Die (verfrühte) "robocopy"-Meldung könnte den Benutzer jedoch auf die
Idee kommen lassen, den Stick (oder das Kabel der USB-Backup-Platte)
schon dann herauszuziehen, wenn "robocopy" (verfrüht) "fertig" meldet.

> Der User klickt also einfach nur auf "Entfernen" und wartet, bis
> Windows meldet "Du darfst jetzt entfernen".

Eben - er darf sich (wie auch Du mehrfach eingeräumt hast) nicht auf die
Meldung von "robocopy" verlassen.

Sherlock

unread,
Jan 15, 2015, 5:15:25 PM1/15/15
to
Helmut Hullen:

>>>> Wann das letzte Byte physisch am Ziel ankam, interessiert keinen
>>>> User.

>>> Diese Ansicht ist "extraordinär". Schon beim Arbeiten mit USB-Sticks
>>> ist es ratsam, den Stick erst dann zu entfernen, wenn auch das
>>> letzte Byte brav abgespeichert worden ist.

>> Auch das interessiert keinen User.

> Du arbeitest mal wieder mit freien Erfindungen.

Nein, du lügst mal wieder und bist merkbefreit.

>> Windows gibt den Stick erst dann frei, wenn es alle Schreibvorgänge
>> darauf erledigt hat, auch die Schreibvorgänge in NTFS-Dateien.

> Also sollte den User doch interessieren, ob denn auch tatsächlich alle
> Bytes auf dem Ziel-Datenträger angekommen sind.

Da Windows dies automatisch ohne Zutun des Users erledigt, muss dieser sich
damit auch nicht befassen. Grundsätzlich sollte ihn alles interessieren, die
Realität sieht aber ganz anders aus. Er muss nur soviel wissen, dass er
externe Datenträger einfach grundsätzlich über "sicheres Entfernen" trennen
muss.

> Die (verfrühte) "robocopy"-Meldung könnte den Benutzer jedoch auf die
> Idee kommen lassen, den Stick (oder das Kabel der USB-Backup-Platte)
> schon dann herauszuziehen, wenn "robocopy" (verfrüht) "fertig" meldet.

1: Windows meldet das nicht verfrüht, denn die Meldung von Robocopy bezieht
sich nicht aufs Trennen.
2: Der User darf zu jedem beliebigen Zeitpunkt auf "Trennen" klicken.
Windows gibt die Erlaubnis erst dann, wenn es möglich ist.

>> Der User klickt also einfach nur auf "Entfernen" und wartet, bis
>> Windows meldet "Du darfst jetzt entfernen".

> Eben - er darf sich (wie auch Du mehrfach eingeräumt hast) nicht auf die
> Meldung von "robocopy" verlassen.

Die Meldung von robocopy bezieht sich nur auf das Ende des Kopiervorganges,
des logischen Kopiervorganges und ist völlig irrelevant beim Trennen.
Außer dem Kopiervorgang können ja auch noch NTFS-Dateien beschrieben werden
oder Dummscanner oder andere Prozesse darauf zugreifen...
Beim Trennen ist einzig die Erlaubnis "sie dürfen jetzt trennen" relevant.
Der User darf sich hier auf gar nichts verlassen, außer auf diese Meldung.
Auch das ist ein sehr einfach zu realisierender Vorgang - sogar für DAUs -
sofern sie keine Hullen sind. ;->

Helmut Hullen

unread,
Jan 15, 2015, 11:37:30 PM1/15/15
to
Hallo, Hans-Peter,

Du meintest am 15.01.15:

>>> Auch das interessiert keinen User.

>> Du arbeitest mal wieder mit freien Erfindungen.

> Nein, du lügst mal wieder und bist merkbefreit.

Mal wieder eine öffentliche Beleidigung. Du wirst von meinem Anwalt
hören.

Sherlock

unread,
Jan 16, 2015, 9:29:28 AM1/16/15
to
Helmut Hullen:

>>> Du arbeitest mal wieder mit freien Erfindungen.

>> Nein, du lügst mal wieder und bist merkbefreit.

> Mal wieder eine öffentliche Beleidigung. Du wirst von meinem Anwalt
> hören.

Nur zu, gerne. Er bekommt dann deine ständigen öffentlichen Beleidigungen
zurück. :-)
It is loading more messages.
0 new messages