it-swarm.com.de

Warum friert mein PC ein, während ich eine Datei auf ein Pendrive kopiere?

Ich habe hier eine wirklich seltsame Situation. Mein PC funktioniert zumindest in den meisten Fällen einwandfrei, aber eines kann ich nicht erledigen. Wenn ich versuche, eine Datei von meinem Pendrive zu kopieren, ist alles in Ordnung - ich habe 16-19M/s, es funktioniert ziemlich gut. Wenn ich jedoch versuche, etwas auf dasselbe Pendrive zu kopieren, friert mein PC ein. Der Mauszeiger bleibt für ein oder zwei Sekunden stehen, bewegt sich dann ein wenig und stoppt erneut. Wenn zum Beispiel in Amarok etwas abgespielt wird, wirkt der Ton wie ein Maschinengewehr. Die Geschwindigkeit springt von 500 K/s auf 15 M/s, durchschnittlich 8 M/s. Dies tritt nur auf, wenn ich etwas auf ein Pendrive kopiere. Wenn der Kopiervorgang abgeschlossen ist, ist alles wieder normal.

Ich habe alles versucht - andere Pendrives, einen anderen USB-Anschluss an der Vorderseite oder diese Anschlüsse von hinten. Ich habe sogar die USB-Pins auf der Hauptplatine (Vorderseite) gewechselt, aber egal, wo ich meinen USB-Stick stecke, es ist immer der gleiche. Ich habe verschiedene Dateisysteme ausprobiert - fat32, ext4. Ich habe kein Problem mit dem Gerät unter Windows, auf meinem Laptop. Es muss mein PC oder etwas in meinem System sein. Ich habe keine Ahnung, wonach ich suchen soll. Ich verwende Debian-Tests mit eigenständiger Openbox. Mein PC ist irgendwie alt - Pentium D 3 GHz, 1 GB RAM, 1,5 TB WD Green-Festplatte. Wenn Sie etwas haben, das mir bei der Lösung dieses Problems helfen würde, würde ich mich freuen, das zu hören.

Ich weiß nicht, welche weiteren Informationen ich bereitstellen soll, aber wenn Sie etwas benötigen, fragen Sie einfach, ich werde diesen Beitrag so schnell wie möglich aktualisieren.

Ich habe versucht, dieses Problem auf Ubuntu 13.04 Live-CD zu reproduzieren. Ich habe meine verschlüsselte Partition + den verschlüsselten Swap gemountet und mein Pendrive mit einem USB-Port verbunden. Als nächstes habe ich versucht, einige Apps zu starten, und jetzt habe ich ~ 820MiB in RAM und ungefähr 400MiB in SWAP. Es gibt kein Problem beim Kopieren, überhaupt kein Einfrieren, alles ist so, wie es sein sollte. Also Es sieht so aus, als wäre es ein Fehler des Systems, aber wo genau? Was würde solch ein seltsames Verhalten verursachen?

68

Verwenden Sie eine 64-Bit-Version von Linux mit viel Speicher? In diesem Fall könnte das Problem darin bestehen, dass Linux bei großen Schreibvorgängen auf langsamen Geräten wie z. B. SD-Karten oder USB-Sticks minutenlang sperren kann. Es ist ein bekannter Fehler, der in neueren Kerneln behoben werden sollte.

Siehe http://lwn.net/Articles/572911/

Problemumgehung: als Grundproblem:

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

Ich habe es meiner /etc/rc.local - Datei auf meinen 64-Bit-Computern hinzugefügt.

TANSTAAFL ; Diese Änderung kann (und wird wahrscheinlich) Ihren Durchsatz zu diesen Geräten reduzieren - es ist ein Kompromiss zwischen Latenz und Geschwindigkeit. Um zum vorherigen Verhalten zurückzukehren, können Sie

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

... das sind die Standardwerte, dh das Rückschreibverhalten wird durch die Parameter dirty_ratio und dirty_background_ratio gesteuert.

Hinweis für die weniger Experten unter Linux: Die Dateien in /proc Sind Pseudodateien - nur Kommunikationskanäle zwischen dem Kernel und dem Benutzerbereich. Verwenden Sie niemals einen Editor, um sie zu ändern oder anzusehen. Holen Sie sich stattdessen eine Shell-Eingabeaufforderung --- zum Beispiel mit Sudo -i (Ubuntu-Aromen) oder su root und verwenden Sie echo und cat).

Update 18.04.2016 Es scheint, dass das Problem immer noch besteht. Sie können es unter LWN.net , in dieser Artikel über Rückschreibewarteschlangen ansehen.

93
Rmano

Der Grund kann die Schreibverstärkung sein, da das System versucht, in Blöcken zu schreiben, die kleiner sind als das Löschen des Blocks (Lesen/Mod/Schreiben) + Blockfehlausrichtung.

So überprüfen Sie Ihre aktuelle Einstellung:

cat /sys/block/sd**X**/device/max_sectors

Sie können die Hallregeln für diese Geräte optimieren:

Ändern Sie den Wert von USB "max_sectors" für eine ganze Gerätefamilie

In diesem Fall hatte ich max_sectors für alle Geräte ersetzt, die standardmäßig 240 (USB-Speicher) für 32K-Sektoren oder 2K-Sektoren verwendeten.

Auf meinem System (Mageia 4, 3.14.24 Core i7) musste ich dies aufgrund der furchtbar langsamen Schreibgeschwindigkeit (2 MB/s) auf Kingston DT101 G2 16 GB tun:

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules

und hinzufügen:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"

Und die dd Schreibgeschwindigkeit stieg dreimal. mccp wahrscheinlich 10-20x höher (nachdem ich die erste Partition im 8192. Sektor gestartet und mit 64k ausgerichteten Clustern neu formatiert hatte):

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n Kingston16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

um die Ausrichtung zu überprüfen (überprüfen Sie, ob [Datenstartsektor] ein Vielfaches von 128 (Clustergröße) sein sollte). Passen Sie bei Bedarf die Anzahl der reservierten Sektoren (-R) an.

Die Standardwerte für max_sectors (240) scheinen bei einigen der billigen neuen Laufwerke eine hohe Schreibverstärkung zu verursachen. Aber seien Sie sehr vorsichtig mit solch einer hohen Einstellung, der ähnliche Effekt wird bei 2048 Sektoren erzielt (wahrscheinlich 1 Million Löschblöcke:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"

Testen Sie alle Ihre alten USB-Geräte, damit sie noch gut funktionieren. Verwenden Sie Hersteller-/Modellattribute in den Regeldateien, um genauer zu sein.

3
Mark

hardware vs. Software

Ich bin auf ein ähnliches Problem mit USB-Sticks gestoßen, und bei meinen Nachforschungen handelt es sich fast immer entweder um ein Treiberproblem oder um die spezifische Hardware auf dem PC/Motherboard.

Ich weiß das, weil ich mehrere Systeme habe, die identische Hardware haben, und auf einem kann ich diesen Vorgang ohne Probleme ausführen, während auf einem anderen das Problem auftritt.

Was ist zu tun?

Ihre Möglichkeiten sind hier wirklich begrenzt. Sie können lediglich sicherstellen, dass auf Ihrem System das neueste BIOS/die neueste Firmware installiert ist und dass Sie über die neuesten Versionen der Pakete Ihrer Distribution verfügen.

Darüber hinaus kann ich nur vorschlagen, dass Sie diese Situation vermeiden, indem Sie nicht versuchen, Dateien zu kopieren, während eine andere Kopie ausgeführt wird.

Wenn Sie die Art von Persönlichkeit haben, in der Sie solche Dinge ärgern, können Sie eine andere Live-Distribution von Linux ausprobieren und die Schritte wiederholen, die zu Ihrem Problem führen. Dies würde nur beseitigen, ob es sich um ein distro-spezifisches Problem oder ein Hardware-Problem handelt, wie ich oben beschrieben habe. Es wäre ein kleiner Trost, aber ich möchte immer Dinge wissen, anstatt meinen Kopf in den Sand zu stecken, und nicht.

Noch etwas?

Wenn Sie wirklich besessen sind, können Sie versuchen, die Anwendung, mit der Sie die Kopie erstellen, über strace auszuführen, in der Hoffnung, das System bei jedem Systemaufruf zu fangen, der einfriert. Sie sollten dies auch über die Befehlszeile tun können.

Beispiel

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

Dann, während das läuft, starte einen anderen.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

Das System friert hoffentlich während dieses Vorgangs ein, und vielleicht haben Sie Glück und finden in einer dieser Protokolldateien etwas Rauch.

1
slm