ファイルをペンドライブにコピーしているときに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を使用していますか？その場合、問題はLinuxがSDカードやUSBスティックなどの遅いデバイスで大量の書き込みを数分間ロックする可能性があることです。これは既知のバグであり、新しいカーネルで修正する必要があります。
参照 http://lwn.net/Articles/572911/
回避策：ルートの問題として：
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
64ビットマシンの/etc/rc.localファイルに追加しました。
[〜＃〜] 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 rootを使用し、echoおよびcatを使用します）。
更新2016/04/18結局、問題はまだここにあるようです。 LWN.net の ライトバックキューに関するこの記事 で確認できます。
その理由は、システムがブロックの消去（読み取り/変更/書き込みを行う）+ブロックのミスアライメントよりも小さいチャンクで書き込みを試みるため、書き込みが増幅される可能性があります。
現在の設定を確認するには、次のようにします。
cat /sys/block/sd**X**/device/max_sectors
これらのデバイスのホールルールを調整できます。
この場合、デフォルトの240（USBストレージ）を使用するすべてのデバイスのmax_sectorsを32Kセクターまたは2Kセクターに置き換えました。
私のシステム（Mageia 4、3.14.24 core 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倍になりました。 mccpおそらく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/.
この操作中にシステムがフリーズすることを期待します。幸運にも、これらのログファイルのいずれかで煙が見つかる可能性があります。