Discussion:
Laufwerk sicher auswerfen
(zu alt für eine Antwort)
Jürgen Meyer
2016-12-30 12:15:51 UTC
Permalink
Hier läuft Windows 10 Pro X64
Kein wirkliches Problem, aber trotzdem merkwürdig.
Ich habe zwei externe USB3-Laufwerke
Sind beide Laufwerkeangeschlossen und ich sage beim LW2 "Sicher entfernen",
dann können zwei unterschiedliche Dinge passieren:

1) Anstelle des LW2 wird das LW1 entfernt
Oder:
2) Es gibt eine Fehlermeldung (LW2 kann nicht entfernt werden, ist in
Gebrauch)
Ich hatte da zunächst den Virenscanner im Verdacht. Aber dann müsste das
Problem ja bei beiden LWs auftreten.
Die LWs sind unterschiedliche Fabrikate.
Daran kann es also auch nicht liegen.
Es ändert sich auch nichts, wenn ich die USB-Anschlüsse tausche.

Es ist für beide LWs "Schnelles Entfernen" aktiviert.

Ist nur eines der beiden LWs angeschlossen, gibt es keine Probleme.
Ist da was bekannt?

Gruß
Jürgen
Herrand Petrowitsch
2016-12-30 17:02:11 UTC
Permalink
Post by Jürgen Meyer
Hier läuft Windows 10 Pro X64
Kein wirkliches Problem, aber trotzdem merkwürdig.
Ich habe zwei externe USB3-Laufwerke
Sind beide Laufwerkeangeschlossen und ich sage beim LW2 "Sicher entfernen",
1) Anstelle des LW2 wird das LW1 entfernt
Bist du sicher, dich bei der Anwahl nicht geirrt zu haben?

Ist das Verhalten auch mit anderen USB-Geraeten nachvollziehbar? Hier
bemerke ich es nicht.
Post by Jürgen Meyer
2) Es gibt eine Fehlermeldung (LW2 kann nicht entfernt werden, ist in
Gebrauch)
Kenne ich in Verbindung mit einem SanDisk-Stick (Cruzer Titanium 4 GB),
der urspruenglich eigene SW mitbrachte. Verhielt sich aehnlich, nur dass
er sich als CD UND Wechseldatentraeger anmeldete und sich anfangs nicht
gerade freiwillig auswerfen liess.
Post by Jürgen Meyer
Ich hatte da zunächst den Virenscanner im Verdacht. Aber dann müsste das
Problem ja bei beiden LWs auftreten.
Nicht unbedingt.

Wenn du einen AV (welchen?) laufen hast, kann der selbstverstaendlich
abhaengig von Datenumfang und Zugriffsgeschwindigkeit unterschiedliche
Zeit benoetigen.
Post by Jürgen Meyer
Die LWs sind unterschiedliche Fabrikate.
Daran kann es also auch nicht liegen.
Kann durchaus, siehe oben.
Post by Jürgen Meyer
Es ändert sich auch nichts, wenn ich die USB-Anschlüsse tausche.
Es ist für beide LWs "Schnelles Entfernen" aktiviert.
Ist nur eines der beiden LWs angeschlossen, gibt es keine Probleme.
Ist da was bekannt?
Siehe oben.

Gruss Herrand
--
Emails an die angegebene Adresse werden gelegentlich sogar gelesen.
Henning Fischer
2016-12-30 17:49:39 UTC
Permalink
Post by Herrand Petrowitsch
Bist du sicher, dich bei der Anwahl nicht geirrt zu haben?
alle sind blöd außer dir.
Post by Herrand Petrowitsch
Ist das Verhalten auch mit anderen USB-Geraeten nachvollziehbar? Hier
bemerke ich es nicht.
z.B. Tastaturen und Mäuse, Scanner, Kameras usw.?
Post by Herrand Petrowitsch
Kenne ich in Verbindung mit einem SanDisk-Stick (Cruzer Titanium 4 GB),
der urspruenglich eigene SW mitbrachte. Verhielt sich aehnlich, nur dass
er sich als CD UND Wechseldatentraeger anmeldete und sich anfangs nicht
gerade freiwillig auswerfen liess.
ist aber keiner (s.o.)
Post by Herrand Petrowitsch
Nicht unbedingt.
Wenn du einen AV (welchen?) laufen hast, kann der selbstverstaendlich
abhaengig von Datenumfang und Zugriffsgeschwindigkeit unterschiedliche
Zeit benoetigen.
und die Ports verwechseln?
Post by Herrand Petrowitsch
Post by Jürgen Meyer
Die LWs sind unterschiedliche Fabrikate.
Daran kann es also auch nicht liegen.
Kann durchaus, siehe oben.
aha
Post by Herrand Petrowitsch
Post by Jürgen Meyer
Es ändert sich auch nichts, wenn ich die USB-Anschlüsse tausche.
Es ist für beide LWs "Schnelles Entfernen" aktiviert.
Ist nur eines der beiden LWs angeschlossen, gibt es keine Probleme.
Ist da was bekannt?
Siehe oben.
genau



völlig überfüssiges Posting (geh mal wieder in eure
Schreibzwang-Therapiegruppe, vielleicht gibt es da was neues, das dir
helfen könnte)
Claus Reibenstein
2016-12-30 21:24:48 UTC
Permalink
Post by Jürgen Meyer
Hier läuft Windows 10 Pro X64
Hier auch.
Post by Jürgen Meyer
Ich habe zwei externe USB3-Laufwerke
Sind beide Laufwerkeangeschlossen und ich sage beim LW2 "Sicher entfernen",
1) Anstelle des LW2 wird das LW1 entfernt
Derartiges ist mir noch nie passiert, und ich habe hier bisweilen bis zu
8 Laufwerke (6 Festplatten und 2 USB-Sticks) gleichzeitig laufen.
Allerdings sind davon maximal 4 USB-3 (2 Festplatten und 2 meiner vielen
USB-Sticks), und alle sind per USB-2 angeschlossen.
Post by Jürgen Meyer
2) Es gibt eine Fehlermeldung (LW2 kann nicht entfernt werden, ist in
Gebrauch)
Das kenne ich allerdings zur Genüge. Hauptverursacher scheint der
Taskmanager zu sein. Wenn dieses Fenster offen ist, lässt sich kein
einziges Laufwerk abmelden :-(

Manchmal hilft allerdings nichts außer Rechner runterfahren - oder
einfach abziehen, was hier allerdings schon mehrfach zu Datenverlust
geführt hat, weswegen ich diese Option nur im äußersten Notfall anwende.
Post by Jürgen Meyer
Es ist für beide LWs "Schnelles Entfernen" aktiviert.
Dann brauchst Du sie gar nicht abzumelden. Einfach rausziehen. Das ist
doch der Sinn dieser Option.

Ich verwende diese Option allerdings nicht.

Gruß
Claus
--
) )
(,) Ich wünsche allen Mitlesern (,)
__|__ ein gesegnetes Weihnachtsfest __|__
| | und einen guten Rutsch ins neue Jahr | |
Christoph Schneegans
2016-12-30 21:47:02 UTC
Permalink
Post by Jürgen Meyer
Sind beide Laufwerkeangeschlossen und ich sage beim LW2 "Sicher entfernen",
1) Anstelle des LW2 wird das LW1 entfernt
Habe ich noch nie beobachtet. So häufig kommt das Szenario bei mir aber
auch nicht vor.
Post by Jürgen Meyer
2) Es gibt eine Fehlermeldung (LW2 kann nicht entfernt werden, ist in
Gebrauch)
Process Explorer etwa per https://live.sysinternals.com/procexp.exe
starten, dann Strg+F und bspw. nach "E:\" suchen. Wenn man Glück hat,
findet man so den Prozeß, der auf das Laufwerk zugreift.
--
<http://schneegans.de/computer/safer/> · SAFER mit Windows
Detlef Wirsing
2016-12-30 21:53:48 UTC
Permalink
Post by Christoph Schneegans
Post by Jürgen Meyer
Sind beide Laufwerkeangeschlossen und ich sage beim LW2 "Sicher entfernen",
1) Anstelle des LW2 wird das LW1 entfernt
Habe ich noch nie beobachtet. So häufig kommt das Szenario bei mir aber
auch nicht vor.
[...]

Ich hatte mal ähnliche Probleme, als ich zwei baugleiche, gleichzeitig
gekaufte Platten in meiner Docking-Station hatte. Anscheinend konnte
das Betriebssystem die Platten mit identischer Firmware etc. nicht
auseinander halten.

Mit freundlichen Grüßen
Detlef Wirsing
Christoph Schneegans
2016-12-30 22:37:45 UTC
Permalink
Post by Detlef Wirsing
Ich hatte mal ähnliche Probleme, als ich zwei baugleiche, gleichzeitig
gekaufte Platten in meiner Docking-Station hatte. Anscheinend konnte
das Betriebssystem die Platten mit identischer Firmware etc. nicht
auseinander halten.
Möglicherweise war es ja vielmehr der Anwender, der sie nicht
auseinanderhalten konnte? ;-)
--
<http://schneegans.de/computer/safer/> · SAFER mit Windows
Jürgen Meyer
2016-12-31 11:11:46 UTC
Permalink
On Fri, 30 Dec 2016 23:37:45 +0100, Christoph Schneegans
Post by Christoph Schneegans
Post by Detlef Wirsing
Ich hatte mal ähnliche Probleme, als ich zwei baugleiche, gleichzeitig
gekaufte Platten in meiner Docking-Station hatte. Anscheinend konnte
das Betriebssystem die Platten mit identischer Firmware etc. nicht
auseinander halten.
Ja, das kenne ich auch noch von Windows 7. Waren zwei baugleiche USB2-HDs.
Jetzt läuft hier USB3. Ist auch ein anderer Rechner.
Post by Christoph Schneegans
Möglicherweise war es ja vielmehr der Anwender, der sie nicht
auseinanderhalten konnte? ;-)
Naheliegende Vermutung
Wenn es auftritt, lässt sich aber reproduzieren, sofern der Rechner nicht neu
gestartet wird.
(USB-Laufwerk abgezogen, neu angesteckt und dann wieder auf "Sicher entfernen"
geklickt"

Nach einem Neustart des Rechners tritt zunächst keines der beiden genannten
Probleme auf (Bis irgendwann mal).

Ist ja kein Drama. Bin nur neugierig.
Richtig ist auch, dass ich das "Sicher entfernen" ja eigentlich gar nicht
brauche, da ja "Schnelles Entfernen" aktiviert ist.

Gruß
Jürgen
Takvorian
2016-12-31 12:29:30 UTC
Permalink
Post by Jürgen Meyer
Richtig ist auch, dass ich das "Sicher entfernen" ja eigentlich gar nicht
brauche, da ja "Schnelles Entfernen" aktiviert ist.
Und laufende Schreibvorgänge werden dann beim Entfernen wie erkannt?
Falk Duebbert
2016-12-31 13:42:27 UTC
Permalink
Post by Takvorian
Post by Jürgen Meyer
Richtig ist auch, dass ich das "Sicher entfernen" ja eigentlich gar nicht
brauche, da ja "Schnelles Entfernen" aktiviert ist.
Und laufende Schreibvorgänge werden dann beim Entfernen wie erkannt?
"Schnelles Entfernen aktiviert" bedeutet, dass kein Schreibcache
aktiviert ist und die Schreibzugriffe auf dieses Laufwerk mit höherer
Priorität laufen. Außerdem werden größere Dateien in freie Sektoren
geschrieben und dann erst in die MFT / FAT committed. Es gibt keine
Updates von Dateien, die man nicht sofort abbrechen könnte.

Falk D.
Takvorian
2016-12-31 14:47:58 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Jürgen Meyer
Richtig ist auch, dass ich das "Sicher entfernen" ja eigentlich gar nicht
brauche, da ja "Schnelles Entfernen" aktiviert ist.
Und laufende Schreibvorgänge werden dann beim Entfernen wie erkannt?
"Schnelles Entfernen aktiviert" bedeutet, dass kein Schreibcache
aktiviert ist
Was die Performance in den tiefen Keller treibt.
Post by Falk Duebbert
und die Schreibzugriffe auf dieses Laufwerk mit höherer
Priorität laufen. Außerdem werden größere Dateien in freie Sektoren
geschrieben und dann erst in die MFT / FAT committed. Es gibt keine
Updates von Dateien, die man nicht sofort abbrechen könnte.
Das stellt leider nicht sicher, im Falle eines Trennens zum falschen
Zeitpunkt keine zerstörten, unbrauchbaren Schrott-Dateien zu bekommen.
Falk Duebbert
2016-12-31 15:42:24 UTC
Permalink
Post by Takvorian
Post by Falk Duebbert
"Schnelles Entfernen aktiviert" bedeutet, dass kein Schreibcache
aktiviert ist
Was die Performance in den tiefen Keller treibt.
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
Post by Takvorian
Post by Falk Duebbert
und die Schreibzugriffe auf dieses Laufwerk mit höherer
Priorität laufen. Außerdem werden größere Dateien in freie Sektoren
geschrieben und dann erst in die MFT / FAT committed. Es gibt keine
Updates von Dateien, die man nicht sofort abbrechen könnte.
Das stellt leider nicht sicher, im Falle eines Trennens zum falschen
Zeitpunkt keine zerstörten, unbrauchbaren Schrott-Dateien zu bekommen.
Eben doch. Siehe oben.

Falk D.
Takvorian
2016-12-31 16:36:21 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
"Schnelles Entfernen aktiviert" bedeutet, dass kein Schreibcache
aktiviert ist
Was die Performance in den tiefen Keller treibt.
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
USB-Platten werden als lokale Datenträger geführt und da bewirkt der Cache
z.B., dass ein Kopiervorgang ggf. mit ca. 3 GB/s, statt mit 150 oder 180
MB/s ausgeführt wird. Das ist ein netter Performance-Unterschied.
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
und die Schreibzugriffe auf dieses Laufwerk mit höherer
Priorität laufen. Außerdem werden größere Dateien in freie Sektoren
geschrieben und dann erst in die MFT / FAT committed. Es gibt keine
Updates von Dateien, die man nicht sofort abbrechen könnte.
Das stellt leider nicht sicher, im Falle eines Trennens zum falschen
Zeitpunkt keine zerstörten, unbrauchbaren Schrott-Dateien zu bekommen.
Eben doch. Siehe oben.
Kann jeder selbst leicht testen. Eine Datei kopieren und dabei das Ziel
trennen. Man wird die Datei im Ziel finden, logischerweise kapott. Mit
sicherem Trennen wäre das nicht passiert.
Falk Duebbert
2016-12-31 17:26:22 UTC
Permalink
Post by Takvorian
Post by Falk Duebbert
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
USB-Platten werden als lokale Datenträger geführt und da bewirkt der Cache
z.B., dass ein Kopiervorgang ggf. mit ca. 3 GB/s, statt mit 150 oder 180
MB/s ausgeführt wird. Das ist ein netter Performance-Unterschied.
Für Platten wird "schnelles Trennen" normalerweise nicht angeboten und
ist auch nicht supported - in sofern OT. Allerdings musst Du da ja
extreme Platten bei Dir haben: 3GB/s in real life habe ich nur bei M.2-
SSD-RAID0 und Server-Raids mit 12 und mehr Spindeln gesehen. Kann aber
auch sein, dass Du einfach nur einen vom Pferd erzählst und bei Dir ein
betagtes Medion Akoya steht, bei dem man wie jeder anderer SATA-Nutzer
mit unter 100MB/s zufrieden sein muss. Du kannst ja mal den Output von
Atto (bitte nicht nur 4k sequential, da kommt mein PC auch auf
Fantasiewerte) aus Deinem System posten. Oder anders gesagt: Show pix or
it ain't happen.
Post by Takvorian
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
und die Schreibzugriffe auf dieses Laufwerk mit höherer
Priorität laufen. Außerdem werden größere Dateien in freie Sektoren
geschrieben und dann erst in die MFT / FAT committed. Es gibt keine
Updates von Dateien, die man nicht sofort abbrechen könnte.
Das stellt leider nicht sicher, im Falle eines Trennens zum falschen
Zeitpunkt keine zerstörten, unbrauchbaren Schrott-Dateien zu bekommen.
Eben doch. Siehe oben.
Kann jeder selbst leicht testen. Eine Datei kopieren und dabei das Ziel
trennen. Man wird die Datei im Ziel finden, logischerweise kapott. Mit
sicherem Trennen wäre das nicht passiert.
Ok - für Dich zum mitmeißeln: solange kein Commit in die MFT oder FAT
stattgefunden hat, existiert die Datei für den nächsten Rechner nicht.
Ergo kann der Fall, den Du beschreibst, bei aktiviertem "schnellen
Trennen" nicht eintreten. Eintreten kann: "Datei da", "Datei nicht da"
oder mit extrem geringer Wahrscheinlichkeit "Dateisystem kaputt". Der
mit der kaputten Datei ist der einzige, der nicht eintreten kann.

Es täte Dir gut ein paar Grundlagen zu beherrschen, bevor Du Dir
Künstlernamen gibst. Kunst kommt von Können und nicht von Wünschen -
sonst hieße es Wunst.

Falk D.
Takvorian
2017-01-01 12:04:43 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
USB-Platten werden als lokale Datenträger geführt und da bewirkt der Cache
z.B., dass ein Kopiervorgang ggf. mit ca. 3 GB/s, statt mit 150 oder 180
MB/s ausgeführt wird. Das ist ein netter Performance-Unterschied.
Für Platten wird "schnelles Trennen" normalerweise nicht angeboten und
ist auch nicht supported - in sofern OT.
Nein. Ich hab's mir mittlerweile angewöhnt, den Status der USB-Platten nach
Updates zu prüfen, denn die stehen dann gerne mal wieder auf "schnelles
Entfernen" und ich muss dann die Schreibcaches für Windows und Hardware
wieder aktiv setzen. Lästig.
Post by Falk Duebbert
Allerdings musst Du da ja
extreme Platten bei Dir haben: 3GB/s in real life habe ich nur bei M.2-
SSD-RAID0 und Server-Raids mit 12 und mehr Spindeln gesehen. Kann aber
auch sein, dass Du einfach nur einen vom Pferd erzählst
Huh? Bei einem vom Cache gepufferten Kopiervorgang hat man die üblichen
RAM-typischen Transferraten - also so, als würde der Kopiervorgang innerhalb
einer RAM-Disk stattfinden. Also irgendwas zwischen 2 und 3 GB/s.
Die maximale physische Schreibrate auf die USB-HD hingegen beträgt ca. 180
MB/s.
Post by Falk Duebbert
Post by Takvorian
Kann jeder selbst leicht testen. Eine Datei kopieren und dabei das Ziel
trennen. Man wird die Datei im Ziel finden, logischerweise kapott. Mit
sicherem Trennen wäre das nicht passiert.
Ok - für Dich zum mitmeißeln: solange kein Commit in die MFT oder FAT
stattgefunden hat, existiert die Datei für den nächsten Rechner nicht.
Ergo kann der Fall, den Du beschreibst, bei aktiviertem "schnellen
Trennen" nicht eintreten.
Eintreten kann: "Datei da", "Datei nicht da"
oder mit extrem geringer Wahrscheinlichkeit "Dateisystem kaputt". Der
mit der kaputten Datei ist der einzige, der nicht eintreten kann.
Ich teste sowas im Gegensatz zu dir einfach: die Datei wird im Ziel
angezeigt, mit der erwarteten Größe, logischerweise aber kaputt, wenn man
sie öffnen will.
Post by Falk Duebbert
Es täte Dir gut ein paar Grundlagen zu beherrschen, bevor Du Dir
Künstlernamen gibst. Kunst kommt von Können und nicht von Wünschen -
sonst hieße es Wunst.
Es täte dir gut, deine vermeintlich beherrschten Grundlagen in der Praxis zu
testen, bevor du dich blamierst. ;->
Falk Duebbert
2017-01-01 12:59:00 UTC
Permalink
Post by Takvorian
Post by Falk Duebbert
Allerdings musst Du da ja
extreme Platten bei Dir haben: 3GB/s in real life habe ich nur bei M.2-
SSD-RAID0 und Server-Raids mit 12 und mehr Spindeln gesehen. Kann aber
auch sein, dass Du einfach nur einen vom Pferd erzählst
Huh? Bei einem vom Cache gepufferten Kopiervorgang hat man die üblichen
RAM-typischen Transferraten - also so, als würde der Kopiervorgang innerhalb
einer RAM-Disk stattfinden. Also irgendwas zwischen 2 und 3 GB/s.
Die maximale physische Schreibrate auf die USB-HD hingegen beträgt ca. 180
MB/s.
Deswegen SHO PIX OR IT AIN'T HAPPEN!

Der Windows-Seitige Schreibcache wirkt sich ungefähr genau gar nicht auf
die Schreibrate aus, weil er nach einem völlig anderem
Optimierungsschema arbeitet und primär dem besseren Alignment der
Streams dient.
Und der typische 64MB große Cache in den Festplatten dient ebenso fast
ausschließlich dazu, dass der Stream beim Head-Travel aufrecht erhalten
bleibt und der Bus nicht in Start/Stop umgeschaltet werden muss. Das ist
ein Erbe aus dem SCSI-Protokoll, das sowohl SAS als auch SATA belastet.

Du hast behauptet, auf trennbaren Festplatten Kopiervorgänge mit
3GByte/s, also dem 4-fachen der theoretischen Geschwindigkeit von SATA-
6G, zu haben und dass das normal sei.
Nebenbei würde das bei 4k-Sektorgröße auch minimal 786.432 IOPS
bedeuten. Was selbst als sequential Write eher ab 2 Höheneinheiten
Allflash zu erwarten ist. Ich bitte Dich jetzt nochmal, diese Leistungen
mit Screenshots und Protokollen von z.B. Atto oder HDD-info zu belegen.

Ansonsten dürfte jetzt jedem Leser klar sein, wer sich gerade blamiert.

Falk D.
Takvorian
2017-01-01 14:08:58 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
Allerdings musst Du da ja
extreme Platten bei Dir haben: 3GB/s in real life habe ich nur bei M.2-
SSD-RAID0 und Server-Raids mit 12 und mehr Spindeln gesehen. Kann aber
auch sein, dass Du einfach nur einen vom Pferd erzählst
Huh? Bei einem vom Cache gepufferten Kopiervorgang hat man die üblichen
RAM-typischen Transferraten - also so, als würde der Kopiervorgang innerhalb
einer RAM-Disk stattfinden. Also irgendwas zwischen 2 und 3 GB/s.
Die maximale physische Schreibrate auf die USB-HD hingegen beträgt ca. 180
MB/s.
Deswegen SHO PIX OR IT AIN'T HAPPEN!
Meinetwegen. Kopieren von 7 GB unter Mitwirkung des Caches:
Loading Image...
Wie du siehst, wird die erste Hälfte mit ca. 2,5 GB/s Transferrate
abgewickelt, nach Erschöpfung des Caches der Rest dann mit
192 MB/s, also die maximale physische Schreibrate der Platte.
Bei einer 2-GB-Datei, sähe es so aus, dass diese scheinbar in Nullzeit
kopiert wird, denn bei nur 2 GB wird der gesamte Kopiervorgang völlig vom
Cache abgedeckt. Es kommt als direkt nach Klick auf Einfügen von Windows die
Meldung "Datei wurde kopiert" und die Datei ist danach auch sofort im Ziel
bearbeitbar.
Hier auch noch das Log von robocopy vom Kopieren einer 2 GB-Datei auf die
USB-Platte unter Beteiligung des Lese- und Schreibcaches:
Insgesamt Kopiert
Dateien: 1 1
Bytes: 2.715 g 2.715 g
Zeiten: 0:00:01 0:00:01
Geschwindigkeit: 2073641881 Bytes/Sek.

Noch Fragen Kienzle? Oder willste hier Hullen & Co. ersetzen? ;->
Post by Falk Duebbert
Der Windows-Seitige Schreibcache wirkt sich ungefähr genau gar nicht auf
die Schreibrate aus, weil er nach einem völlig anderem
Optimierungsschema arbeitet und primär dem besseren Alignment der
Streams dient.
Und der typische 64MB große Cache in den Festplatten dient ebenso fast
ausschließlich dazu, dass der Stream beim Head-Travel aufrecht erhalten
bleibt und der Bus nicht in Start/Stop umgeschaltet werden muss. Das ist
ein Erbe aus dem SCSI-Protokoll, das sowohl SAS als auch SATA belastet.
Das ist abenteuerlich und grotesk flasch. Siehe oben.
Post by Falk Duebbert
Du hast behauptet, auf trennbaren Festplatten Kopiervorgänge mit
3GByte/s, also dem 4-fachen der theoretischen Geschwindigkeit von SATA-
6G, zu haben und dass das normal sei.
Ja, unter Mitwirkung des Lese/Schreibcaches völlig normal, denn dazu ist er
ja da! Der Cache ist RAM und Kopiervorgänge im RAM finden mit RAM-typischer
Geschwindigkeit statt.
Post by Falk Duebbert
Nebenbei würde das bei 4k-Sektorgröße auch minimal 786.432 IOPS
bedeuten. Was selbst als sequential Write eher ab 2 Höheneinheiten
Allflash zu erwarten ist. Ich bitte Dich jetzt nochmal, diese Leistungen
mit Screenshots und Protokollen von z.B. Atto oder HDD-info zu belegen.
Done. Dass dafür jemand aber Screenshots anfordert, ist höchst erstaunlich.
Dass kannte ich bisher nur von Hullen & Co.
Post by Falk Duebbert
Ansonsten dürfte jetzt jedem Leser klar sein, wer sich gerade blamiert.
Nach Kenntnisnahme des Screenshots auf jeden Fall.
Post by Falk Duebbert
Post by Takvorian
Ich teste sowas im Gegensatz zu dir einfach: die Datei wird im Ziel
angezeigt, mit der erwarteten Größe, logischerweise aber kaputt, wenn man
sie öffnen will.
Dann hast Du kein "schnelles Trennen" aktiviert.
Das ist für USB-Sticks Standard. War natürlich so eingestellt.
Kopiert wurde ein 500 MB mp4-Video. Der Stick wurde während des Kopierens
rausgezogen, danach wieder gemountet: Die Datei ist zu sehen, ist aber
logischerweise kapott.
Takvorian
2017-01-01 14:14:28 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
Allerdings musst Du da ja
extreme Platten bei Dir haben: 3GB/s in real life habe ich nur bei M.2-
SSD-RAID0 und Server-Raids mit 12 und mehr Spindeln gesehen. Kann aber
auch sein, dass Du einfach nur einen vom Pferd erzählst
Huh? Bei einem vom Cache gepufferten Kopiervorgang hat man die üblichen
RAM-typischen Transferraten - also so, als würde der Kopiervorgang innerhalb
einer RAM-Disk stattfinden. Also irgendwas zwischen 2 und 3 GB/s.
Die maximale physische Schreibrate auf die USB-HD hingegen beträgt ca. 180
MB/s.
Deswegen SHO PIX OR IT AIN'T HAPPEN!
Meinetwegen. Kopieren von 7 GB unter Mitwirkung des Caches:
http://img5.fotos-hochladen.net/uploads/kopierenzwr5m1jxq0.jpg
Wie du siehst, wird die erste Hälfte mit ca. 2,5 GB/s Transferrate
abgewickelt, nach Erschöpfung des Caches der Rest dann mit
192 MB/s, also die maximale physische Schreibrate der Platte.
Bei einer 2-GB-Datei, sähe es so aus, dass diese scheinbar in Nullzeit
kopiert wird, denn bei nur 2 GB wird der gesamte Kopiervorgang völlig vom
Cache abgedeckt. Es kommt als direkt nach Klick auf Einfügen von Windows die
Meldung "Datei wurde kopiert" und die Datei ist danach auch sofort im Ziel
bearbeitbar.
Hier auch noch das Log von robocopy vom Kopieren einer 2 GB-Datei auf die
USB-Platte unter Beteiligung des Lese- und Schreibcaches:
Insgesamt Kopiert
Dateien: 1 1
Bytes: 2.715 g 2.715 g
Zeiten: 0:00:01 0:00:01
Geschwindigkeit: 2073641881 Bytes/Sek.

Noch Fragen Kienzle? Oder willste hier Hullen & Co. ersetzen? ;->
Post by Falk Duebbert
Der Windows-Seitige Schreibcache wirkt sich ungefähr genau gar nicht auf
die Schreibrate aus, weil er nach einem völlig anderem
Optimierungsschema arbeitet und primär dem besseren Alignment der
Streams dient.
Und der typische 64MB große Cache in den Festplatten dient ebenso fast
ausschließlich dazu, dass der Stream beim Head-Travel aufrecht erhalten
bleibt und der Bus nicht in Start/Stop umgeschaltet werden muss. Das ist
ein Erbe aus dem SCSI-Protokoll, das sowohl SAS als auch SATA belastet.
Das ist abenteuerlich und grotesk flasch. Siehe oben.
Post by Falk Duebbert
Du hast behauptet, auf trennbaren Festplatten Kopiervorgänge mit
3GByte/s, also dem 4-fachen der theoretischen Geschwindigkeit von SATA-
6G, zu haben und dass das normal sei.
Ja, unter Mitwirkung des Lese/Schreibcaches völlig normal, denn dazu ist er
ja da! Der Cache ist RAM und Kopiervorgänge im RAM finden mit RAM-typischer
Geschwindigkeit statt.
Post by Falk Duebbert
Nebenbei würde das bei 4k-Sektorgröße auch minimal 786.432 IOPS
bedeuten. Was selbst als sequential Write eher ab 2 Höheneinheiten
Allflash zu erwarten ist. Ich bitte Dich jetzt nochmal, diese Leistungen
mit Screenshots und Protokollen von z.B. Atto oder HDD-info zu belegen.
Done. Dass dafür jemand aber Screenshots anfordert, ist höchst erstaunlich.
Das kannte ich bisher nur von Hullen & Co.
Post by Falk Duebbert
Ansonsten dürfte jetzt jedem Leser klar sein, wer sich gerade blamiert.
Nach Kenntnisnahme des Screenshots auf jeden Fall.
Post by Falk Duebbert
Post by Takvorian
Ich teste sowas im Gegensatz zu dir einfach: die Datei wird im Ziel
angezeigt, mit der erwarteten Größe, logischerweise aber kaputt, wenn man
sie öffnen will.
Dann hast Du kein "schnelles Trennen" aktiviert.
Das ist für USB-Sticks Standard. War natürlich so eingestellt.
Kopiert wurde ein 500 MB mp4-Video. Der Stick wurde während des Kopierens
rausgezogen, danach wieder gemountet: Die Datei ist zu sehen, ist aber
logischerweise kapott.
Falk Duebbert
2017-01-01 14:44:12 UTC
Permalink
Post by Takvorian
http://img5.fotos-hochladen.net/uploads/kopierenzwr5m1jxq0.jpg
Noch einer, der die Spurts-basierte Kopie nicht verstanden hat.
In dem Teil mit Deiner "hohen Datenrate" wurde effektiv fast nichts
gelesen oder geschrieben, sondern nur die Streamchannels reserviert, die
dann in sogenannten Spurts abgearbeitet werden. Windows verkauft das
Teil des Transports. Nebenbei sollte man die Skalierung beachten.

Das ist hier ganz gut erklärt: https://is.gd/SOwqi2

Deswegen verlangte ich nach einem Graphen aus zum Beispiel Atto.

Falk D.
Takvorian
2017-01-01 15:01:18 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
http://img5.fotos-hochladen.net/uploads/kopierenzwr5m1jxq0.jpg
Noch einer, der die Spurts-basierte Kopie nicht verstanden hat.
In dem Teil mit Deiner "hohen Datenrate" wurde effektiv fast nichts
gelesen oder geschrieben, sondern nur die Streamchannels reserviert, die
dann in sogenannten Spurts abgearbeitet werden. Windows verkauft das
Teil des Transports. Nebenbei sollte man die Skalierung beachten.
Das ist hier ganz gut erklärt: https://is.gd/SOwqi2
Noch einer, der den Sinn des Caches nicht verstanden hat. Jetzt fällt dir
also nur noch Lötzinn ein.
Kopieren mit Cache:
"Datei wurde kopiert" kommt sofort - 2 GB/s - Datei nach dieser Meldung
sofort bearbeitbar.
Kopieren ohne Cache: "Datei wurde kopiert" erst nach x Sekunden Wartezeit,
180 MB/s - Datei erst dann bearbeitbar.

FYI: Der Kopiervorgang ist für Windows dann beendet, wenn der LOGISCHE
Kopiervorgang beendet ist. Die Datei ist dann frei zur Bearbeitung am Ziel.
Ohne Cache muss der User warten, bis der physische Kopiervorgang beendet
ist, weil logischer und physischer Kopiervorgang praktisch gleich sind.
Ob ein User auf die Datei x Sekunden warten muss oder sie sofort bearbeiten
kann, ist ein handgreiflicher Unterschied, das nennt man "Performance des
Systems". Je mehr RAM, desto besser klappt das.
Falk Duebbert
2017-01-01 15:48:46 UTC
Permalink
Post by Takvorian
"Datei wurde kopiert" kommt sofort - 2 GB/s - Datei nach dieser Meldung
sofort bearbeitbar.
Kopieren ohne Cache: "Datei wurde kopiert" erst nach x Sekunden Wartezeit,
180 MB/s - Datei erst dann bearbeitbar.
Du hast drei Eimer Wasser.

Einen nennen wir "Quelle", einen "Cache" und einen Ziel. Es gibt eine
schnelle Pumpe die von "Quelle" nach "Cache" pumpen kann und eine, die
mit normaler Geschwindigkeit von "Cache" nach "Ziel" pumpen kann.

Welche Geschwindigkeit von welcher Pumpe ist wohl für den gesamten
Pumpvorgang entscheidend?

Falk D.
Takvorian
2017-01-01 17:18:20 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
"Datei wurde kopiert" kommt sofort - 2 GB/s - Datei nach dieser Meldung
sofort bearbeitbar.
Kopieren ohne Cache: "Datei wurde kopiert" erst nach x Sekunden Wartezeit,
180 MB/s - Datei erst dann bearbeitbar.
Du hast drei Eimer Wasser.
Einen nennen wir "Quelle", einen "Cache" und einen Ziel. Es gibt eine
schnelle Pumpe die von "Quelle" nach "Cache" pumpen kann und eine, die
mit normaler Geschwindigkeit von "Cache" nach "Ziel" pumpen kann.
Welche Geschwindigkeit von welcher Pumpe ist wohl für den gesamten
Pumpvorgang entscheidend?
Unter Mitwirkung des Cache wird physisch *gar nichts* ans Ziel gepumpt.
Das läuft dann später unsichtbar nebenher im Hintergrund. Man kann es z.B.
im Ressourcenmonitor verfolgen. Für den User verläuft der Transfer mit
RAM-Geschwindigkeit, siehe das Robocopy-Log oder der Explorer zeigt als
Transferrate 2,5 GB/s an.
Die Datei ist zwar am Ziel sichtbar und kann dort auch bearbeitet und
verändert werden, am Ziel selbst spielt sich das physisch nicht ab, wie
sollte es auch, wenn die Datei dort noch gar nicht existiert?
Man denke sich einen Cache mit einer Schreibverzögerung von 10 Minuten.
Windows meldet also sofort "Datei wurde kopiert" - am Ziel hat sich
physisch genau gar nichts getan. Muss der User dann 10 Minuten warten, bis
er die Datei am Ziel bearbeiten kann, weil erst dann der physische
Schreibvorgang ans Ziel einsetzt?
Den physischen Schreibvorgang bemerkt man als User nur dann, wenn man das
Ziel sofort nach der Meldung "Datei wurde kopiert" trennen will. Das klappt
erst dann, wenn auch der physische Schreibvorgang erledigt ist.
Oder ein Suchvorgang auf Laufwerk X:
Die Suche rödelt 30 Sekunden auf der HD rum und bringt dann endlich das
Ergebnis. Ein späterer Suchvorgang nach einer anderen Datei bringt das
Ergebnis schon nach 2 Sekunden, weil die Suche nun aus dem Cache bedient
wurde und nicht von der lahmen HD. Ist die zweite Suche auf der HD falsch
oder nicht echt, weil effektiv auf der HD gar keine Suche stattfand? Tausend
weitere Beispiele kann man sich ersparen...
Falk Duebbert
2017-01-01 17:47:40 UTC
Permalink
Post by Takvorian
Für den User verläuft der Transfer mit
RAM-Geschwindigkeit, siehe das Robocopy-Log oder der Explorer zeigt als
Transferrate 2,5 GB/s an.
Und diese Daten kommen aus dem Nichts?

Warum diese Zahlen, die Du zu haben glaubst, nichts wert sind, kannst Du
Dir nach der Lektüre von
http://www.brendangregg.com/Slides/QCon2015_Broken_Performance_Tools.pdf
vielleicht Denken.

Egal. Du hast Dich für heute ausreichend blamiert.

Falk D.
Stefan Kanthak
2017-01-01 19:01:06 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Für den User verläuft der Transfer mit
RAM-Geschwindigkeit, siehe das Robocopy-Log oder der Explorer zeigt als
Transferrate 2,5 GB/s an.
Und diese Daten kommen aus dem Nichts?
Nein, Dummerchen, aus der Division von Dateigroesse durch verstrichene
Zeit; bei "laufender" Anzeige aus der Division von "geschriebene Bytes"
(wie von [Nt]WriteFile() zurueckgemeldet) durch "verstrichene Zeit".
Post by Falk Duebbert
Warum diese Zahlen, die Du zu haben glaubst, nichts wert sind, kannst Du
Dir nach der Lektüre von
http://www.brendangregg.com/Slides/QCon2015_Broken_Performance_Tools.pdf
vielleicht Denken.
Er schon, Du definitiv NICHT!

| ... doesn't resemble real world.

JFTR: "real world" ist
CMD.exe /K echo !TIME! && copy <grosse_datei> <USB>: && echo !TIME! && Rem <USB>:\<grosse_datei> weiterverarbeiten
Post by Falk Duebbert
Egal. Du hast Dich für heute ausreichend blamiert.
Schreibt der sich hier mal wieder durch voelligen Bloedsinn statt der
sonst ueblichen Luegen und Verleumdungen "auszeichnende" ahnungslose
Dummschwaetzer!

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Takvorian
2017-01-02 14:46:59 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Für den User verläuft der Transfer mit
RAM-Geschwindigkeit, siehe das Robocopy-Log oder der Explorer zeigt als
Transferrate 2,5 GB/s an.
Und diese Daten kommen aus dem Nichts?
Warum diese Zahlen, die Du zu haben glaubst, nichts wert sind, kannst Du
Dir nach der Lektüre von
http://www.brendangregg.com/Slides/QCon2015_Broken_Performance_Tools.pdf
vielleicht Denken.
Diese Zahlen kommen ebenso wenig aus dem Nichts, wie die angezeigte
Transfergeschwindigkeit innerhalb einer RAM-Disk aus dem Nichts kommt.
Es sind die üblichen Zahlen für RAM-Kopiervorgänge.

Und wie kommst du auf das schmale Brett, diese Zahlen seien nichts wert?
Sie machen den für den User handgreiflichen Unterschied von 13 Sekunden aus!
Oder ist es für dich gleich, wenn die Meldung "Datei wurde kopiert" im einen
Fall nach 13 Sekunden, im zweiten Fall aber sofort erscheint?

-------------------------------------------------------------------
Noch mal die Zahlen:
Kopiervorgang ohne Cache auf die USB-Disk:

Insgesamt Kopiert
Dateien: 1 1
Bytes: 2.002 g 2.002 g
Zeiten: 0:00:13 0:00:12
Geschwindigkeit: 165476112 Bytes/Sek.

Hier der Fall, in dem der Kopiervorgang komplett vom Cache bedient wird:
(Datei existiert also schon im Lesecache!)

Insgesamt Kopiert
Dateien: 1 1
Bytes: 2.002 g 2.002 g
Zeiten: 0:00:00 0:00:00
Geschwindigkeit: 2190115106 Bytes/Sek.
-------------------------------------------------------------------
Im ersten Fall also 13 Sekunden, im zweiten Fall Nullzeit (= kleiner als
eine Sekunde). Preisfrage: Wie lange dauert das Kopieren von ca. 2 GB bei
einer Transferrate von ca. 2 GB/s?
Post by Falk Duebbert
Egal. Du hast Dich für heute ausreichend blamiert.
Scherzkeks. Ich hatte dir deutliche Screenshots und Zahlen aus Logs genannt.
Wenn sich jemand blamiert, dann der, der sie nicht versteht. Besser, man
verzichtet auf solche Kindereien und bleibt sachlich.

Warum hast du meine Frage nach dem Cache mit Schreibverzögerung eigentlich
nicht beantwortet?

Ich kopiere dir hier noch mal Stefans Antwort rein, die du mit deinem
Schrott-Newsserver ja nicht lesen konntest:
Message-ID: <o4bk8v$2ukn$***@adenine.netfront.net>
Zitat:
-----------------------------------------------------------------
Post by Falk Duebbert
Post by Takvorian
Für den User verläuft der Transfer mit
RAM-Geschwindigkeit, siehe das Robocopy-Log oder der Explorer zeigt als
Transferrate 2,5 GB/s an.
Und diese Daten kommen aus dem Nichts?
Nein, Dummerchen, aus der Division von Dateigroesse durch verstrichene
Zeit; bei "laufender" Anzeige aus der Division von "geschriebene Bytes"
(wie von [Nt]WriteFile() zurueckgemeldet) durch "verstrichene Zeit".
Post by Falk Duebbert
Warum diese Zahlen, die Du zu haben glaubst, nichts wert sind, kannst Du
Dir nach der Lektüre von
http://www.brendangregg.com/Slides/QCon2015_Broken_Performance_Tools.pdf
vielleicht Denken.
Er schon, Du definitiv NICHT!

| ... doesn't resemble real world.

JFTR: "real world" ist
CMD.exe /K echo !TIME! && copy <grosse_datei> <USB>: && echo !TIME! &&
Rem <USB>:\<grosse_datei> weiterverarbeiten
Post by Falk Duebbert
Egal. Du hast Dich für heute ausreichend blamiert.
Schreibt der sich hier mal wieder durch voelligen Bloedsinn statt der
sonst ueblichen Luegen und Verleumdungen "auszeichnende" ahnungslose
Dummschwaetzer!
-------------------------------------------------------------
Zitat Ende.
Falk Duebbert
2017-01-02 15:03:47 UTC
Permalink
Post by Takvorian
Post by Falk Duebbert
Und diese Daten kommen aus dem Nichts?
Diese Zahlen kommen ebenso wenig aus dem Nichts, wie die angezeigte
Transfergeschwindigkeit innerhalb einer RAM-Disk aus dem Nichts kommt.
Es sind die üblichen Zahlen für RAM-Kopiervorgänge.
Ich schrieb: "Diese Daten", denn die Daten, die Dein Cache mit 3GB/s
kopieren will, müssen ja irgendwo herkommen.

Falk D.
Takvorian
2017-01-02 19:44:40 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
Und diese Daten kommen aus dem Nichts?
Diese Zahlen kommen ebenso wenig aus dem Nichts, wie die angezeigte
Transfergeschwindigkeit innerhalb einer RAM-Disk aus dem Nichts kommt.
Es sind die üblichen Zahlen für RAM-Kopiervorgänge.
Ich schrieb: "Diese Daten", denn die Daten, die Dein Cache mit 3GB/s
kopieren will, müssen ja irgendwo herkommen.
Wie kommen Daten in den Cache? Weil sie irgendwann vorher schon mal genutzt
wurden oder weil die Speicherverwaltung sie von sich aus reinschaufelt für
Superfetch, wie sonst sollten sie hinein kommen?
Der Cache ist zu dem Zeitpunkt also mit 2 GB befüllt. Nach dem Kopiervorgang
ist er dann auf 4 GB angewachsen, die Datei wurde innerhalb des Cache also
kopiert/verdoppelt, daher die Anzeige von 2,5 GB/s beim Kopieren auf die
USB-Disk. Das ist die Transferrate des *logischen* Kopiervorganges und nur
der zählt für den User - sofern nicht der Sonderfall gegeben ist, dass das
Ziel sofort getrennt werden soll. Voraussetzung: Der Windows-Schreibcache
für die USB-Platte wurde aktiviert. Falls nicht, kommt nur die normale
HD-Transferrate von 180 MB/s zum Zuge.
Stefan Kanthak
2017-01-02 19:51:11 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
Und diese Daten kommen aus dem Nichts?
Diese Zahlen kommen ebenso wenig aus dem Nichts, wie die angezeigte
Transfergeschwindigkeit innerhalb einer RAM-Disk aus dem Nichts kommt.
Es sind die üblichen Zahlen für RAM-Kopiervorgänge.
Ich schrieb: "Diese Daten", denn die Daten, die Dein Cache mit 3GB/s
kopieren will, müssen ja irgendwo herkommen.
Fuer die Funktion eines "write back" oder "wite behind"-Caches ist es
VOELLIG wurscht, woher die Daten kommen: seine Aufgabe ist es ja gerade,
eine schnelle Quelle von einem langsam(er)en Ziel zu entkoppeln.

wehret den ahnungslosen Dummschwaetzern!
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Henning Fischer
2017-01-02 20:55:08 UTC
Permalink
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Claus Reibenstein
2017-01-02 21:50:38 UTC
Permalink
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.

Gruß
Claus
Henning Fischer
2017-01-02 22:03:23 UTC
Permalink
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
klingt logisch

Gruß
Henning
Joerg Lorenz
2017-01-03 05:39:42 UTC
Permalink
Post by Henning Fischer
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
klingt logisch
Aber nur scheinbar.
--
http://www.albasani.net/index.html.de
Ein freier und kostenloser Server fuer Usenet/NetNews (NNTP)
Schorsch
2017-01-02 22:06:41 UTC
Permalink
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
Wenn Ihr (alles die die Aussage für richtig halten) es doch tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.

Gruß
Schorsch
Joerg Lorenz
2017-01-03 05:41:14 UTC
Permalink
Post by Schorsch
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
Wenn Ihr (alles die die Aussage für richtig halten) es doch tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.
Dann geht gar nichts mehr, wie im Rest des Usenet.
Und ob sie dazu überhaupt in der Lage sind, ist auch noch die Frage.
--
http://www.albasani.net/index.html.de
Ein freier und kostenloser Server fuer Usenet/NetNews (NNTP)
Lutz E. Cerning
2017-01-03 10:18:40 UTC
Permalink
Post by Joerg Lorenz
Dann geht gar nichts mehr, wie im Rest des Usenet.
Und ob sie dazu überhaupt in der Lage sind, ist auch noch die Frage.
<Hoffnung an>
Vlt. begreifen die ganzen Mio. FB-, TW-, WA- etc. -nutzer ja mal
irgendwann, dass *da* nicht viel Sinnvolles zu holen ist und tauschen
(wieder) /echte/ Nachrichten aus. Hier z.B. ....
<Hoffnung aus>
--
Grüße von LutzeC*54 aus
(ca.) 52.64736,13.550518
Sepp Neuper
2017-01-04 19:51:51 UTC
Permalink
Post by Joerg Lorenz
Post by Schorsch
Post by Claus Reibenstein
Indem wir Kanthak, Takvorian & Co filtern.
Wenn Ihr (alles die die Aussage für richtig halten) es doch tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.
Dann geht gar nichts mehr, wie im Rest des Usenet.
Gut erkannt.
Der größte Teil des Usenets ist bereits "lesbar".
Weit und breit niemand, der beim Lesen stören könnte.

Servus, Sepp
Detlef Wirsing
2017-01-04 20:45:08 UTC
Permalink
Sepp Neuper schrieb:

[...]
Post by Sepp Neuper
Der größte Teil des Usenets ist bereits "lesbar".
Weit und breit niemand, der beim Lesen stören könnte.
Inzwischen getrennt lebend?

Mit freundlichen Grüßen
Detlef Wirsing
Jonas Klein
2017-01-03 13:52:29 UTC
Permalink
Post by Schorsch
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
Wenn Ihr (alles die die Aussage für richtig halten) es doch
tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Im konkreten Fall ein Filter mit:
Text enthält (den Namen XYZ, der immer wieder einen
Rattenschwanz an Reaktionen verursacht, die mich nicht die
Bohne interessieren) -> Löschen der Nachricht.
Stefan Kanthak
2017-01-03 16:40:07 UTC
Permalink
"Jonas Klein" <***@habmalnefrage.de> schrieb:

[...]
Post by Jonas Klein
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Du: gar nicht!

| User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
| X-Antivirus-Status: Clean
| X-Antivirus: avast! (VPS 170103-0, 03.01.2017), Outbound message

Wer mit solchem veralteten und unsicheren Schrott das USENET unsicher
macht ist voellig ahnungslos und komplett bescheuert.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Sepp Neuper
2017-01-04 19:56:27 UTC
Permalink
Post by Stefan Kanthak
Post by Jonas Klein
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Du: gar nicht!
| User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
| X-Antivirus-Status: Clean
| X-Antivirus: avast! (VPS 170103-0, 03.01.2017), Outbound message
Wer mit solchem veralteten und unsicheren Schrott das USENET unsicher
macht ist voellig ahnungslos und komplett bescheuert.
Mittlerweile finde ich den Stefan sogar irgendwie witzig in seiner
Bizzarheit.

bye, Sepp
Jonas Klein
2017-01-04 23:12:46 UTC
Permalink
Post by Stefan Kanthak
Post by Jonas Klein
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Du: gar nicht!
| User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
| X-Antivirus-Status: Clean
| X-Antivirus: avast! (VPS 170103-0, 03.01.2017), Outbound message
Wer mit solchem veralteten und unsicheren Schrott das USENET unsicher
macht ist voellig ahnungslos und komplett bescheuert.
Genau wegen solcher Behauptungen möchte ich alles mit
Kanthak im Text gar nicht zu Gesicht bekommen und ich bitte
ihn darum, mich wegzufiltern. Dann sind wir beide glücklicher.
Ruediger Lahl
2017-01-04 23:54:40 UTC
Permalink
Post by Jonas Klein
Post by Stefan Kanthak
Post by Jonas Klein
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Du: gar nicht!
| User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
| X-Antivirus-Status: Clean
| X-Antivirus: avast! (VPS 170103-0, 03.01.2017), Outbound message
Wer mit solchem veralteten und unsicheren Schrott das USENET unsicher
macht ist voellig ahnungslos und komplett bescheuert.
Genau wegen solcher Behauptungen möchte ich alles mit
Kanthak im Text gar nicht zu Gesicht bekommen und ich bitte
ihn darum, mich wegzufiltern. Dann sind wir beide glücklicher.
Folgende security-bugfixes hast du bis jetzt verpasst:

Security vulnerabilities fixed in Thunderbird 45.6

# Fixed in Thunderbird 45.5.1

2016-92 Firefox SVG Animation Remote Code Execution

# Fixed in Thunderbird 45.5

2016-93 Security vulnerabilities fixed in Thunderbird 45.5

# Fixed in Thunderbird 45.4

2016-88 Security vulnerabilities fixed in Thunderbird 45.4

# Fixed in Thunderbird 45.3

2016-62 Miscellaneous memory safety hazards (rv:48.0 / rv:45.3)

# Fixed in Thunderbird 45.2

2016-49 Miscellaneous memory safety hazards (rv:47.0 / rv:45.2)

# Fixed in Thunderbird 45.1

2016-39 Miscellaneous memory safety hazards (rv:46.0 / rv:45.1 /rv:38.8)

# Fixed in Thunderbird 45

2016-37 Font vulnerabilities in the Graphite 2 library
2016-36 Use-after-free during processing of DER encoded keys in NSS
2016-35 Buffer overflow during ASN.1 decoding in NSS
2016-34 Out-of-bounds read in HTML parser following a failed allocation
2016-27 Use-after-free during XML transformations
2016-24 Use-after-free in SetBody
2016-23 Use-after-free in HTML5 string parser
2016-20 Memory leak in libstagefright when deleting an array during MP4 processing
2016-19 Linux video memory DOS with Intel drivers
2016-18 CSP reports fail to strip location information for embedded iframe pages
2016-17 Local file overwriting and potential privilege escalation through CSP reports
2016-16 Miscellaneous memory safety hazards (rv:45.0 / rv:38.7)

# Fixed in Thunderbird 38.8

2016-39 Miscellaneous memory safety hazards (rv:46.0 / rv:45.1 / rv:38.8)
2016-36 Use-after-free during processing of DER encoded keys in NSS

# Fixed in Thunderbird 38.7

2016-37 Font vulnerabilities in the Graphite 2 library
2016-35 Buffer overflow during ASN.1 decoding in NSS
2016-34 Out-of-bounds read in HTML parser following a failed allocation
2016-31 Memory corruption with malicious NPAPI plugin
2016-27 Use-after-free during XML transformations
2016-24 Use-after-free in SetBody
2016-23 Use-after-free in HTML5 string parser
2016-20 Memory leak in libstagefright when deleting an array during MP4 processing
2016-17 Local file overwriting and potential privilege escalation through CSP reports
2016-16 Miscellaneous memory safety hazards (rv:45.0 / rv:38.7)

# Fixed in Thunderbird 38.6

2016-14 Vulnerabilities in Graphite 2
2016-03 Buffer overflow in WebGL after out of memory allocation
2016-01 Miscellaneous memory safety hazards (rv:44.0 / rv:38.6)
2015-150 MD5 signatures accepted within TLS 1.2 ServerKeyExchange in server signature

# Fixed in Thunderbird 38.5

2015-149 Cross-site reading attack through data and view-source URIs
2015-146 Integer overflow in MP4 playback in 64-bit versions
2015-145 Underflow through code inspection
2015-139 Integer overflow allocating extremely large textures
2015-134 Miscellaneous memory safety hazards (rv:43.0 / rv:38.5)

# Fixed in Thunderbird 38.4

2015-133 NSS and NSPR memory corruption issues
2015-132 Mixed content WebSocket policy bypass through workers
2015-131 Vulnerabilities found through code inspection
2015-128 Memory corruption in libjar through zip files
2015-127 CORS preflight is bypassed when non-standard Content-Type headers are received
2015-123 Buffer overflow during image interactions in canvas
2015-122 Trailing whitespace in IP address hostnames can bypass same-origin policy
2015-116 Miscellaneous memory safety hazards (rv:42.0 / rv:38.4)

# Fixed in Thunderbird 38.3

2015-113 Memory safety errors in libGLES in the ANGLE graphics library
2015-112 Vulnerabilities found through code inspection
2015-111 Errors in the handling of CORS preflight request headers
2015-110 Dragging and dropping images exposes final URL after redirects
2015-106 Use-after-free while manipulating HTML media content
2015-105 Buffer overflow while decoding WebM video
2015-101 Buffer overflow in libvpx while parsing vp9 format video
2015-100 Arbitrary file manipulation by local user through Mozilla updater
2015-96 Miscellaneous memory safety hazards (rv:41.0 / rv:38.3)

# Fixed in Thunderbird 38.2

2015-90 Vulnerabilities found through code inspection
2015-88 Heap overflow in gdk-pixbuf when scaling bitmap images
2015-85 Out-of-bounds write with Updater and malicious MAR file
2015-84 Arbitrary file overwriting through Mozilla Maintenance Service with hard links
2015-79 Miscellaneous memory safety hazards (rv:40.0 / rv:38.2)

# Fixed in Thunderbird 38.1

2015-71 NSS incorrectly permits skipping of ServerKeyExchange
2015-70 NSS accepts export-length DHE keys with regular DHE cipher suites
2015-67 Key pinning is ignored when overridable errors are encountered
2015-66 Vulnerabilities found through code inspection
2015-63 Use-after-free in Content Policy due to microtask execution error
2015-59 Miscellaneous memory safety hazards (rv:39.0 / rv:31.8 / rv:38.1)

Dabei waren nur 11 Bugs, die nicht als 'kritisch' oder 'hoch' eingestuft
wurden.

Möchtest du weiterhin jemanden filtern, der DICH darauf hinweist, dass
das von dir benutzte Programm mittlerweile *16* Aktualisierungen
erfahren hat, die *68* sicherheitsrelevante Fehler behoben haben, welche
in deiner Version noch vorhanden sind?
--
bis denne
Michael Graf
2017-01-05 08:23:27 UTC
Permalink
Hi!
[...]

Mir ist eh nicht klar, wieso man so viele updates verpasst hat. TB
aktuell zu halten ist nun wirklich kein Hexenwerk.
Gut, laut SK sind TB und FF ja "broken by design", wissen wir ja.

Michael
Claus Reibenstein
2017-01-05 08:28:46 UTC
Permalink
Post by Jonas Klein
Genau wegen solcher Behauptungen möchte ich alles mit
Kanthak im Text gar nicht zu Gesicht bekommen und ich bitte
ihn darum, mich wegzufiltern. Dann sind wir beide glücklicher.
Wie jetzt? Du willst ihn nicht lesen, also soll er Dich wegfiltern? So
wird das nix.

Wenn Du ihn nicht lesen willst, musst Du ihn wegfiltern. Nur so kann es
funktionieren.

Gruß
Claus
Jonas Klein
2017-01-05 11:50:20 UTC
Permalink
Post by Claus Reibenstein
Post by Jonas Klein
Genau wegen solcher Behauptungen möchte ich alles mit
Kanthak im Text gar nicht zu Gesicht bekommen und ich bitte
ihn darum, mich wegzufiltern. Dann sind wir beide glücklicher.
Wie jetzt? Du willst ihn nicht lesen, also soll er Dich wegfiltern? So
wird das nix.
Wenn Du ihn nicht lesen willst, musst Du ihn wegfiltern. Nur so kann es
funktionieren.
Wegfiltern? Schon längst gemacht. Aber das hilft nicht
weiter, wenn nicht Gefilterte seine Beleidigungen wiedergeben.
Hoffentlich klappt es mit neuen Themen doch, da ich gestern
Jörgs Rat gefolgt bin und als Filter "Unterthema ignorieren"
statt "Löschen der Nachricht" eingestellt habe.
Stefan Kanthak
2017-01-05 13:02:58 UTC
Permalink
"Sepp Neuper" <***@web.de> schrieb:

| X-Newsreader: Forte Agent 1.91/32.564

Wer mit solchem veralteten und unsicheren Schrott das USENET unsicher
macht ist voellig ahnungslos und komplett bescheuert.
Post by Sepp Neuper
Post by Stefan Kanthak
Post by Jonas Klein
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Du: gar nicht!
| User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
| X-Antivirus-Status: Clean
| X-Antivirus: avast! (VPS 170103-0, 03.01.2017), Outbound message
Wer mit solchem veralteten und unsicheren Schrott das USENET unsicher
macht ist voellig ahnungslos und komplett bescheuert.
Mittlerweile finde ich den Stefan sogar irgendwie witzig in seiner
Bizzarheit.
Bizarr ist, dass Witzfiguren wie Du hier posten!

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Joerg Lorenz
2017-01-04 05:23:47 UTC
Permalink
Post by Jonas Klein
Post by Schorsch
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
Wenn Ihr (alles die die Aussage für richtig halten) es doch
tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Text enthält (den Namen XYZ, der immer wieder einen
Rattenschwanz an Reaktionen verursacht, die mich nicht die
Bohne interessieren) -> Löschen der Nachricht.
Irgendwie verstehe ich Dein Problem nicht: Filtere auf die Mailadresse
der Person, die die Probleme verursacht und dann löscht Du nicht die
Nachricht, sondern ignorierst das Unterthema. Du wirst staunen.
--
http://www.albasani.net/index.html.de
Ein freier und kostenloser Server fuer Usenet/NetNews (NNTP)
Jonas Klein
2017-01-04 13:18:59 UTC
Permalink
Post by Joerg Lorenz
Post by Jonas Klein
Dann beantworte bitte diese Frage: Wie kann ich Filter
einrichten, die nicht nur Betreff, Von, Datum und Größe,
sondern auch den Text berücksichtigen?
Text enthält (den Namen XYZ, der immer wieder einen
Rattenschwanz an Reaktionen verursacht, die mich nicht die
Bohne interessieren) -> Löschen der Nachricht.
Irgendwie verstehe ich Dein Problem nicht: Filtere auf die
Mailadresse der Person, die die Probleme verursacht und dann
löscht Du nicht die Nachricht, sondern ignorierst das
Unterthema. Du wirst staunen.
Ich staune und bedanke mich herzlich.
"Unterthema ignorieren" hatte schon jemand woanders
vorgeschlagen. Auch eine gute Idee, die ich seit diesem Tipp
angewendet hatte, aber diese Funktion konnte ich erst nach
einigen Rattenschwanz-Antworten aktivieren. Dein Tipp:
Von enthält XYZ -> Unterthema ignorieren
macht diese Gruppe für mich wesentlich lesbarer.
Takvorian
2017-01-03 14:04:33 UTC
Permalink
Post by Schorsch
Wenn Ihr (alles die die Aussage für richtig halten) es doch tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.
Keine Chance. Der IQ der Zielgruppe lässt dies nicht zu. Neurotische Kinder
und teildemente Greise, die hier ihre festgefahrenen Feindbilder ausleben
wollen und sich naiv einbilden, dies könnte die Zielpersonen kümmern.
Es ist ihnen auch völlig wurscht, ob eine Gruppe dadurch zugemüllt wird oder
nicht.
Henning Fischer
2017-01-03 16:04:56 UTC
Permalink
Post by Takvorian
Post by Schorsch
Wenn Ihr (alles die die Aussage für richtig halten) es doch tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.
Keine Chance. Der IQ der Zielgruppe lässt dies nicht zu. Neurotische Kinder
und teildemente Greise, die hier ihre festgefahrenen Feindbilder ausleben
wollen und sich naiv einbilden, dies könnte die Zielpersonen kümmern.
Es ist ihnen auch völlig wurscht, ob eine Gruppe dadurch zugemüllt wird oder
nicht.
Und warum schreibst du dann hier? Schreibzwang?
Takvorian
2017-01-03 19:30:13 UTC
Permalink
Post by Henning Fischer
Post by Takvorian
Post by Schorsch
Wenn Ihr (alles die die Aussage für richtig halten) es doch tun würdet.
Dann wäre die Gruppe wesentlich lesbarer.
Keine Chance. Der IQ der Zielgruppe lässt dies nicht zu. Neurotische Kinder
und teildemente Greise, die hier ihre festgefahrenen Feindbilder ausleben
wollen und sich naiv einbilden, dies könnte die Zielpersonen kümmern.
Es ist ihnen auch völlig wurscht, ob eine Gruppe dadurch zugemüllt wird oder
nicht.
Und warum schreibst du dann hier?
Es sind nicht alle so.
Post by Henning Fischer
Schreibzwang?
Das Wort scheint bei dir eine Zwangsvorstellung zu sein. Hauptsächlich lese
ich hier, um Neues zu erfahren. Wenn ich jemandem helfen kann, gerne auch
das.
Henning Fischer
2017-01-04 08:05:53 UTC
Permalink
Post by Takvorian
Das Wort scheint bei dir eine Zwangsvorstellung zu sein. Hauptsächlich lese
ich hier, um Neues zu erfahren. Wenn ich jemandem helfen kann, gerne auch
das.
es gibt in dieser NG mindestens drei Personen, die zu fast JEDER Frage
irgendwas antworten, egal ob zielführend und sinnvoll oder nicht.

Offensichtlich dient dabei die Darstellung (z.B. als Superexperte) in
erster Linie der Befriedigung eigener Bedürfnisse bzw. entspricht
zwanghaftem Verhalten (ich muß diesen Deppen zeigen wie toll ich bin,
ich kann einfach nicht anders, ohne mich wäre die NG ja völlig
uninteressant...)
Klaus Gawol
2017-01-04 10:39:10 UTC
Permalink
Post by Henning Fischer
Post by Takvorian
Das Wort scheint bei dir eine Zwangsvorstellung zu sein. Hauptsächlich lese
ich hier, um Neues zu erfahren. Wenn ich jemandem helfen kann, gerne auch
das.
es gibt in dieser NG mindestens drei Personen, die zu fast JEDER Frage
irgendwas antworten, egal ob zielführend und sinnvoll oder nicht.
Offensichtlich dient dabei die Darstellung (z.B. als Superexperte) in
erster Linie der Befriedigung eigener Bedürfnisse bzw. entspricht
zwanghaftem Verhalten (ich muß diesen Deppen zeigen wie toll ich bin,
ich kann einfach nicht anders, ohne mich wäre die NG ja völlig
uninteressant...)
Richtig, ohne diese 'mindestens drei Personen' wäre das auch so, weshalb
zu hoffen ist, dass sie auch weiterhin posten und sich resistent gegen
irrationale Kritik zeigen.
Takvorian
2017-01-04 17:44:53 UTC
Permalink
Post by Klaus Gawol
Richtig, ohne diese 'mindestens drei Personen' wäre das auch so, weshalb
zu hoffen ist, dass sie auch weiterhin posten und sich resistent gegen
irrationale Kritik zeigen.
LOL YMMD "irrational" stimmt genau, was anderes könnt ihr ja nicht.
Auch du gehörst zum üblichen Hornvieh in dieser Gruppe. Herr lass Hirn
regnen.
Takvorian
2017-01-04 18:37:31 UTC
Permalink
Post by Takvorian
Post by Klaus Gawol
Richtig, ohne diese 'mindestens drei Personen' wäre das auch so, weshalb
zu hoffen ist, dass sie auch weiterhin posten und sich resistent gegen
irrationale Kritik zeigen.
LOL YMMD "irrational" stimmt genau, was anderes könnt ihr ja nicht.
Auch du gehörst zum üblichen Hornvieh in dieser Gruppe. Herr lass Hirn
regnen.
Noch ein Fake vom Faker-Äffchen.
Klaus Gawol
2017-01-05 08:48:15 UTC
Permalink
Post by Takvorian
Post by Klaus Gawol
Richtig, ohne diese 'mindestens drei Personen' wäre das auch so, weshalb
zu hoffen ist, dass sie auch weiterhin posten und sich resistent gegen
irrationale Kritik zeigen.
LOL YMMD "irrational" stimmt genau, was anderes könnt ihr ja nicht.
Auch du gehörst zum üblichen Hornvieh in dieser Gruppe. Herr lass Hirn
regnen.
Hhm, hier habe ich den Vorpost offenbar falsch verstanden. Mit den
'mindestens drei Personen' von denen ich mir weiterhin trotz allen
Widerstands Beiträge wünsche, meinte ich bspw. dich, Stefan, Hermann
usw., nicht aber jene Beiträge, die praktisch inhaltsleer die NG füllen.
Henning Fischer
2017-01-05 09:01:31 UTC
Permalink
Post by Klaus Gawol
Hhm, hier habe ich den Vorpost offenbar falsch verstanden. Mit den
'mindestens drei Personen' von denen ich mir weiterhin trotz allen
Widerstands Beiträge wünsche, meinte ich bspw. dich, Stefan, Hermann
usw., nicht aber jene Beiträge, die praktisch inhaltsleer die NG füllen.
Hermann würde ich nicht dazu zählen
Takvorian
2017-01-05 14:01:48 UTC
Permalink
Post by Klaus Gawol
Post by Takvorian
Post by Klaus Gawol
Richtig, ohne diese 'mindestens drei Personen' wäre das auch so, weshalb
zu hoffen ist, dass sie auch weiterhin posten und sich resistent gegen
irrationale Kritik zeigen.
LOL YMMD "irrational" stimmt genau, was anderes könnt ihr ja nicht.
Auch du gehörst zum üblichen Hornvieh in dieser Gruppe. Herr lass Hirn
regnen.
Hhm, hier habe ich den Vorpost offenbar falsch verstanden. Mit den
'mindestens drei Personen' von denen ich mir weiterhin trotz allen
Widerstands Beiträge wünsche, meinte ich bspw. dich, Stefan, Hermann
usw., nicht aber jene Beiträge, die praktisch inhaltsleer die NG füllen.
Wie schon gesagt, diesen Nonsens habe nicht ich geschrieben. Es gibt hier
einen Clown, der das gleiche Pseudonym nutzt. Sieh dir die Header an, er
postet immer über den AIOE-Trollserver. Setze einen Filter auf diesen
Server, davon kommt eh nur Müll.
Takvorian
2017-01-04 12:58:08 UTC
Permalink
Post by Henning Fischer
Post by Takvorian
Das Wort scheint bei dir eine Zwangsvorstellung zu sein. Hauptsächlich lese
ich hier, um Neues zu erfahren. Wenn ich jemandem helfen kann, gerne auch
das.
es gibt in dieser NG mindestens drei Personen, die zu fast JEDER Frage
irgendwas antworten, egal ob zielführend und sinnvoll oder nicht.
Die bekannten OT-Plapperer ohne Windowswissen kann man ja einfach filtern.
Post by Henning Fischer
Offensichtlich dient dabei die Darstellung (z.B. als Superexperte) in
erster Linie der Befriedigung eigener Bedürfnisse bzw. entspricht
zwanghaftem Verhalten (ich muß diesen Deppen zeigen wie toll ich bin,
ich kann einfach nicht anders, ohne mich wäre die NG ja völlig
uninteressant...)
LOL. Du meinst also, die Regulars mit fundiertem Wissen in den diversen
Fachgruppen hätten diese alberne, infantile Einstellung. Damit gibst du
immerhin einen interessanten Einblick in deine Psyche und Denkweise.
Selbst wenn es so wäre: wenn jemand wie am Fließband die Probleme anderer
User löste, wäre es wohl ziemlich wurscht, welche Motivation dahinter
steckte. Die Schlüsse, die du da ziehst, sind mit Verlaub aber doch arg
infantil.
Henning Fischer
2017-01-05 06:59:27 UTC
Permalink
Post by Takvorian
LOL. Du meinst also, die Regulars mit fundiertem Wissen in den diversen
Fachgruppen hätten diese alberne, infantile Einstellung. Damit gibst du
immerhin einen interessanten Einblick in deine Psyche und Denkweise.
Selbst wenn es so wäre: wenn jemand wie am Fließband die Probleme anderer
User löste, wäre es wohl ziemlich wurscht, welche Motivation dahinter
steckte. Die Schlüsse, die du da ziehst, sind mit Verlaub aber doch arg
infantil.
"... wie am Fließband die Probleme anderer User löste ..." trifft leider
nur äußerst selten zu. Meist ist es mehr unverständliches Geblubbere
besonders von SK.

Und Leute als ahnungslose Dummschwaetzer oder Äffen zu bezeichnen ist
einfach unakzeptabel.

Mir persönlich würde diese Gruppe ohne die genannten Psychopathen besser
gefallen.
Stefan Kanthak
2017-01-05 13:15:12 UTC
Permalink
"Henning Fischer" <***@t-online.de> schrieb:

[...]
Meist ist es mehr unverständliches Geblubbere besonders von SK.
Fuer Dein mangelhaftes Wissen und Verstaendnis sogar elementarer
Grundlagen von Windows (oder Betruebssystemen) kannst nur Du 'was!
Fuer Dein Unvermoegen, die von Microsoft seit fast 20 Jahren im WWW
bereitgestellte, ZIEMLICH umfassende Information ueber Windows
sinnentnehmend zu lesen, kannst auch nur Du was!
Wenn Du nicht dumm sterben willst: LIES!
Und Leute als ahnungslose Dummschwaetzer oder Äffen zu bezeichnen ist
einfach unakzeptabel.
Ersteres ist eine TATSACHE!
Mir persönlich würde diese Gruppe ohne die genannten Psychopathen besser
gefallen.
de.alt.dummschwatz existiert, GERADE fuer Dich!

Mir persoenlich gefiele eine Gruppe ohne notorische Dummschwaetzer wie
Dich und Andere, von denen staendig geistiger Duennpfiff, aber NIE
irgendein sachlicher oder konstruktiver Beitrag kommt, WESENTLICH besser.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Stefan Kanthak
2017-01-05 14:10:06 UTC
Permalink
Post by Henning Fischer
Und Leute als ahnungslose Dummschwaetzer oder Äffen zu bezeichnen ist
einfach unakzeptabel.
... schreibt der ahnungslose Dummschwaetzer, der gleich darauf andere
als Psychopathen bezeichnet.
Verfuegst Du ueber eine (mehrfach?) gespaltene Persoenlichkeit, die Du
sogar innerhalb eines Post wechselst?
Dein oefter verwendetes "wir" indiziert das!
Post by Henning Fischer
Mir persönlich würde diese Gruppe ohne die genannten Psychopathen besser
gefallen.
"quod licet jovi non licet bovi!"

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Henning Fischer
2017-01-05 15:16:59 UTC
Permalink
Post by Henning Fischer
Und Leute als ahnungslose Dummschwaetzer oder Äffen zu bezeichnen ist
einfach unakzeptabel.
.... schreibt der ahnungslose Dummschwaetzer, der gleich darauf andere
als Psychopathen bezeichnet.
Verfuegst Du ueber eine (mehrfach?) gespaltene Persoenlichkeit, die Du
sogar innerhalb eines Post wechselst?
Dein oefter verwendetes "wir" indiziert das!
Post by Henning Fischer
Mir persönlich würde diese Gruppe ohne die genannten Psychopathen besser
gefallen.
"quod licet jovi non licet bovi!"
Stefan
[
Antwort lohnt nicht
Herrand Petrowitsch
2017-01-05 15:29:41 UTC
Permalink
Post by Henning Fischer
Antwort lohnt nicht
Auf dein infantiles, dummes Geschwaetz: Sicher nicht.

Gruss Herrand
--
Emails an die angegebene Adresse werden gelegentlich sogar gelesen.
Andre Igler
2017-01-05 17:56:25 UTC
Permalink
Post by Henning Fischer
Post by Stefan Kanthak
"quod licet jovi non licet bovi!"
Antwort lohnt nicht
weil Du nicht Latein kannst? *duck&weg*

addio
--
mail <mein vorname> bei <mein nachname> punkt at
—> Mein neues Buch jetzt auf www.oluschka.com
www.albinschwarz.com http://weblog.igler.at
9F16 E985 B0E3 B2D7 D48D 147A F137 3EB0 A41C B361
Sepp Neuper
2017-01-06 14:19:19 UTC
Permalink
Post by Stefan Kanthak
Post by Henning Fischer
Mir persönlich würde diese Gruppe ohne die genannten Psychopathen besser
gefallen.
"quod licet jovi non licet bovi!"
Ich vermute mal, du siehst dich selbst als "iovi"
Das kannst du von mir aus gerne tun. Aber eine Usenet-Gruppe wie
diese hier ist doch für Leute gedacht, die keine IT-Experten sind,
also in diesem Sinne "die Ochsen", und die hier gegenseitig
Erfahrungen, Meinungen und Wissen austauschen wollen.
Quasi ein virtueller Kuhstall.

Man muß es dir daher tatsächlich hoch anrechnen, dass du als
IT-Jupiter dich nicht scheust, diese niederen Gefilde mit deiner
Anwesenheit zu ehren.

Servus, Sepp
Henning Fischer
2017-01-06 15:02:47 UTC
Permalink
Post by Sepp Neuper
Man muß es dir daher tatsächlich hoch anrechnen, dass du als
IT-Jupiter dich nicht scheust, diese niederen Gefilde mit deiner
Anwesenheit zu ehren.
schon mehrmals habe ich empfohlen, daß die betreffenden eine eigene
Gruppe bilden (z.B. de.comp.os.wimdows.tak-sk-petro.e.a.) in der sie
sich ihr geballtes Fachwissen um die Ohren hauen könnten.

Aber das entspräche nicht ihrer Psychopathologie.
Takvorian
2017-01-07 13:51:21 UTC
Permalink
Post by Sepp Neuper
Post by Stefan Kanthak
Post by Henning Fischer
Mir persönlich würde diese Gruppe ohne die genannten Psychopathen besser
gefallen.
"quod licet jovi non licet bovi!"
Ich vermute mal, du siehst dich selbst als "iovi"
Wenn schon, dann sieht er sich als "Iuppiter". So heißt der Typ.
"Iovi" ist der Dativ. Licet -> wem.
Post by Sepp Neuper
Das kannst du von mir aus gerne tun. Aber eine Usenet-Gruppe wie
diese hier ist doch für Leute gedacht, die keine IT-Experten sind,
also in diesem Sinne "die Ochsen", und die hier gegenseitig
Erfahrungen, Meinungen und Wissen austauschen wollen.
Quasi ein virtueller Kuhstall.
Mööp! Eine Newsgroup ist für ALLE gedacht, die Interesse an ihrem Thema
haben. Wenn sie nur für die boves (Ochsen) gedacht wäre, was hätten diese
davon? Sie würden sich nur gegenseitig dummes, unzutreffendes Zeug zu
Windows zublöken und niemand wäre da, der ihnen bei ihren Problemen helfen
könnte. Das willst du also nicht wirklich.
Post by Sepp Neuper
Man muß es dir daher tatsächlich hoch anrechnen, dass du als
IT-Jupiter dich nicht scheust, diese niederen Gefilde mit deiner
Anwesenheit zu ehren.
Zudem bringt diese Anwesenheit jede Menge Wissen mit sich, sofern die boves
denn lernbereit wären... :o)

Hermann
2017-01-02 22:31:53 UTC
Permalink
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
Warum?

Gruß

Hermann
--
Der Neid kann sich nicht verbergen. Er klagt an und verurteilt, ohne
Beweise zu haben; er übertreibt die Fehler, er hat maßlose Namen für
die geringsten Irrtümer, und seine Sprache ist voll Bitterkeit,
Übertreibung und Missgunst. Mit unerbittlichem Hass und rasender Wut
stürzt er sich auf jedes wirkliche Verdienst; er ist blind, jähzornig,
gefühllos, brutal. (Luc de Clapiers, Marquis de Vauvenargues, franzö-
sischer Philosoph, Moralist und Schriftsteller 1715-1747)
Joerg Lorenz
2017-01-03 05:38:58 UTC
Permalink
Post by Claus Reibenstein
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Indem wir Kanthak, Takvorian & Co filtern.
Ist dann die NG für Dich nicht tot?
*SCNR*
--
http://www.albasani.net/index.html.de
Ein freier und kostenloser Server fuer Usenet/NetNews (NNTP)
Stefan Kanthak
2017-01-02 22:23:26 UTC
Permalink
Post by Henning Fischer
Post by Stefan Kanthak
wehret den ahnungslosen Dummschwaetzern!
und wie machen wir das?
Selbst dafuer seid ihr zu bloed: de.alt.dummschwatz existiert!

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Henning Fischer
2017-01-03 07:24:56 UTC
Permalink
Post by Stefan Kanthak
Selbst dafuer seid ihr zu bloed: de.alt.dummschwatz existiert!
hast du sie gegründet?
Michael Graf
2017-01-03 09:40:15 UTC
Permalink
Hi!
Post by Stefan Kanthak
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
Und diese Daten kommen aus dem Nichts?
Diese Zahlen kommen ebenso wenig aus dem Nichts, wie die angezeigte
Transfergeschwindigkeit innerhalb einer RAM-Disk aus dem Nichts kommt.
Es sind die üblichen Zahlen für RAM-Kopiervorgänge.
Ich schrieb: "Diese Daten", denn die Daten, die Dein Cache mit 3GB/s
kopieren will, müssen ja irgendwo herkommen.
Fuer die Funktion eines "write back" oder "wite behind"-Caches ist es
VOELLIG wurscht, woher die Daten kommen: seine Aufgabe ist es ja gerade,
eine schnelle Quelle von einem langsam(er)en Ziel zu entkoppeln.
Und was bringt das, wenn Sinn der Sache ist, eine Datei auf das
langsame(re) Ziel zu transferieren? Kann ich dann das Dateisystem des
langsameren Ziels trennen, solange der (Software-)cache im
inkonsistenten Zustand ist?
Das alles sind bekannte Nachteile eines write-back-caches. Und seit die
Nullzeit-Diskussion los ging wollen jetzt schon 2 das nicht wahrhaben.
Mr. T möchte sich ja zu deinen Höhen vorarbeiten, sehr nett von dir,
dass du ihm entgegen kommst. :-)

Michael
Michael Graf
2017-01-02 09:16:16 UTC
Permalink
Hi!
Post by Falk Duebbert
Post by Takvorian
"Datei wurde kopiert" kommt sofort - 2 GB/s - Datei nach dieser Meldung
sofort bearbeitbar.
Kopieren ohne Cache: "Datei wurde kopiert" erst nach x Sekunden Wartezeit,
180 MB/s - Datei erst dann bearbeitbar.
Du hast drei Eimer Wasser.
Einen nennen wir "Quelle", einen "Cache" und einen Ziel. Es gibt eine
schnelle Pumpe die von "Quelle" nach "Cache" pumpen kann und eine, die
mit normaler Geschwindigkeit von "Cache" nach "Ziel" pumpen kann.
Welche Geschwindigkeit von welcher Pumpe ist wohl für den gesamten
Pumpvorgang entscheidend?
Mein Tipp: Lass es! Es ist den Aufwand nicht wert. Er hat es nicht
kapiert und wird es nie kapieren (wollen).

Michael
Falk Duebbert
2017-01-01 12:59:10 UTC
Permalink
Post by Takvorian
Ich teste sowas im Gegensatz zu dir einfach: die Datei wird im Ziel
angezeigt, mit der erwarteten Größe, logischerweise aber kaputt, wenn man
sie öffnen will.
Dann hast Du kein "schnelles Trennen" aktiviert. Mach demnächst Deine
Tests zum Thema.

Falk D.
Stefan Kanthak
2017-01-01 12:38:14 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
USB-Platten werden als lokale Datenträger geführt und da bewirkt der Cache
z.B., dass ein Kopiervorgang ggf. mit ca. 3 GB/s, statt mit 150 oder 180
MB/s ausgeführt wird. Das ist ein netter Performance-Unterschied.
Für Platten wird "schnelles Trennen" normalerweise nicht angeboten und
ist auch nicht supported - in sofern OT.
Falsch.
Selbstverstaendlich wird "schnelles Trennen" fuer als auswerfbar erkannte
Datentraeger (egal ob Platte, SSD, USB-Stick, SD-Karte, ...) angeboten
und UNTERSTUETZT.

[ GIGO entsorgt ]

wehret den ahnungslosen Dummschwaetzern!
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Jürgen Meyer
2016-12-31 18:11:51 UTC
Permalink
Post by Takvorian
Post by Falk Duebbert
Post by Takvorian
Das stellt leider nicht sicher, im Falle eines Trennens zum falschen
Zeitpunkt keine zerstörten, unbrauchbaren Schrott-Dateien zu bekommen.
Eben doch.
Kann jeder selbst leicht testen. Eine Datei kopieren und dabei das Ziel
trennen. Man wird die Datei im Ziel finden, logischerweise kapott. Mit
sicherem Trennen wäre das nicht passiert.
Genau
Bei mir gibt es eine Fehlermeldung, wenn ich versuche bei einem laufenden
Schreibvorgang die externe HD abzumelden.

Das Trennen (über diesen Button) kann erst erfolgen, nachdem sämtliche
Schreibvorgänge beendet sind. Ansonsten wäre der Schalter ja auch sinnlos.

Wenn nun aber jemand einfach nur das Kabel abzieht - Dagegen ist auch das
beste Windows machtlos

Jürgen
Takvorian
2017-01-01 12:09:27 UTC
Permalink
Post by Jürgen Meyer
Post by Takvorian
Post by Falk Duebbert
Post by Takvorian
Das stellt leider nicht sicher, im Falle eines Trennens zum falschen
Zeitpunkt keine zerstörten, unbrauchbaren Schrott-Dateien zu bekommen.
Eben doch.
Kann jeder selbst leicht testen. Eine Datei kopieren und dabei das Ziel
trennen. Man wird die Datei im Ziel finden, logischerweise kapott. Mit
sicherem Trennen wäre das nicht passiert.
Genau
Bei mir gibt es eine Fehlermeldung, wenn ich versuche bei einem laufenden
Schreibvorgang die externe HD abzumelden.
Auf welche Weise genau wird "abgemeldet"? Abmelden macht man grundsätzlich
nur über "sicheres Entfernen".
Post by Jürgen Meyer
Das Trennen (über diesen Button) kann erst erfolgen, nachdem sämtliche
Schreibvorgänge beendet sind. Ansonsten wäre der Schalter ja auch sinnlos.
Wenn nun aber jemand einfach nur das Kabel abzieht - Dagegen ist auch das
beste Windows machtlos
Man kann den Ausschalter von USB-Platten betätigen oder Sticks einfach
abziehen. Ich würde auch bei "Schnelles Entfernen" immer nur über "sicheres
Entfernen" abmelden.
Claus Reibenstein
2017-01-01 13:00:24 UTC
Permalink
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
"Schnelles Entfernen aktiviert" bedeutet, dass kein Schreibcache
aktiviert ist
Was die Performance in den tiefen Keller treibt.
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
Was man aber einstellen kann und bei mir auch eingestellt ist. Der
Unterschied ist gewaltig.

Gruß
Claus
Takvorian
2017-01-01 14:10:19 UTC
Permalink
Post by Claus Reibenstein
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
"Schnelles Entfernen aktiviert" bedeutet, dass kein Schreibcache
aktiviert ist
Was die Performance in den tiefen Keller treibt.
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
Was man aber einstellen kann und bei mir auch eingestellt ist. Der
Unterschied ist gewaltig.
Richtig, denn im Idealfall stehen eben x GB/s mit Cache gegen x MB/s ohne
Cache.
Jürgen Meyer
2017-01-02 20:10:57 UTC
Permalink
On Sun, 1 Jan 2017 14:00:24 +0100, Claus Reibenstein
Post by Claus Reibenstein
Post by Falk Duebbert
Post by Takvorian
Post by Falk Duebbert
"Schnelles Entfernen aktiviert" bedeutet, dass kein Schreibcache
aktiviert ist
Was die Performance in den tiefen Keller treibt.
Nicht so sehr, da Windows auf removable devices normalerweise eh keinen
Schreibcache anlegt.
Was man aber einstellen kann und bei mir auch eingestellt ist. Der
Unterschied ist gewaltig.
Gruß
Claus
Korrigiert mich wenn ich falsch liege:
Wenn der Schreibcache aktiviert ist, dann wird die Originaldatei beim
"Ausschneiden/Einfügen" sofort gelöscht, wenn der Kopiervorgang gestartet
wird.

Ist der Schreibcache hingegen deaktiviert und es kommt zu einem
Übertragungsfehler, dann ist die Originaldatei immer noch vorhanden.
Die Originaldatei wird erst nach erfolgreicher Übertragung gelöscht.

Für diesen Sicherheitsgewinn warte ich gerne ein paar Sekunden länger.

Gruß
Jürgen
Stefan Kanthak
2017-01-02 21:12:52 UTC
Permalink
"Jürgen Meyer" <***@gmx.de> schrieb:

[...]
Du liegst falsch!
Post by Jürgen Meyer
Wenn der Schreibcache aktiviert ist, dann wird die Originaldatei beim
"Ausschneiden/Einfügen" sofort gelöscht, wenn der Kopiervorgang gestartet
wird.
Sie wird latuernich erst geloescht, wenn der Kopiervorgang ERFOLGREICH
abgeschlossen ist.

[...]

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Takvorian
2017-01-02 21:24:57 UTC
Permalink
Post by Jürgen Meyer
Wenn der Schreibcache aktiviert ist, dann wird die Originaldatei beim
"Ausschneiden/Einfügen" sofort gelöscht, wenn der Kopiervorgang gestartet
wird.
Dann wäre Windows schon lange tot.
Claus Reibenstein
2017-01-03 12:17:31 UTC
Permalink
Post by Jürgen Meyer
Wenn der Schreibcache aktiviert ist, dann wird die Originaldatei beim
"Ausschneiden/Einfügen" sofort gelöscht, wenn der Kopiervorgang
gestartet wird.
Sie wird erst dann gelöscht, wenn der Kopiervorgang aus Sicht der
Anwendung abgeschlossen ist. Dies kann schon sein, wenn die Datei
vollständig in den Cache kopiert wurde, aber auch erst, wenn der
Cache-Inhalt vollständig geschrieben wurde (flush). Hängt von der
Anwendung ab.
Post by Jürgen Meyer
Ist der Schreibcache hingegen deaktiviert und es kommt zu einem
Übertragungsfehler, dann ist die Originaldatei immer noch vorhanden.
Die Originaldatei wird erst nach erfolgreicher Übertragung gelöscht.
Für diesen Sicherheitsgewinn warte ich gerne ein paar Sekunden länger.
Aufgrund der Seltenheit solcher Übertragungsfehler und in Anbetracht der
regelmäßig durchgeführten Datensicherung (3 Kopien) halte ich dieses
Problem für vernachlässigbar. Außerdem dürfte das Warten in der Summe
deutlich länger dauern als das gelegentliche Wiederherstellen einer
Datei aus einer Sicherung.

Mir ist die Performance in diesem Fall wichtiger. Ich habe schlicht
keine Lust, einer blockierten Anwendung dabei zuzuschauen, wie sie Datei
für Datei auf einen Stick kopiert. Ich finde es wesentlich angenehmer,
wenn sie schnell wieder frei wird und ich damit weiterarbeiten kann,
während das System im Hintergrund fröhlich weiterkopiert.

Gruß
Claus
Thorsten Albrecht
2017-01-03 23:11:50 UTC
Permalink
Post by Claus Reibenstein
Mir ist die Performance in diesem Fall wichtiger. Ich habe schlicht
keine Lust, einer blockierten Anwendung dabei zuzuschauen, wie sie Datei
für Datei auf einen Stick kopiert.
Welche "Anwendungen" sind das denn z.B. in Deinem Fall, die ohne
Schreibcache blockiert wären?

Meine Dateimanager (Explorer, Xyplorer) sind jedenfalls beim Kopieren
auf einen Stick nie blockiert, und ich merke gerade auch keinen
Unterschied, ob ich den Schreibcache nun aktiviere oder deaktiviere.
Dauert alles gleich lang; und bei keiner Kombination ist etwas
blockiert.

Thorsten
Takvorian
2017-01-04 13:09:29 UTC
Permalink
Post by Thorsten Albrecht
Post by Claus Reibenstein
Mir ist die Performance in diesem Fall wichtiger. Ich habe schlicht
keine Lust, einer blockierten Anwendung dabei zuzuschauen, wie sie Datei
für Datei auf einen Stick kopiert.
Welche "Anwendungen" sind das denn z.B. in Deinem Fall, die ohne
Schreibcache blockiert wären?
"Blockiert" ist natürlich Unsinn.
Post by Thorsten Albrecht
Meine Dateimanager (Explorer, Xyplorer) sind jedenfalls beim Kopieren
auf einen Stick nie blockiert, und ich merke gerade auch keinen
Unterschied, ob ich den Schreibcache nun aktiviere oder deaktiviere.
Dauert alles gleich lang; und bei keiner Kombination ist etwas
blockiert.
Siehe meine Beispiele, ich hatte die Zeiten doch genau aufgelistet.
Wenn Daten erst mal im Cache vorhanden sind, wird der Schreibvorgang ggf.
rein im Cache mit RAM-Geschwindigkeit abgewickelt. In meinem Beispiel kommt
die Meldung "Datei wurde kopiert" für die 2 GB-Datei dank Schreibcache
sofort, ohne Cache hingegen erst nach 13 Sekunden. Der Cache hat den Sinn,
dass der langsame Datenträger dann gar nicht mehr ins Spiel kommt. Man
arbeitet also mit der Performance einer RAM-Disk, sofern genug RAM
vorhanden.
Claus Reibenstein
2017-01-04 13:24:40 UTC
Permalink
Post by Thorsten Albrecht
Post by Claus Reibenstein
Mir ist die Performance in diesem Fall wichtiger. Ich habe schlicht
keine Lust, einer blockierten Anwendung dabei zuzuschauen, wie sie
Datei für Datei auf einen Stick kopiert.
Welche "Anwendungen" sind das denn z.B. in Deinem Fall, die ohne
Schreibcache blockiert wären?
Z.B. Total Commander beim Synchronisieren von Verzeichnissen.
Post by Thorsten Albrecht
Meine Dateimanager (Explorer, Xyplorer) sind jedenfalls beim
Kopieren auf einen Stick nie blockiert,
Dateien kopieren ist ja nur _ein_ Fall von vielen, in denen der
Schreibcache greift.
Post by Thorsten Albrecht
und ich merke gerade auch keinen Unterschied, ob ich den Schreibcache
nun aktiviere oder deaktiviere.
Dann hast Du den Cache nicht wirklich aktiviert.

Gruß
Claus
Thorsten Albrecht
2017-01-04 17:13:03 UTC
Permalink
Post by Claus Reibenstein
Post by Thorsten Albrecht
Post by Claus Reibenstein
Mir ist die Performance in diesem Fall wichtiger. Ich habe schlicht
keine Lust, einer blockierten Anwendung dabei zuzuschauen, wie sie
Datei für Datei auf einen Stick kopiert.
Welche "Anwendungen" sind das denn z.B. in Deinem Fall, die ohne
Schreibcache blockiert wären?
Z.B. Total Commander beim Synchronisieren von Verzeichnissen.
Ein solches Problem kenne ich nicht mit Xyplorer (oder anderen
Synchronisationsprogrammen). Programme, die zum Blockieren neigen,
würde ich persönlich meiden.
Post by Claus Reibenstein
Post by Thorsten Albrecht
Meine Dateimanager (Explorer, Xyplorer) sind jedenfalls beim
Kopieren auf einen Stick nie blockiert,
Dateien kopieren ist ja nur _ein_ Fall von vielen, in denen der
Schreibcache greift.
Deswegen hatte ich ja gefragt, welche Anwendungsszenarien Dir da
vorschweben. Mir schwebt nur Synchronisation vor, und das ist auch nur
eine Art Kopiervorgang.
Post by Claus Reibenstein
Post by Thorsten Albrecht
und ich merke gerade auch keinen Unterschied, ob ich den Schreibcache
nun aktiviere oder deaktiviere.
Dann hast Du den Cache nicht wirklich aktiviert.
Jein. Der Grund lag an der gestern von mir verwendeten Hardware. Der
Lexar Stick (32 GB) reagiert einfach nicht auf die Cache-Einstellungen
im Gerätemanager. Gerade noch einmal auf einem nagelneuen
Win10-Rechner sowie unter Win7 verifiziert. Nix zu machen.

Dagegen reagiert ein anderer USB 3.0-Stick (64 GB SanDisk Extreme Pro)
sehr wohl auf diese Einstellungen. Mit Cache sehe ich zum ersten Mal
in meinem Leben die berühmte Nullzeit, endlich....! ;-)

Mein Fazit bzgl. der Cache-Einstellung "Bessere Leistung" bzw. dieser
"Nullzeit":
Sie ist - wenn man nicht gerade ein Programm benutzt, welches
ansonsten blockiert (s.o.) - für mich nicht zu gebrauchen. Scheinbar
ist zwar ein Programm wie FreeFileSync im Nu, d.h. in 1s, fertig mit
der Synchronisation, aber in Wirklichkeit kopiert der Cache im
Hintergrund natürlich noch weiter die Daten auf den Stick, und zwar
relativ langsam:

Da der Stick eine Leuchtdiode besitzt, kann man sehen, wie lange das
Betriebssystem benötigt, die Daten vom Cache auf den Stick zu
schaufeln. In meinem Fall (ca. 2 GB) benötigte der Cache ca. 45 s. Zum
Vergleich: mit der Einstellung "schnelles Entfernen" ist der
Datentransfer in 16s vollständig abgeschlossen. Offenbar hat der Cache
in den Defaulteinstellungen also keine besonders hohe
Datentransferrate bzw. Priorität.

Für Sticks, die man gerne schnell wieder abziehen möchte, ist "Bessere
Leistung" also keine geeignete Einstellung, da man aufgrund der
fehlenden Fortschrittsanzeige bei einem Kopiervorgang nie weiß, wann
man "Hardware entfernen" endlich betätigen kann. Zu frühes Betätigen
führt zu einer Fehlermeldung.

Thorsten
Michael Graf
2016-12-31 14:11:47 UTC
Permalink
Hi!
Post by Takvorian
Post by Jürgen Meyer
Richtig ist auch, dass ich das "Sicher entfernen" ja eigentlich gar nicht
brauche, da ja "Schnelles Entfernen" aktiviert ist.
Und laufende Schreibvorgänge werden dann beim Entfernen wie erkannt?
DAS ist richtig gute Realsatire. :-)))

Michael
Falk Duebbert
2016-12-30 22:50:33 UTC
Permalink
Post by Jürgen Meyer
1) Anstelle des LW2 wird das LW1 entfernt
Das passiert eigentlich nur, wenn der Hersteller richtig gespart hat und
keine geräte-individuelle USB-ID in die Chips brennt. Das Unmounten
passiert unterhalb des Dateisystems.

Ich habe da öfter Probleme, weil ich teilweise die virtuelle Hardware
von gestern auf dem gleichen Rechner habe.
Post by Jürgen Meyer
2) Es gibt eine Fehlermeldung (LW2 kann nicht entfernt werden, ist in
Gebrauch)
Wenn Du die Locks nicht per powershell auflisten und töten willst:
unlocker oder Lockhunter gibt es in portabel

Ich habe für Hotliner mal das hier eingesetzt:
https://quickandeasysoftware.net/software/usb-disk-ejector

Falk D.
Loading...