ファイルをペンドライブにコピーしているときにPCがフリーズするのはなぜですか？

ここには本当に奇妙な状況があります。少なくともほとんどの場合、私のPCは正常に動作しますが、対処できないことが1つあります。私のペンドライブからファイルをコピーしようとすると、すべてが大丈夫です-16-19M / sを取得しましたが、それはかなりうまくいきます。しかし、同じペンドライブに何かをコピーしようとすると、PCがフリーズします。マウスポインターが1〜2秒間停止し、その後少し移動して再び停止します。たとえば、Amarokで何かが再生されている場合、音はマシンガンのように機能します。速度は500K / sから15M / s、平均8M / sにジャンプします。これは、何かをペンドライブにコピーしているときにのみ発生します。コピーのプロセスが完了すると、すべてが正常に戻ります。

他のペンドライブ、フロントパネルの別のUSBポート、または背面からのポートなど、すべてを試しましたが、マザーボード（フロントパネル）のUSBピンも変更しましたが、USBスティックをどこに置いても同じです。私は別のファイルシステムを試してみました- 、。fat32 ext4私のラップトップで、Windows上のデバイスに問題はありません。それは私のPCまたは私のシステムの何かでなければなりません。何を探すべきか分かりません。スタンドアロンOpenboxでDebianテストを使用しています。私のPCはちょっと古いです-Pentium D 3GHz、1GiBのRAM、1,5TB WD Greenディスク。この問題を解決するのに役立つ何かがあれば、それを聞いてうれしいです。

他にどんな情報を提供する必要があるのか​​わかりませんが、何か必要な場合は尋ねてください。できるだけ早くこの投稿を更新します。

この問題をubuntu 13.04のライブCDで再現しようとしました。暗号化されたパーティションと暗号化されたスワップをマウントし、ペンドライブをUSBポートに接続しました。次に、いくつかのアプリを起動しようとしましたが、今ではRAMに〜820MiB、SWAPに約400MiBがあります。コピーに問題はなく、フリーズすることもありません。すべて正常です。だから、それはシステムの障害のように見えますが、正確にはどこですか？このような奇妙な動作を引き起こすのは何ですか？

多くのメモリを搭載した64ビットバージョンのLinuxを使用していますか？その場合、問題は、たとえばSDカードやUSBスティックなどの低速デバイスでの大量の書き込みでLinuxが数分間ロックする可能性があることです。これは、新しいカーネルで修正されるべき既知のバグです。

http://lwn.net/Articles/572911/を参照してください

回避策：ルートの問題として：

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

/etc/rc.local64ビットマシンのファイルに追加しました。

TANSTAAFL ; この変更により、これらのデバイスのスループットが低下する可能性があります（おそらく低下します）---遅延と速度の妥協点です。以前の動作に戻すには、次のことができます

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

...これはデフォルト値です。つまり、ライトバックの動作はパラメータdirty_ratioとによって制御されますdirty_background_ratio。

not-so-expert-with-linuxの人々への注意：のファイル/proc は擬似ファイルです---カーネルとユーザー空間間の単なる通信チャネルです。エディターを使用して変更したり見たりしないでください。代わりにシェルプロンプトを取得します---たとえば、sudo -i（Ubuntuフレーバー）またはsu rootandおよびandを使用echoしcatます。

更新2016/04/18結局のところ、問題はまだ残っているようです。ライトバックキューに関するこの記事のLWN.netで確認できます。

システムは、ブロックの消去（読み取り/修正/書き込みを行う）+ブロックの不整列よりも小さいチャンクで書き込みを試みるため、書き込み増幅が原因である可能性があります。

現在の設定を確認するには：

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

これらのデバイスのホールルールを調整できます。

デバイスファミリ全体のUSB "max_sectors"の値を変更する

この場合、すべてのデバイスのmax_sectorsを置き換え、デフォルトの240（USBストレージ）を32Kセクターまたは2Kセクターに使用しました。

私のシステム（Mageia 4、3.14.24コアi7）では、Kingston DT101 G2 16GBで書き込み速度が非常に遅い（2MB /秒）ため、これを行う必要がありました。

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

追加します：

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

そして、dd書き込み速度が3倍倍に上りました。mc cpおそらく10〜20倍（最初のパーティション@ 8192番目のセクターを開始し、64kに整列したクラスターで再フォーマットした後）：

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

アライメントを確認するには（[データ開始セクター]が128（クラスターサイズ）の倍数であることを確認してください）。必要に応じて、予約済みセクターの数（-R）を調整します。

デフォルトのmax_sectors（240）は、一部の安価な新しいドライブで高い書き込み増幅を引き起こすようです。ただし、このような高い設定では非常に注意してください。2048セクターで同様の効果が得られます（おそらく1Mの消去ブロック：

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

すべての古いUSBデバイスをテストして、それらが正常に機能することを確認します。ルールファイルのベンダー/モデル属性を使用して、より具体的にします。

ハードウェアとソフトウェア

USBサムドライブでこれに似た奇妙な問題に遭遇しましたが、私の研究ではほとんどの場合ドライバーの問題か、PC /マザーボード内の特定のハードウェアのどちらかです。

これは、同一のハードウェアであるいくつかのシステムを持っているからです。1つは問題なくこの操作を実行できますが、もう1つは問題が発生します。

何をすべきか？

あなたのオプションはここでは本当に制限されています。できることは、システムに最新のBIOS /ファームウェアがインストールされていること、およびdistoのパッケージの最新バージョンがあることを確認することだけです。

それ以上に、別のコピーの進行中にファイルをコピーしようとしないことで、この状況を確実に回避することができます。

このような性格の人がいるなら、Linuxの別のライブディストリビューションを試して、問題につながるステップを繰り返すことができます。これにより、上記で説明したように、それがディストリビューション固有の問題なのか、ハードウェアの問題なのかがなくなります。ちょっとした慰めになりますが、頭を砂に埋めるのではなく、常に物事を知りたいです。

他に何か？

本当に強迫観念している場合は、straceシステムコールがフリーズしているときにシステムをキャッチすることを期待して、コピーを実行しているアプリケーションを実行してみてください。これはコマンドラインからも実行できるはずです。

例

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

次に、実行中に別のものを起動します。

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

この操作中にシステムがフリーズし、幸運なことに、これらのログファイルのいずれかで煙が見つかる可能性があります。